先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

通过调用同步器的release(int arg)方法可以释放同步状态，该方法在释放了同步状态之后，会唤醒其后继节点（进而使后继节点重新尝试获取同步状态）

同步器的release方法

public final boolean release(int arg) {

if (tryRelease(arg)) {

Node h = head;

if (h != null && h.waitStatus != 0)

//unparkSuccessor(Node node)方法使用LockSupport来唤醒处于等待状态的线程

unparkSuccessor(h);

return true;

}

return false;

}

独占式同步状态获取和释放过程的总结

1. 在获取同步状态时，同步器维护一个同步队列，获取状态失败的线程都会被加入到队列中并在队列中进行自旋

2. 移出队列（或停止自旋）的条件是前驱节点为头节点且成功获取了同步状态

3. 在释放同步状态时，同步器调用tryRelease(int arg)方法释放同步状态，然后唤醒头节点的后继节点。

3.重入锁和公平锁

---

3-1 定义

重入锁ReentrantLock，顾名思义，就是支持重进入的锁，它表示该锁能够支持一个线程对资源的重复加锁。除此之外，该锁的还支持获取锁时的公平和非公平性选择。

• synchronized关键字隐式的支持重进入，比如一个synchronized修饰的递归方 法，在方法执行时，执行线程在获取了锁之后仍能连续多次地获得该锁

• ReentrantLock虽然没能像synchronized关键字一样支持隐式的重进入，但是在调用lock()方 法时，已经获取到锁的线程，能够再次调用lock()方法获取锁而不被阻塞。

这里提到一个锁获取的公平性问题，如果在绝对时间上，先对锁进行获取的请求一定先被满足，那么这个锁是公平锁，反之，是不公平的。公平的获取锁，也就是等待时间最长的线程最优先获取锁，也可以说锁获取是顺序的。ReentrantLock提供了一个构造函数，能够控制锁是否是公平的。

默认是不公平锁，需要在创建时指定为公平锁：

ReentrantLock lock = new ReentrantLock(true);

3-2 ReentrantLock实现重进入

重进入是指任意线程在获取到锁之后能够再次获取该锁而不会被锁所阻塞，该特性的实现需要解决以下两个问题：

1. 线程再次获取锁。锁需要去识别获取锁的线程是否为当前占据锁的线程，如果是，则再次成功获取。

2. 锁的最终释放。线程重复n次获取了锁，随后在第n次释放该锁后，其他线程能够获取到该锁。锁的最终释放要求锁对于获取进行计数自增，计数表示当前锁被重复获取的次数，而锁被释放时，计数自减，当计数等于0时表示锁已经成功释放。

ReentrantLock是通过组合自定义同步器来实现锁的获取与释放，以非公平性（默认的） 实现为例，获取同步状态的代码如代码：

ReentrantLock的nonfairTryAcquire方法

final boolean nonfairTryAcquire(int acquires) {

final Thread current = Thread.currentThread();

int c = getState();

//第一次获得锁

if (c == 0) {

if (compareAndSetState(0, acquires)) {

setExclusiveOwnerThread(current);

return true;

}

} else if (current == getExclusiveOwnerThread()) {

//判断当前线程是否为获取锁的线程

//如果是获取锁的线程再次请求，则将同步状态值进行增加并返回true

int nextc = c + acquires;

if (nextc < 0)

throw new Error(“Maximum lock count exceeded”);

setState(nextc);

return true;

}

return false;

}

ReentrantLock的tryRelease方法

protected final boolean tryRelease(int releases) {

int c = getState() - releases;

if (Thread.currentThread() != getExclusiveOwnerThread())

throw new IllegalMonitorStateException();

boolean free = false;

//如果该锁被获取了n次，那么前(n-1)次tryRelease(int releases)方法必须返回false

if (c == 0) {

free = true;

setExclusiveOwnerThread(null);

//释放成功

}

setState;

return free;

}

3-3 公平与非公平获取锁的区别

公平性与否是针对获取锁而言的，如果一个锁是公平的，那么锁的获取顺序就应该符合请求的绝对时间顺序，也就是FIFO

公平锁的获取方法：

ReentrantLock的tryAcquire方法

protected final boolean tryAcquire(int acquires) {

final Thread current = Thread.currentThread();

int c = getState();

if (c == 0) {

//该方法与nonfairTryAcquire(int acquires)比较，唯一不同的位置为判断条件多了

//hasQueuedPredecessors()方法，即加入了同步队列中当前节点是否有前驱节点的判断，如果该方法返回true，则表示有线程比当前线程更早地请求获取锁，因此需要等待前驱线程获取并释放锁之后才能继续获取锁

if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) {

setExclusiveOwnerThread(current);

return true;

}

} else if (current == getExclusiveOwnerThread()) {

int nextc = c + acquires;

if (nextc < 0)

throw new Error(“Maximum lock count exceeded”);

setState(nextc);

return true;

}

return false;

}

• 公平性锁保证了锁的获取按照FIFO原则，而代价是进行大量的线程切换

• 非公平性锁虽然可能造成线程“饥饿”，但极少的线程切换，保证了其更大的吞吐量。相比公平锁并发度更高

4.读写锁

---

4-1 定义

• 读写锁在同一时刻可以允许多个读线程访问，但是在写线程访问时，所有的读线程和其他写线程均被阻塞。读写锁维护了一对锁，一个读锁和一个写锁，通过分离读锁和写锁，使得并发性相比一般的排他锁有了很大提升

• 一般情况下，读写锁的性能都会比排它锁好，因为大多数场景读是多于写的。在读多于写的情况下，读写锁能够提供比排它锁更好的并发性和吞吐量。Java并发包提供读写锁的实现是 ReentrantReadWriteLock

ReentrantReadWriteLock的特性：

4-2 读写锁的接口与示例

ReadWriteLock仅定义了获取读锁和写锁的两个方法，即readLock()方法和writeLock()方 法，而其实现——ReentrantReadWriteLock，除了接口方法之外，还提供了一些便于外界监控其 内部工作状态的方法：

一个缓存示例：

public class Cache {

static Map<String, Object> map = new HashMap<String, Object>();

static ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();

static Lock r = rwl.readLock();

static Lock w = rwl.writeLock();

//获取一个key对应的value

public static final Object get(String key) {

//获取读锁

r.lock();

try {

return map.get(key);

} finally {

r.unlock();

}

}

//设置key对应的value，并返回旧的value

public static final Object put(String key, Object value) {

//获取写锁,在更新HashMap时必须提前获取写锁，当获取写锁后，其他线程对于读锁和写锁的获取均被阻塞，而只有写锁被释放之后，其他读写操作才能继续

w.lock();

try {

return map.put(key, value);

} finally {

w.unlock();

}

}

//清空所有的内容

public static final void clear() {

//获取写锁

w.lock();

try {

map.clear();

} finally {

w.unlock();

}

}

}

上述示例中，Cache组合一个非线程安全的HashMap作为缓存的实现，同时使用读写锁的读锁和写锁来保证Cache是线程安全的。Cache使用读写锁提升读操作的并发性，也保证每次写操作对所有的读写操作的可见性，同时简化了编程方式

4-3 读写锁的实现分析

（1）读写状态的设计

读写锁同样依赖自定义同步器来实现同步功能，而读写状态就是其同步器的同步状态。

如果在一个整型变量上维护多种状态，就一定需要“按位切割使用”这个变量，读写锁将变量切分成了两个部分，高16位表示读，低16位表示写

（2）写锁的获取与释放

写锁是一个支持重进入的排它锁

• 如果当前线程已经获取了写锁，则增加写状态。

• 如果当前线程在获取写锁时，读锁已经被获取（读状态不为0）或者该线程不是已经获取写锁的线程， 则当前线程进入等待状态

ReentrantReadWriteLock的tryAcquire方法：

protected final boolean tryAcquire(int acquires) {

Thread current = Thread.currentThread();

int c = getState();

int w = exclusiveCount;

if (c != 0) {

// 存在读锁或者当前获取线程不是已经获取写锁的线程

if (w == 0 || current != getExclusiveOwnerThread())

return false;

if (w + exclusiveCount(acquires) > MAX_COUNT)

throw new Error(“Maximum lock count exceeded”);

setState(c + acquires);

return true;

}

if (writerShouldBlock() || !compareAndSetState(c, c + acquires)) {

return false;

}

setExclusiveOwnerThread(current);

return true;

}

（3）读锁的获取与释放

读锁是一个支持重进入的共享锁

• 它能够被多个线程同时获取，在没有其他写线程访问 （或者写状态为0）时，读锁总会被成功地获取，而所做的也只是（线程安全的）增加读状态

• 如果当前线程已经获取了读锁，则增加读状态。

• 如果当前线程在获取读锁时，写锁已被其他线程获取，则进入等待状态

ReentrantReadWriteLock的tryAcquireShared方法的核心部分：

protected final int tryAcquireShared(int unused) {

for (; {

int c = getState();

int nextc = c + (1 << 16);

if (nextc < c)

throw new Error(“Maximum lock count exceeded”);

if (exclusiveCount != 0 && owner != Thread.currentThread())

return -1;

if (compareAndSetState(c, nextc))

return 1;

}

}

读锁的每次释放（线程安全的，可能有多个读线程同时释放读锁）均减少读状态，减少的值是（1<<16）。

4）锁降级

锁降级指的是写锁降级成为读锁

• 如果当前线程拥有写锁，然后将其释放，最后再获取读锁，这种分段完成的过程不能称之为锁降级。×

• 锁降级是指把持住（当前拥有的）写锁，再获取到读锁，随后释放（先前拥有的）写锁的过程。√

一个栗子：

public void processData() {

readLock.lock();

if (!update) {

// 必须先释放读锁

readLock.unlock();

// 锁降级从写锁获取到开始

writeLock.lock();

try {

if (!update) {

// 准备数据的流程（略）

update = true;

}

//再获取读锁

readLock.lock();

} finally {

writeLock.unlock();

}

// 锁降级完成，写锁降级为读锁

}

try {

// 使用数据的流程（略）

} finally {

readLock.unlock();

}

}

上述示例中，当数据发生变更后，update变量（布尔类型且volatile修饰）被设置为false，此时所有访问processData()方法的线程都能够感知到变化，但只有一个线程能够获取到写锁，其他线程会被阻塞在读锁和写锁的lock()方法上。当前线程获取写锁完成数据准备之后，再获取读锁，随后释放写锁，完成锁降级

RentrantReadWriteLock不支持锁升级（把持读锁、获取写锁，最后释放读锁的过程）。目的也是保证数据可见性，如果读锁已被多个线程获取，其中任意线程成功获取了写锁并更新了数据，则其更新对其他获取到读锁的线程是不可见的

5.LockSupport工具

---

LockSupport定义了一组以park开头的方法用来阻塞当前线程，以及unpark(Thread thread) 方法来唤醒一个被阻塞的线程。

LockSupport提供的阻塞和唤醒方法：

注：想要详细了解LockSupport的使用和原理可以参考【并发编程】（学习笔记-共享模型之管程）-part3

6.Condition接口

---

6-1 定义

任意一个Java对象，都拥有一组监视器方法（定义在java.lang.Object上），主要包括wait()、 wait(long timeout)、notify()以及notifyAll()方法，这些方法与synchronized同步关键字配合，可以实现等待/通知模式

Condition接口也提供了类似Object的监视器方法，与Lock配合可以实现等待/通知模式，但是这两者在使用方式以及功能特性上还是有差别的

Object的监视器方法与Condition接口的对比：

6-2 Condition接口与示例

Condition的使用方式比较简单，需要注意在调用方法前获取锁

//获取锁

Lock lock = new ReentrantLock();

//通过Lock对象获得Condition对象

Condition condition = lock.newCondition();

public void conditionWait() throws InterruptedException {

lock.lock();

try {

condition.await();

} finally {

lock.unlock();

}

}

public void conditionSignal() throws InterruptedException {

lock.lock();

try {

condition.signal();

} finally {

lock.unlock();

}

}

一般都会将Condition对象作为成员变量。

• 当调用await()方法后，当前线程会释放锁并在此等待

• 而其他线程调用Condition对象的signal()方法，通知当前线程后，当前线程才从await()方法返回，并且在返回前已经获取了锁。

• 要执行这两个方法都得获得Lock锁

Condition定义的（部分）方法以及描述：

获取一个Condition必须通过Lock的newCondition()方法

下面通过一个有界队列的示例来深入了解Condition的使用方式：

public class BoundedQueue {

private Object[] items;

// 添加的下标，删除的下标和数组当前数量

private int addIndex, removeIndex, count;

//获得锁

private Lock lock = new ReentrantLock();

private Condition notEmpty = lock.newCondition();

private Condition notFull = lock.newCondition();

public BoundedQueue(int size) {

items = new Object[size];

}

// 添加一个元素，如果数组满，则添加线程进入等待状态，直到有"空位"

public void add(T t) throws InterruptedException {

//首先需要获得锁，目的是确保数组修改的可见性和排他性

lock.lock();

try {

//当数组数量等于数组长度时，表示数组已满，则调用notFull.await()，当前线程随之释放锁并进入等待状态。

while (count == items.length)

notFull.await();

//如果数组数量不等于数组长度，表示数组未满，则添加元素到数组中，同时通知等待在notEmpty上的线程，数组中已经有新元素可以获取。

items[addIndex] = t;

if (++addIndex == items.length)

addIndex = 0;

++count;

notEmpty.signal();

} finally {

lock.unlock();

}

}

// 由头部删除一个元素，如果数组空，则删除线程进入等待状态，直到有新添加元素

@SuppressWarnings(“unchecked”)

public T remove() throws InterruptedException {

//获得锁

lock.lock();

try {

while (count == 0)

notEmpty.await();

Object x = items[removeIndex];

if (++removeIndex == items.length)

removeIndex = 0;

–count;

notFull.signal();

return (T) x;

} finally {

lock.unlock();

}

}

}

在添加和删除方法中使用while循环而非if判断，目的是防止过早或意外的通知，只有条件符合才能够退出循环。回想之前提到的等待/通知的经典范式，二者是非常类似的。

6-3 Condition的实现分析

ConditionObject是同步器AbstractQueuedSynchronizer的内部类，因为Condition的操作需要获取相关联的锁，所以作为同步器的内部类也较为合理。

每个Condition对象都包含着一个队列（以下称为等待队列），该队列是Condition对象实现等待/通知功能的关键。（下面提到的Condition如 果不加说明均指的是ConditionObject）

1）等待队列

• 等待队列是一个FIFO（先进先出）的队列，在队列中的每个节点都包含了一个线程引用，该线程就是在Condition对象上等待的线程

• 一个Condition包含一个等待队列，Condition拥有首节点（firstWaiter）和尾节点 （lastWaiter）。当前线程调用Condition.await()方法，那么该线程将会释放锁，将会以当前线程构造节点，并将节点从尾部加入等待队列

等待队列的基本结构如图：

Condition拥有首尾节点的引用，而新增节点只需要将原有的尾节点nextWaiter 指向它，并且更新尾节点即可。

注意：上述节点引用更新的过程并没有使用CAS保证，原因在于调用 await()方法的线程必定是获取了锁的线程，也就是说该过程是由锁来保证线程安全的

在Object的监视器模型上，一个对象拥有一个同步队列和等待队列，而并发包中的 Lock（更确切地说是同步器）拥有一个同步队列和多个等待队列：

Condition的实现是同步器的内部类，因此每个Condition实例都能够访问同步器 提供的方法，相当于每个Condition都拥有所属同步器的引用

2）等待

• 调用Condition的await()方法（或者以await开头的方法），会使当前线程进入等待队列并释放锁，同时线程状态变为等待状态。

• 当从await()方法返回时，当前线程一定获取了Condition相关联的锁

• 如果从队列（同步队列和等待队列）的角度看await()方法，当调用await()方法时，相当于同步队列的首节点（获取了锁的节点）移动到Condition的等待队列中。

ConditionObject的await方法

public final void await() throws InterruptedException {

if (Thread.interrupted())

throw new InterruptedException();

// 通过addConditionWaiter()方法把当前线程构造成一个新的节点并将其加入等待队列中

Node node = addConditionWaiter();

// 释放同步状态，也就是释放锁

int savedState = fullyRelease(node);

int interruptMode = 0;

//判断节点是否在同步队列

while (!isOnSyncQueue(node)) {

//在等待队列，进入等待

LockSupport.park(this);

if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)

break;

}

//调用同步器的acquireQueued()方法加入到获取同步状态的竞争中

if (acquireQueued(node, savedState) && interruptMode != THROW_IE)

我的面试宝典：一线互联网大厂Java核心面试题库

以下是我个人的一些做法，希望可以给各位提供一些帮助：

整理了很长一段时间，拿来复习面试刷题非常合适，其中包括了Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等，且还会持续的更新…可star一下！

283页的Java进阶核心pdf文档

Java部分：Java基础，集合，并发，多线程，JVM，设计模式

数据结构算法：Java算法，数据结构

开源框架部分：Spring，MyBatis，MVC，netty，tomcat

分布式部分：架构设计，Redis缓存，Zookeeper，kafka，RabbitMQ，负载均衡等

微服务部分：SpringBoot，SpringCloud，Dubbo，Docker

还有源码相关的阅读学习

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

checkInterruptWhileWaiting(node)) != 0)

break;

}

//调用同步器的acquireQueued()方法加入到获取同步状态的竞争中

if (acquireQueued(node, savedState) && interruptMode != THROW_IE)

我的面试宝典：一线互联网大厂Java核心面试题库

以下是我个人的一些做法，希望可以给各位提供一些帮助：

整理了很长一段时间，拿来复习面试刷题非常合适，其中包括了Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等，且还会持续的更新…可star一下！

[外链图片转存中…(img-zVFB7eFo-1713657798753)]

283页的Java进阶核心pdf文档

Java部分：Java基础，集合，并发，多线程，JVM，设计模式

数据结构算法：Java算法，数据结构

开源框架部分：Spring，MyBatis，MVC，netty，tomcat

分布式部分：架构设计，Redis缓存，Zookeeper，kafka，RabbitMQ，负载均衡等

微服务部分：SpringBoot，SpringCloud，Dubbo，Docker

[外链图片转存中…(img-zmgQwrVe-1713657798754)]

还有源码相关的阅读学习

[外链图片转存中…(img-zWCcufLw-1713657798754)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-y0tdr99U-1713657798755)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！