一、锁的分类
1.1 可重入锁、不可重入锁
Java 中提供的 synchronized、ReentrantLock、ReentrantReadWriteLock 都是可重入锁。
重入：当前线程获取到 A 锁，在获取之后尝试再次获取 A 锁是可以直接拿到的。
不可重入：当前线程获取到 A 锁，在获取之后尝试再次获取 A 锁，无法获取到的，因为 A 锁被当前线程占用着，需要等待自己释放锁再获取锁。
1.2 乐观锁、悲观锁
Java 中提供的 synchronized、ReentrantLock、ReentrantReadWriteLock 都是悲观锁。
Java 中提供的 CAS 操作，就是乐观锁的一种实现。
悲观锁：获取不到锁资源时，会将当前线程挂起（进入 BLOCKED、WAITING），线程挂起会涉及到用户态和内核的态的切换，而这种切换是比较消耗资源的。
- 用户态：JVM 可以自行执行的指令，不需要借助操作系统执行。
- 内核态：JVM 不可以自行执行，需要操作系统才可以执行。
乐观锁：获取不到锁资源，可以再次让 CPU 调度，重新尝试获取锁资源。Atomic 原子性类中，就是基于 CAS 乐观锁实现的。
1.3 公平锁、非公平锁
Java 中提供的 synchronized 只能是非公平锁。
Java 中提供的 ReentrantLock、ReentrantReadWriteLock 可以实现公平锁和非公平锁。
公平锁：线程 A 获取到了锁资源，线程 B 没有拿到，线程 B 去排队，线程 C 来了，锁被 A 持有，同时线程 B 在排队。直接排到 B 的后面，等待 B 拿到锁资源或者是 B 取消后，才可以尝试去竞争锁资源。
非公平锁：线程 A 获取到了锁资源，线程 B 没有拿到，线程 B 去排队，线程 C 来了，先尝试竞争，如果成功获取到了锁那么线程 C 就可以正常执行业务逻辑，如果没有拿到锁资源，依然要排到 B 的后面，等待 B 拿到锁资源或者是 B 取消后，才可以尝试去竞争锁资源。
1.4 互斥锁、共享锁
Java 中提供的 synchronized、ReentrantLock 是互斥锁。
Java 中提供的 ReentrantReadWriteLock，有互斥锁也有共享锁。
互斥锁：同一时间点，只会有一个线程持有者当前互斥锁。
共享锁：同一时间点，当前共享锁可以被多个线程同时持有。
二、synchronized
2.1 类锁、对象锁
synchronized 的使用一般就是同步方法和同步代码块。synchronized 的锁是基于对象实现的。
如果使用同步方法：
- static：此时使用的是当前类的字节码对象
OneClass.class作为锁（类锁）。 - 非 static：此时使用的是当前对象做为锁（对象锁）。
java
class Test {
public static synchronized void a() {
System.out.println("1111");
}
public synchronized void b() {
System.out.println("2222");
}
}
public class Main {
public static void main(String[] args) {
// 锁的是当前 Test.class
Test.a();
Test test = new Test();
// 锁的是 new 出来的 test 对象
test.b();
}
}2.2 synchronized优化
在 Java 5 的时候，Doug Lee 推出了 ReentrantLock，其性能远高于 synchronized 同步锁，所以 Java 团队就在 Java 6 中，对 synchronized 做了大量的优化。
锁消除 ：在 synchronized 修饰的代码中，如果不存在操作临界资源的情况，会触发锁消除。你即便写了 synchronized，它也不会触发加锁操作。
java
public synchronized void method() {
// 此方法没有操作临界资源
// 那么 synchronized 关键字可以忽略，不会触发获取锁的操作。
}锁膨胀：如果在一个循环中，频繁的获取和释放锁资源，这样带来的消耗很大。锁膨胀就是将锁的范围扩大，避免频繁的竞争和获取锁资源带来不必要的消耗。
java
public void method() {
for (int i = 0; i < 1_000_000; i++) {
synchronized(obj) {
// ...
}
}
// 上述代码会触发锁膨胀
synchronized (obj) {
for (int i = 0; i < 1_000_000; i++) {
// ...
}
}
}锁升级 ：ReentrantLock 的实现，是先基于乐观锁的 CAS 尝试获取锁资源，如果拿不到锁资源，才会挂起线程。synchronized 在 Java 6 之前，完全就是获取不到锁，立即挂起当前线程，所以 synchronized 性能比较差。
所以 synchronized 就在 Java 6 做了锁升级的优化。
-
无锁、匿名偏向：当前对象没有作为锁存在。
-
偏向锁：如果当前锁资源，只有一个线程在频繁的获取和释放，那么这个线程过来，只需要判断锁指向的线程是否是当前线程。
- 如果是，直接获取锁资源。
- 如果当前线程不是这个线程，基于 CAS 的方式，尝试将偏向锁指向当前线程。如果获取不到，触发锁升级，升级为轻量级锁。（偏向锁状态出现了锁竞争的情况）
-
轻量级锁 ：会采用自旋锁 的方式去频繁以 CAS 的形式获取锁资源（采用的是自适应自旋锁）
- 如果成功获取到，拿着锁资源走。
- 如果自旋了一定次数，没拿到锁资源，锁升级。
-
重量级锁 ：就是最传统的
synchronized方式，拿不到锁资源，就挂起当前线程。（用户态 -> 内核态）
2.3 synchronized原理
synchronized 是基于对象实现的，Java 对象在堆内存的存储如下：
MarkWord 对象字段如下：
MarkWord 中标记着四种锁的信息：无锁、偏向锁、轻量级锁、重量级锁。
2.4 synchronized锁升级
为了可以在 Java 中看到对象头的 MarkWord 信息，需要导入依赖：
xml
<dependency>
<groupId>org.openjdk.jol</groupId>
<artifactId>jol-core</artifactId>
<version>0.9</version>
</dependency>锁默认情况下，开启了偏向锁延迟。
偏向锁在升级为轻量级锁时，会涉及到偏向锁撤销，需要等到一个安全点（STW），才可以做偏向锁撤销，在明知道有并发情况，就可以选择不开启偏向锁，或者是设置偏向锁延迟开启。
因为 JVM 在启动时，需要加载大量的 .class 文件到内存中，这个操作会涉及到 synchronized 的使用，为了避免出现偏向锁撤销操作，JVM 启动初期，有一个延迟 4s 开启偏向锁的操作。
如果正常开启偏向锁了，那么不会出现无锁状态，对象会直接变为匿名偏向。
示例代码：
java
public static void main(String[] args) throws InterruptedException {
Thread.sleep(5000);
Object o = new Object();
System.out.println(ClassLayout.parseInstance(o).toPrintable());
new Thread(() -> {
synchronized (o) {
// t1 - 偏向锁
System.out.println("t1:" + ClassLayout.parseInstance(o).toPrintable());
}
}).start();
// main - 偏向锁 - 轻量级锁CAS - 重量级锁
synchronized (o) {
System.out.println("main: " + ClassLayout.parseInstance(o).toPrintable());
}
}
整个锁升级状态的转变：
Lock Record 以及 ObjectMonitor 存储的内容：
2.5 ObjectMonitor
想要知道 ObjectMonitor 原理，那就有必要了解一下它的源码实现，链接如下：
hg.openjdk.java.net/jdk8u/jdk8u...
找到 ObjectMonitor 的两个文件，一个头文件还有一个源文件。
先查看核心属性：
cpp
ObjectMonitor() {
_header = NULL; // header 存储着 MarkWord
_count = 0; // 竞争锁的线程个数
_waiters = 0, // wait 的线程个数
_recursions = 0; // 标识当前 synchronized 锁重入的次数
_object = NULL;
_owner = NULL; // 持有锁的线程
_WaitSet = NULL; // 保存 wait 的线程信息，双向链表
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ; // 获取锁资源失败后，线程要放到当前的单向链表中
FreeNext = NULL ;
_EntryList = NULL ; // _cxq 以及被唤醒的 WaitSet 中的线程，在一定机制下，会放到 EntryList 中
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
_previous_owner_tid = 0;
}几个 C++ 中实现的加锁流程，链接如下：
hg.openjdk.java.net/jdk8u/jdk8u...
TryLock：
cpp
int ObjectMonitor::TryLock (Thread * Self) {
for (;;) {
void * own = _owner ;
if (own != NULL) return 0 ;
// 说明没有线程持有锁，own 是 null，cmpxchg 指令就是底层的 CAS 实现。
if (Atomic::cmpxchg_ptr (Self, &_owner, NULL) == NULL) {
// Either guarantee _recursions == 0 or set _recursions = 0.
assert (_recursions == 0, "invariant") ;
assert (_owner == Self, "invariant") ;
// CONSIDER: set or assert that OwnerIsThread == 1
return 1 ;
}
// The lock had been free momentarily, but we lost the race to the lock.
// Interference -- the CAS failed.
// We can either return -1 or retry.
// Retry doesn't make as much sense because the lock was just acquired.
if (true) return -1 ;
}
}try_enter：
cpp
bool ObjectMonitor::try_enter(Thread* THREAD) {
// 在判断 _owner 是不是当前线程
if (THREAD != _owner) {
// 判断当前持有锁的线程是否是当前线程，说明轻量级锁刚刚升级过来的情况
if (THREAD->is_lock_owned ((address)_owner)) {
assert(_recursions == 0, "internal state error");
_owner = THREAD ;
_recursions = 1 ;
OwnerIsThread = 1 ;
return true;
}
// CAS操作，尝试获取锁资源
if (Atomic::cmpxchg_ptr (THREAD, &_owner, NULL) != NULL) {
// 没拿到锁资源，告辞
return false;
}
// 拿到锁资源
return true;
} else {
// 将 _recursions + 1，代表锁重入操作。
_recursions++;
return true;
}
}enter：想方设法拿到锁资源，如果没拿到，挂起扔到 _cxq 单向链表中。
cpp
void ATTR ObjectMonitor::enter(TRAPS) {
// 拿到当前线程
Thread * const Self = THREAD ;
void * cur ;
// CAS走你，
cur = Atomic::cmpxchg_ptr (Self, &_owner, NULL) ;
if (cur == NULL) {
// 拿锁成功
return ;
}
// 锁重入操作
if (cur == Self) {
// TODO-FIXME: check for integer overflow! BUGID 6557169.
_recursions ++ ;
return ;
}
// 轻量级锁过来的。
if (Self->is_lock_owned ((address)cur)) {
_recursions = 1 ;
_owner = Self ;
OwnerIsThread = 1 ;
return ;
}
// 走到这了，没拿到锁资源，count++
Atomic::inc_ptr(&_count);
{
// ...
for (;;) {
jt->set_suspend_equivalent();
// 入队操作，进到cxq中
EnterI (THREAD) ;
if (!ExitSuspendEquivalent(jt)) break ;
_recursions = 0 ;
_succ = NULL ;
exit (false, Self) ;
jt->java_suspend_self();
}
// ...
}
// count--
Atomic::dec_ptr(&_count);
}EnterI：
cpp
for (;;) {
// 入队
node._next = nxt = _cxq ;
// CAS的方式入队。
if (Atomic::cmpxchg_ptr (&node, &_cxq, nxt) == nxt) break ;
// 重新尝试获取锁资源
if (TryLock (Self) > 0) {
assert (_succ != Self , "invariant") ;
assert (_owner == Self , "invariant") ;
assert (_Responsible != Self , "invariant") ;
return ;
}
}三、ReentrantLock
3.1 与synchronized区别
核心区别：ReentrantLock 是个类，synchronized 是关键字，当然都是在 JVM 层面实现互斥锁的方式。
效率区别：如果竞争比较激烈，推荐 ReentrantLock 去实现，不存在锁升级概念。而 synchronized 是存在锁升级概念的，如果升级到重量级锁，是不存在锁降级的。
底层实现区别：实现原理是不一样，ReentrantLock 基于 AQS 实现的，synchronized 是基于 ObjectMonitor。
功能向的区别：
ReentrantLock支持公平锁和非公平锁。ReentrantLock可以指定等待锁资源的时间。
如果你对并发编程特别熟练，推荐使用 ReentrantLock，功能更丰富。如果掌握的一般般，使用 synchronized 会更好。
3.2 AQS概述
AQS 就是 AbstractQueuedSynchronizer 抽象类，AQS 其实就是 JUC 包下的一个基类，JUC 下的很多内容都是基于 AQS 实现了部分功能，比如 ReentrantLock，ThreadPoolExecutor，阻塞队列，CountDownLatch，Semaphore，CyclicBarrier 等等都是基于 AQS 实现。
首先 AQS 中提供了一个由 volatile 修饰，并且采用 CAS 方式修改的 int 类型的 state 变量。其次 AQS 中维护了一个双向链表，有 head，有 tail，并且每个节点都是 Node 对象。
java
static final class Node {
static final Node SHARED = new Node();
static final Node EXCLUSIVE = null;
static final int CANCELLED = 1;
static final int SIGNAL = -1;
static final int CONDITION = -2;
static final int PROPAGATE = -3;
volatile int waitStatus;
volatile Node prev;
volatile Node next;
volatile Thread thread;
}AQS 内部结构和属性：
3.3 加锁流程分析
3.3.1 加锁流程概述
这个是非公平锁的流程：
3.3.2 三种加锁源码分析
3.3.2.1 lock方法
执行 lock 方法后，公平锁和非公平锁的执行套路不一样：
java
// 非公平锁
final void lock() {
// 上来就先基于CAS 的方式，尝试将 state 从 0 改为 1
if (compareAndSetState(0, 1))
// 获取锁资源成功，会将当前线程设置到 exclusiveOwnerThread 属性，代表是当前线程持有着锁资源
setExclusiveOwnerThread(Thread.currentThread());
else
// 执行acquire，尝试获取锁资源
acquire(1);
}
// 公平锁
final void lock() {
// 执行 acquire，尝试获取锁资源
acquire(1);
}acquire 方法，是公平锁和非公平锁的逻辑一样：
java
public final void acquire(int arg) {
// tryAcquire：再次查看，当前线程是否可以尝试获取锁资源
if (!tryAcquire(arg) &&
// 没有拿到锁资源
// addWaiter(Node.EXCLUSIVE)：将当前线程封装为Node节点，插入到AQS的双向链表的结尾
// acquireQueued：查看我是否是第一个排队的节点，如果是可以再次尝试获取锁资源，如果长时间拿不到，挂起线程
// 如果不是第一个排队的额节点，就尝试挂起线程即可
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
// 中断线程的操作
selfInterrupt();
}tryAcquire 方法竞争锁最资源的逻辑，分为公平锁和非公平锁：
java
// 非公平锁实现
final boolean nonfairTryAcquire(int acquires) {
// 获取当前线程
final Thread current = Thread.currentThread();
// 获取了state熟属性
int c = getState();
// 判断state当前是否为0,之前持有锁的线程释放了锁资源
if (c == 0) {
// 再次抢一波锁资源
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
// 拿锁成功返回true
return true;
}
}
// 不是0，有线程持有着锁资源，如果是，证明是锁重入操作
else if (current == getExclusiveOwnerThread()) {
// 将state + 1
int nextc = c + acquires;
if (nextc < 0) // 说明对重入次数+1后，超过了int正数的取值范围
// 01111111 11111111 11111111 11111111
// 10000000 00000000 00000000 00000000
// 说明重入的次数超过界限了。
throw new Error("Maximum lock count exceeded");
// 正常的将计算结果，复制给state
setState(nextc);
// 锁重入成功
return true;
}
// 返回 false
return false;
}
java
// 公平锁实现
protected final boolean tryAcquire(int acquires) {
// 获取当前线程
final Thread current = Thread.currentThread();
// ....
int c = getState();
if (c == 0) {
// 查看 AQS 中是否有排队的 Node
// 没人排队抢一手 。有人排队，如果我是第一个，也抢一手
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;
}
// 查看是否有线程在 AQS 的双向队列中排队
// 返回 false，代表没人排队
public final boolean hasQueuedPredecessors() {
// 头尾节点
Node t = tail;
Node h = head;
// s为头结点的next节点
Node s;
// 如果头尾节点相等，证明没有线程排队，直接去抢占锁资源
return h != t &&
// s节点不为null，并且s节点的线程为当前线程（排在第一名的是不是我）
(s == null || s.thread != Thread.currentThread());
}addWaiter 方法，将没有拿到锁资源的线程扔到 AQS 队列中去排队：
java
// 没有拿到锁资源，过来排队，mode：代表互斥锁
private Node addWaiter(Node mode) {
// 将当前线程封装为Node，
Node node = new Node(Thread.currentThread(), mode);
// 拿到尾结点
Node pred = tail;
// 如果尾结点不为null
if (pred != null) {
// 当前节点的prev指向尾结点
node.prev = pred;
// 以CAS的方式，将当前线程设置为tail节点
if (compareAndSetTail(pred, node)) {
// 将之前的尾结点的next指向当前节点
pred.next = node;
return node;
}
}
// 如果CAS失败，以死循环的方式，保证当前线程的Node一定可以放到AQS队列的末尾
enq(node);
return node;
}
private Node enq(final Node node) {
for (;;) {
// 拿到尾结点
Node t = tail;
// 如果尾结点为空，AQS中一个节点都没有，构建一个伪节点，作为head和tail
if (t == null) {
if (compareAndSetHead(new Node()))
tail = head;
} else {
// 比较熟悉了，以CAS的方式，在AQS中有节点后，插入到AQS队列的末尾
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}acquireQueued 方法，判断当前线程是否还能再次尝试获取锁资源，如果不能再次获取锁资源，或者又没获取到，尝试将当前线程挂起。
java
// 当前没有拿到锁资源后，并且到AQS排队了之后触发的方法。 中断操作这里不用考虑
final boolean acquireQueued(final Node node, int arg) {
// 不考虑中断
// failed：获取锁资源是否失败（这里简单掌握落地，真正触发的，还是tryLock和lockInterruptibly）
boolean failed = true;
try {
boolean interrupted = false;
// 死循环............
for (;;) {
// 拿到当前节点的前继节点
final Node p = node.predecessor();
// 前继节点是否是head，如果是head，再次执行tryAcquire尝试获取锁资源。
if (p == head && tryAcquire(arg)) {
// 获取锁资源成功
// 设置头结点为当前获取锁资源成功Node，并且取消thread信息
setHead(node);
// help GC
p.next = null;
// 获取锁失败标识为false
failed = false;
return interrupted;
}
// 没拿到锁资源......
// shouldParkAfterFailedAcquire：基于上一个节点转改来判断当前节点是否能够挂起线程，如果可以返回true，
// 如果不能，就返回false，继续下次循环
if (shouldParkAfterFailedAcquire(p, node) &&
// 这里基于Unsafe类的park方法，将当前线程挂起
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
// 在lock方法中，基本不会执行。
cancelAcquire(node);
}
}
// 获取锁资源成功后，先执行setHead
private void setHead(Node node) {
// 当前节点作为头结点 伪
head = node;
// 头结点不需要线程信息
node.thread = null;
node.prev = null;
}
// 当前Node没有拿到锁资源，或者没有资格竞争锁资源，看一下能否挂起当前线程
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
// -1，SIGNAL状态：代表当前节点的后继节点，可以挂起线程，后续我会唤醒我的后继节点
// 1，CANCELLED状态：代表当前节点以及取消了
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
// 上一个节点为-1之后，当前节点才可以安心的挂起线程
return true;
if (ws > 0) {
// 如果当前节点的上一个节点是取消状态，我需要往前找到一个状态不为1的Node，作为他的next节点
// 找到状态不为1的节点后，设置一下next和prev
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
// 上一个节点的状态不是1或者-1，那就代表节点状态正常，将上一个节点的状态改为-1
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}3.3.2.2 tryLock方法
java
// tryLock 方法，无论公平锁还有非公平锁。都会走非公平锁抢占锁资源的操作
// 就是拿到 state 的值， 如果是 0，直接 CAS 浅尝一下
// state 不是 0，那就看下是不是锁重入操作
// 如果没抢到，或者不是锁重入操作，告辞，返回 false。
public boolean tryLock() {
// 非公平锁的竞争锁操作
return sync.nonfairTryAcquire(1);
}
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()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}tryLock(time,unit) 方法：
java
// tryLock(time,unit)执行的方法
public final boolean tryAcquireNanos(int arg, long nanosTimeout)throws InterruptedException {
// 线程的中断标记位，是不是从false，别改为了true，如果是，直接抛异常
if (Thread.interrupted())
throw new InterruptedException();
// tryAcquire分为公平和非公平锁两种执行方式，如果拿锁成功， 直接告辞，
return tryAcquire(arg) ||
// 如果拿锁失败，在这要等待指定时间
doAcquireNanos(arg, nanosTimeout);
}
private boolean doAcquireNanos(int arg, long nanosTimeout)
throws InterruptedException {
// 如果等待时间是0秒，直接告辞，拿锁失败
if (nanosTimeout <= 0L)
return false;
// 设置结束时间。
final long deadline = System.nanoTime() + nanosTimeout;
// 先扔到AQS队列
final Node node = addWaiter(Node.EXCLUSIVE);
// 拿锁失败，默认true
boolean failed = true;
try {
for (;;) {
// 如果在AQS中，当前node是head的next，直接抢锁
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return true;
}
// 结算剩余的可用时间
nanosTimeout = deadline - System.nanoTime();
// 判断是否是否用尽的位置
if (nanosTimeout <= 0L)
return false;
// shouldParkAfterFailedAcquire：根据上一个节点来确定现在是否可以挂起线程
if (shouldParkAfterFailedAcquire(p, node) &&
// 避免剩余时间太少，如果剩余时间少就不用挂起线程
nanosTimeout > spinForTimeoutThreshold)
// 如果剩余时间足够，将线程挂起剩余时间
LockSupport.parkNanos(this, nanosTimeout);
// 如果线程醒了，查看是中断唤醒的，还是时间到了唤醒的。
if (Thread.interrupted())
// 是中断唤醒的！
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}取消节点分析：
java
// 取消在 AQS 中排队的 Node
private void cancelAcquire(Node node) {
// 如果当前节点为null，直接忽略。
if (node == null)
return;
//1. 线程设置为null
node.thread = null;
//2. 往前跳过被取消的节点，找到一个有效节点
Node pred = node.prev;
while (pred.waitStatus > 0)
node.prev = pred = pred.prev;
//3. 拿到了上一个节点之前的next
Node predNext = pred.next;
//4. 当前节点状态设置为1，代表节点取消
node.waitStatus = Node.CANCELLED;
// 脱离AQS队列的操作
// 当前Node是尾结点，将tail从当前节点替换为上一个节点
if (node == tail && compareAndSetTail(node, pred)) {
compareAndSetNext(pred, predNext, null);
} else {
// 到这，上面的操作CAS操作失败
int ws = pred.waitStatus;
// 不是head的后继节点
if (pred != head &&
// 拿到上一个节点的状态，只要上一个节点的状态不是取消状态，就改为-1
(ws == Node.SIGNAL || (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL)))
&& pred.thread != null) {
// 上面的判断都是为了避免后面节点无法被唤醒。
// 前继节点是有效节点，可以唤醒后面的节点
Node next = node.next;
if (next != null && next.waitStatus <= 0)
compareAndSetNext(pred, predNext, next);
} else {
// 当前节点是head的后继节点
unparkSuccessor(node);
}
node.next = node; // help GC
}
}3.3.2.3 lockInterruptibly方法
java
// 这个是lockInterruptibly和tryLock(time,unit)唯一的区别
// lockInterruptibly，拿不到锁资源，就死等，等到锁资源释放后，被唤醒，或者是被中断唤醒
private void doAcquireInterruptibly(int arg) throws InterruptedException {
final Node node = addWaiter(Node.EXCLUSIVE);
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return;
}
if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt())
// 中断唤醒抛异常！
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
// 这个方法可以确认，当前挂起的线程，是被中断唤醒的，还是被正常唤醒的。
// 中断唤醒，返回true，如果是正常唤醒，返回false
return Thread.interrupted();
}3.4 释放锁流程分析
3.4.1 释放锁流程概述
3.4.2 释放锁源码分析
java
public void unlock() {
// 释放锁资源不分为公平锁和非公平锁，都是一个sync对象
sync.release(1);
}
// 释放锁的核心流程
public final boolean release(int arg) {
// 核心释放锁资源的操作之一
if (tryRelease(arg)) {
// 如果锁已经释放掉了，走这个逻辑
Node h = head;
// h不为null，说明有排队的
// 如果h的状态不为0（为-1），说明后面有排队的Node，并且线程已经挂起了。
if (h != null && h.waitStatus != 0)
// 唤醒排队的线程
unparkSuccessor(h);
return true;
}
return false;
}
// ReentrantLock释放锁资源操作
protected final boolean tryRelease(int releases) {
// 拿到state - 1（并没有赋值给state）
int c = getState() - releases;
// 判断当前持有锁的线程是否是当前线程，如果不是，直接抛出异常
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
// free，代表当前锁资源是否释放干净了。
boolean free = false;
if (c == 0) {
// 如果state - 1后的值为0，代表释放干净了。
free = true;
// 将持有锁的线程置位null
setExclusiveOwnerThread(null);
}
// 将c设置给state
setState(c);
// 锁资源释放干净返回true，否则返回false
return free;
}
// 唤醒后面排队的Node
private void unparkSuccessor(Node node) {
// 拿到头节点状态
int ws = node.waitStatus;
if (ws < 0)
// 先基于CAS，将节点状态从-1，改为0
compareAndSetWaitStatus(node, ws, 0);
// 拿到头节点的后续节点。
Node s = node.next;
// 如果后续节点为null或者，后续节点的状态为1，代表节点取消了。
if (s == null || s.waitStatus > 0) {
s = null;
// 如果后续节点为null，或者后续节点状态为取消状态，从后往前找到一个有效节点环境
for (Node t = tail; t != null && t != node; t = t.prev)
// 从后往前找到状态小于等于0的节点
// 找到离head最新的有效节点，并赋值给s
if (t.waitStatus <= 0)
s = t;
}
// 只要找到了这个需要被唤醒的节点，执行unpark唤醒
if (s != null)
LockSupport.unpark(s.thread);
}3.5 AQS中常见问题
3.5.1 AQS为什么要有一个虚拟head节点
AQS 可以没有 head，设计之初指定 head 只是为了更方便的操作。方便管理双向链表而已，一个哨兵节点的存在。
比如 ReentrantLock 中释放锁资源时，会考虑是否需要唤醒后继节点。如果头结点的状态不是 -1。就不需要去唤醒后继节点。唤醒后继节点时，需要找到 head.next 节点，如果 head.next 为 null，或者是取消了，此时需要遍历整个双向链表，从后往前遍历，找到离 head 最近的 Node。规避了一些不必要的唤醒操作。
如果不用虚拟节点（哨兵节点），当前节点挂起，当前节点的状态设置为 -1。可行。AQS 本身就是使用了哨兵节点做双向链表的一些操作。
网上说了，虚拟的 head，可以避免重复唤醒操作。虚拟的 head 并没有处理这个问题。
3.5.2 AQS为什么使用双向链表
AQS 的双向链表就为了更方便的操作 Node 节点。
在执行 tryLock 和 lockInterruptibly 方法时，如果在线程阻塞时，中断了线程，此时线程会执行 cancelAcquire 取消当前节点，不在 AQS 的双向链表中排队。如果是单向链表，此时会导致取消节点，无法直接将当前节点的 prev 节点的 next 指针，指向当前节点的 next 节点。
3.6 ConditionObject
3.6.1 概念介绍
像 synchronized 提供了 wait 和 notify 的方法实现线程在持有锁时，可以实现挂起，已经唤醒的操作。
Condition 也拥有这个功能。Condition 提供了 await 和 signal 方法去实现类似 wait 和 notify 的功能。想执行 await 或者是 signal 方法，那么线程就必须先持有 lock 锁的资源。
Condition 的应用：
java
public static void main(String[] args) throws InterruptedException, IOException {
ReentrantLock lock = new ReentrantLock();
Condition condition = lock.newCondition();
new Thread(() -> {
lock.lock();
System.out.println("子线程获取锁资源并await挂起线程");
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
try {
condition.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("子线程挂起后被唤醒！持有锁资源");
}).start();
Thread.sleep(100);
// =================main======================
lock.lock();
System.out.println("主线程等待5s拿到锁资源，子线程执行了await方法");
condition.signal();
System.out.println("主线程唤醒了await挂起的子线程");
lock.unlock();
}3.6.2 核心属性
发现在通过 lock 锁对象执行 newCondition 方法时，本质就是直接 new 的 AQS 提供的 ConditionObject 对象。
java
final ConditionObject newCondition() {
return new ConditionObject();
}其实 lock 锁中可以有多个 Condition 对象。在对 Condition1 进行操作时，不会影响到 Condition2 的单向链表。其次可以发现 ConditionObject 中，只有两个核心属性：
java
/** First node of condition queue. */
private transient Node firstWaiter;
/** Last node of condition queue. */
private transient Node lastWaiter;虽然 Node 对象有 prev 和 next，但是在 ConditionObject 中是不会使用这两个属性的，只要在 Condition 队列中，这两个属性都是 null。在 ConditionObject 中只会使用 nextWaiter 的属性实现单向链表的效果。
3.6.3 await方法前置分析
持有锁的线程在执行 await 方法后会做几个操作：
- 判断线程是否中断，如果中断了，什么都不做。
- 没有中断，就讲当前线程封装为
Node添加到Condition的单向链表中。 - 一次性释放掉锁资源。
- 如果当前线程没有在 AQS 队列，就正常执行
LockSupport.park(this)挂起线程。
java
// await方法的前置分析，只分析到线程挂起
public final void await() throws InterruptedException {
// 先判断线程的中断标记位是否是 true
if (Thread.interrupted())
// 如果是true，就没必要执行后续操作挂起了。
throw new InterruptedException();
// 在线程挂起之前，先将当前线程封装为Node，并且添加到Condition队列中
Node node = addConditionWaiter();
// fullyRelease在释放锁资源，一次性将锁资源全部释放，并且保留重入的次数
int savedState = fullyRelease(node);
// 省略一行代码......
// 当前Node是否在AQS队列中？
// 执行fullyRelease方法后，线程就释放锁资源了，如果线程刚刚释放锁资源，其他线程就立即执行了signal方法，
// 此时当前线程就被放到了AQS的队列中，这样一来线程就不需要执行LockSupport.park(this);去挂起线程了
while (!isOnSyncQueue(node)) {
// 如果没有在AQS队列中，正常在Condition单向链表里，正常挂起线程。
LockSupport.park(this);
// 省略部分代码......
}
// 省略部分代码......
}
// 线程挂起先，添加到Condition单向链表的业务~~
private Node addConditionWaiter() {
// 拿到尾节点。
Node t = lastWaiter;
// 如果尾节点有值，并且尾节点的状态不正常，不是-2，尾节点可能要拜拜了~
if (t != null && t.waitStatus != Node.CONDITION) {
// 如果尾节点已经取消了，需要干掉取消的尾节点~
unlinkCancelledWaiters();
// 重新获取lastWaiter
t = lastWaiter;
}
// 构建当前线程的Node，并且状态设置为-2
Node node = new Node(Thread.currentThread(), Node.CONDITION);
// 如果last节点为null。直接将当前节点设置为firstWaiter
if (t == null)
firstWaiter = node;
else
// 如果last节点不为null，说明有值，就排在lastWaiter的后面
t.nextWaiter = node;
// 把当前节点设置为最后一个节点
lastWaiter = node;
// 返回当前节点
return node;
}
// 干掉取消的尾节点。
private void unlinkCancelledWaiters() {
// 拿到头节点
Node t = firstWaiter;
// 声明一个节点，爱啥啥~~~
Node trail = null;
// 如果t不为null，就正常执行~~
while (t != null) {
// 拿到t的next节点
Node next = t.nextWaiter;
// 如果t的状态不为-2，说明有问题
if (t.waitStatus != Node.CONDITION) {
// t节点的next为null
t.nextWaiter = null;
// 如果trail为null，代表头结点状态就是1，
if (trail == null)
// 将头结点指向next节点
firstWaiter = next;
else
// 如果trail有值，说明不是头结点位置
trail.nextWaiter = next;
// 如果next为null，说明单向链表遍历到最后了，直接结束
if (next == null)
lastWaiter = trail;
}
// 如果t的状态是-2，一切正常
else {
// 临时存储t
trail = t;
}
// t指向之前的next
t = next;
}
}
// 一次性释放锁资源
final int fullyRelease(Node node) {
// 标记位，释放锁资源默认失败！
boolean failed = true;
try {
// 拿到现在state的值
int savedState = getState();
// 一次性释放干净全部锁资源
if (release(savedState)) {
// 释放锁资源失败了么？ 没有！
failed = false;
// 返回对应的锁资源信息
return savedState;
} else {
throw new IllegalMonitorStateException();
}
} finally {
if (failed)
// 如果释放锁资源失败，将节点状态设置为取消
node.waitStatus = Node.CANCELLED;
}
}3.6.4 signal方法
分为了几个部分：
- 确保执行
signal方法的是持有锁的线程。 - 脱离
Condition的队列。 - 将
Node状态从-2改为0。 - 将
Node添加到 AQS 队列。 - 为了避免当前
Node无法在 AQS 队列正常唤醒做了一些判断和操作。
java
// 线程挂起后，可以基于 signal 唤醒
public final void signal() {
// 在ReentrantLock中，如果执行signal的线程没有持有锁资源，直接扔异常
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
// 拿到排在Condition首位的Node
Node first = firstWaiter;
// 有Node在排队，才需要唤醒，如果没有，直接告辞~~
if (first != null)
doSignal(first);
}
// 开始唤醒Condition中的Node中的线程
private void doSignal(Node first) {
do {
// 获取到第二个节点，并且将第二个节点设置为firstWaiter
if ((firstWaiter = first.nextWaiter) == null)
// 说明就一个节点在Condition队列中，那么直接将firstWaiter和lastWaiter置为 null
lastWaiter = null;
// 如果还有nextWaiter节点，因为当前节点要被唤醒了，脱离整个Condition队列。将nextWaiter置为null
first.nextWaiter = null;
// 如果transferForSignal返回true，一切正常，退出while循环
} while (!transferForSignal(first) &&
// 如果后续节点还有，往后面继续唤醒，如果没有，退出while循环
(first = firstWaiter) != null);
}
// 准备开始唤醒在Condition中排队的Node
final boolean transferForSignal(Node node) {
// 将在Condition队列中的Node的状态从-2，改为0，代表要扔到AQS队列了。
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
// 如果失败了，说明在signal之前应当是线程被中断了，从而被唤醒了。
return false;
// 如果正常的将Node的状态从-2改为0，这是就要将Condition中的这个Node扔到AQS的队列。
// 将当前Node扔到AQS队列，返回的p是当前Node的prev
Node p = enq(node);
// 获取上一个Node的状态
int ws = p.waitStatus;
// 如果ws > 0 ，说明这个Node已经被取消了。
// 如果ws状态不是取消，将prev节点的状态改为-1,。
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
// 如果prev节点已经取消了，可能会导致当前节点永远无法被唤醒。立即唤醒当前节点，基于acquireQueued方法，
// 让当前节点找到一个正常的prev节点，并挂起线程
// 如果prev节点正常，但是CAS修改prev节点失败了。证明prev节点因为并发原因导致状态改变。还是为了避免当前
// 节点无法被正常唤醒，提前唤醒当前线程，基于acquireQueued方法，让当前节点找到一个正常的prev节点，并挂起线程
LockSupport.unpark(node.thread);
// 返回true
return true;
}3.6.5 await方法后置分析
分为几个部分：
- 唤醒之后，要先确认是中断唤醒还是
signal唤醒，还是signal唤醒后被中断。 - 确保当前线程的
Node已经在 AQS 队列中。 - 执行
acquireQueued方法，等待锁资源。 - 在获取锁资源后，要确认是否在获取锁资源的阶段被中断过，如果被中断过，并且不是
THROW_IE，那就确保interruptMode是REINTERRUPT。 - 确认当前
Node已经不在Condition队列中了 - 最终根据
interruptMode来决定具体做的事情：- 0：do nothing
- THROW_IE：抛出异常
- REINTERRUPT：执行线程的 interrupt 方法
java
// 现在分析await方法的后半部分
public final void await() throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
Node node = addConditionWaiter();
int savedState = fullyRelease(node);
// 中断模式~
int interruptMode = 0;
while (!isOnSyncQueue(node)) {
LockSupport.park(this);
// 如果线程执行到这，说明现在被唤醒了。
// 线程可以被signal唤醒。（如果是signal唤醒，可以确认线程已经在AQS队列中）
// 线程可以被interrupt唤醒，线程被唤醒后，没有在AQS队列中。
// 如果线程先被signal唤醒，然后线程中断了。。。。（做一些额外处理）
// checkInterruptWhileWaiting可以确认当前中如何唤醒的。
// 返回的值，有三种
// 0：正常signal唤醒，没别的事（不知道Node是否在AQS队列）
// THROW_IE（-1）：中断唤醒，并且可以确保在AQS队列
// REINTERRUPT（1）：signal唤醒，但是线程被中断了，并且可以确保在AQS队列
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
// Node一定在AQS队列
// 执行acquireQueued，尝试在ReentrantLock中获取锁资源。
// acquireQueued方法返回true：代表线程在AQS队列中挂起时，被中断过
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
// 如果线程在AQS队列排队时，被中断了，并且不是THROW_IE状态，确保线程的interruptMode是REINTERRUPT
// REINTERRUPT：await不是中断唤醒，但是后续被中断过！！！
interruptMode = REINTERRUPT;
// 如果当前Node还在condition的单向链表中，脱离Condition的单向链表
if (node.nextWaiter != null)
unlinkCancelledWaiters();
// 如果interruptMode是0，说明线程在signal后以及持有锁的过程中，没被中断过，什么事都不做！
if (interruptMode != 0)
// 如果不是0~
reportInterruptAfterWait(interruptMode);
}
// 判断当前线程被唤醒的模式，确认interruptMode的值。
private int checkInterruptWhileWaiting(Node node) {
// 判断线程是否中断了。
return Thread.interrupted() ?
// THROW_IE：代表线程是被interrupt唤醒的，需要向上排除异常
// REINTERRUPT：代表线程是signal唤醒的，但是在唤醒之后，被中断了。
(transferAfterCancelledWait(node) ? THROW_IE : REINTERRUPT) :
// 线程是正常的被signal唤醒，并且线程没有中断过。
0;
}
// 判断线程到底是中断唤醒的，还是signal唤醒的！
final boolean transferAfterCancelledWait(Node node) {
// 基于CAS将Node的状态从-2改为0
if (compareAndSetWaitStatus(node, Node.CONDITION, 0)) {
// 说明是中断唤醒的线程。因为CAS成功了。
// 将Node添加到AQS队列中~（如果是中断唤醒的，当前线程同时存在Condition的单向链表以及AQS的队列中）
enq(node);
// 返回true
return true;
}
// 判断当前的Node是否在AQS队列（signal唤醒的，但是可能线程还没放到AQS队列）
// 等到signal方法将线程的Node扔到AQS队列后，再做后续操作
while (!isOnSyncQueue(node))
// 如果没在AQS队列上，那就线程让步，稍等一会，Node放到AQS队列再处理（看CPU）
Thread.yield();
// signal唤醒的，返回false
return false;
}
// 确认Node是否在AQS队列上
final boolean isOnSyncQueue(Node node) {
// 如果线程状态为-2，肯定没在AQS队列
// 如果prev节点的值为null，肯定没在AQS队列
if (node.waitStatus == Node.CONDITION || node.prev == null)
// 返回false
return false;
// 如果节点的next不为null。说明已经在AQS队列上。、
if (node.next != null)
// 确定AQS队列上有！
return true;
// 如果上述判断都没有确认节点在AQS队列上，在AQS队列中寻找一波
return findNodeFromTail(node);
}
// 在AQS队列中找当前节点
private boolean findNodeFromTail(Node node) {
// 拿到尾节点
Node t = tail;
for (;;) {
// tail是否是当前节点，如果是，说明在AQS队列
if (t == node)
// 可以跳出while循环
return true;
// 如果节点为null，AQS队列中没有当前节点
if (t == null)
// 进入while，让步一手
return false;
// t向前引用
t = t.prev;
}
}
private void reportInterruptAfterWait(int interruptMode) throws InterruptedException {
// 如果是中断唤醒的await，直接抛出异常！
if (interruptMode == THROW_IE)
throw new InterruptedException();
// 如果是REINTERRUPT，signal后被中断过
else if (interruptMode == REINTERRUPT)
// 确认线程的中断标记位是true
// Thread.currentThread().interrupt();
selfInterrupt();
}3.6.6 awaitNanos & signalAll方法分析
awaitNanos：仅仅是在 await 方法的基础上，做了一内内的改变，整体的逻辑思想都是一样的。挂起线程时，传入要阻塞的时间，时间到了，自动唤醒，走添加到 AQS 队列的逻辑。
java
// await 指定时间，多了个时间到了自动醒。
public final long awaitNanos(long nanosTimeout)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
Node node = addConditionWaiter();
int savedState = fullyRelease(node);
// deadline：当前线程最多挂起到什么时间点
final long deadline = System.nanoTime() + nanosTimeout;
int interruptMode = 0;
while (!isOnSyncQueue(node)) {
// nanosTimeout的时间小于等于0，直接告辞！！
if (nanosTimeout <= 0L) {
// 正常扔到AQS队列
transferAfterCancelledWait(node);
break;
}
// nanosTimeout的时间大于1000纳秒时，才可以挂起线程
if (nanosTimeout >= spinForTimeoutThreshold)
// 如果大于，正常挂起
LockSupport.parkNanos(this, nanosTimeout);
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
// 计算剩余的挂起时间，可能需要重新的走while循环，再次挂起线程
nanosTimeout = deadline - System.nanoTime();
}
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
if (node.nextWaiter != null)
unlinkCancelledWaiters();
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
// 剩余的挂起时间
return deadline - System.nanoTime();
}signalAll 方法。这个方法一看就懂，之前 signal 是唤醒 1 个，这个是全部唤醒。
java
// 以 do-while 的形式，将Condition单向链表中的所有 Node，全部唤醒并扔到 AQS 队列
private void doSignalAll(Node first) {
// 将头尾都置位 null
lastWaiter = firstWaiter = null;
do {
// 拿到next节点的引用
Node next = first.nextWaiter;
// 断开当前Node的nextWaiter
first.nextWaiter = null;
// 修改Node状态，扔AQS队列，是否唤醒！
transferForSignal(first);
// 指向下一个节点
first = next;
} while (first != null);
}四、ReentrantReadWriteLock
4.1 为什么要使用读写锁
synchronized 和 ReentrantLock 都是互斥锁。如果说有一个操作是读多写少的，还要保证线程安全的话。如果采用上述的两种互斥锁，效率方面很定是很低的。
在这种情况下，咱们就可以使用 ReentrantReadWriteLock 读写锁去实现。读读之间是不互斥的，可以读和读操作并发执行。但是如果涉及到了写操作，那么还得是互斥的操作。
java
import java.util.concurrent.locks.ReentrantReadWriteLock;
public class Main {
static ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
static ReentrantReadWriteLock.WriteLock writeLock = lock.writeLock();
static ReentrantReadWriteLock.ReadLock readLock = lock.readLock();
public static void main(String[] args) throws InterruptedException {
new Thread(() -> {
readLock.lock();
try {
System.out.println("子线程！");
try {
Thread.sleep(500000);
} catch (InterruptedException e) {
e.printStackTrace();
}
} finally {
readLock.unlock();
}
}).start();
Thread.sleep(1000);
writeLock.lock();
try {
System.out.println("主线程！");
} finally {
writeLock.unlock();
}
}
}代码中主线程被阻塞的原因是写锁（writeLock）在主线程中获取时被阻塞了，因为子线程持有了读锁（readLock）并且睡眠了很长时间（500000毫秒，即500秒）。
具体来说，ReentrantReadWriteLock 的写锁需要等待所有的读锁释放后才能获得，而你的子线程一直持有读锁且没有释放（因为睡眠期间没有释放锁），导致主线程在尝试获取写锁时被阻塞。
4.2 读写锁实现原理
ReentrantReadWriteLock 还是基于 AQS 实现的，还是对 state 进行操作，拿到锁资源就去干活，如果没有拿到，依然去 AQS 队列中排队。
读锁操作：基于 state 的高 16 位进行操作。
写锁操作：基于 state 的低 16 位进行操作。
ReentrantReadWriteLock 依然是可重入锁。
写锁重入 ：读写锁中的写锁的重入方式，基本和 ReentrantLock 一致，没有什么区别，依然是对 state 进行 +1 操作即可，只要确认持有锁资源的线程，是当前写锁线程即可。只不过之前 ReentrantLock 的重入次数是 state 的正数取值范围，但是读写锁中写锁范围就变小了。
读锁重入 ：读锁在获取锁资源操作时，是要对 state 的高 16 位进行 +1 操作。因为读锁是共享锁，所以同一时间会有多个读线程持有读锁资源。这样一来，多个读操作在持有读锁时，无法确认每个线程读锁重入的次数。为了去记录读锁重入的次数，每个读操作的线程，都会有一个 ThreadLocal 记录锁重入的次数。
写锁的饥饿问题 ：读锁是共享锁，当有线程持有读锁资源时，再来一个线程想要获取读锁，直接对 state 修改即可。在读锁资源先被占用后，来了一个写锁资源，此时，大量的需要获取读锁的线程来请求锁资源，如果可以绕过写锁，直接拿资源，会造成写锁长时间无法获取到写锁资源。
读锁在拿到锁资源后，如果再有读线程需要获取读锁资源，需要去 AQS 队列排队。如果队列的前面需要写锁资源的线程，那么后续读线程是无法拿到锁资源的。持有读锁的线程，只会让写锁线程之前的读线程拿到锁资源
4.3 写锁分析
4.3.1 写锁加锁流程图
4.3.2 写锁加锁源码分析
java
// 写锁加锁的入口
public void lock() {
sync.acquire(1);
}
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
// 读写锁的写锁实现tryAcquire
protected final boolean tryAcquire(int acquires) {
// 拿到当前线程
Thread current = Thread.currentThread();
// 拿到state的值
int c = getState();
// 得到state低16位的值
int w = exclusiveCount(c);
// 判断是否有线程持有着锁资源
if (c != 0) {
// 当前没有线程持有写锁，读写互斥，告辞。
// 有线程持有写锁，持有写锁的线程不是当前线程，不是锁重入，告辞。
if (w == 0 || current != getExclusiveOwnerThread())
return false;
// 当前线程持有写锁。 锁重入。
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// 没有超过锁重入的次数，正常 + 1
setState(c + acquires);
return true;
}
// 尝试获取锁资源
if (writerShouldBlock() ||
// CAS拿锁
!compareAndSetState(c, c + acquires))
return false;
// 拿锁成功，设置占有互斥锁的线程
setExclusiveOwnerThread(current);
// 返回true
return true;
}
// ================================================================
// 这个方法是将state的低16位的值拿到
int w = exclusiveCount(c);
state & ((1 << 16) - 1)
00000000 00000000 00000000 00000001 == 1
00000000 00000001 00000000 00000000 == 1 << 16
00000000 00000000 11111111 11111111 == (1 << 16) - 1
&运算，一个为0，必然为0，都为1，才为1
// ================================================================
// writerShouldBlock方法查看公平锁和非公平锁的效果
// 非公平锁直接返回false执行CAS尝试获取锁资源
// 公平锁需要查看是否有排队的，如果有排队的，我是否是head的next4.3.3 写锁释放锁流程
释放的流程和 ReentrantLock 一致，只是在判断释放是否干净时，判断低 16 位的值。
java
// 写锁释放锁的 tryRelease 方法
protected final boolean tryRelease(int releases) {
// 判断当前持有写锁的线程是否是当前线程
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
// 获取state - 1
int nextc = getState() - releases;
// 判断低16位结果是否为0，如果为0，free设置为true
boolean free = exclusiveCount(nextc) == 0;
if (free)
// 将持有锁的线程设置为null
setExclusiveOwnerThread(null);
// 设置给state
setState(nextc);
// 释放干净，返回true。 写锁有冲入，这里需要返回false，不去释放排队的Node
return free;
}4.4 读锁分析
4.4.1 读锁加锁流程概述
java
// 读锁加锁的方法入口
public final void acquireShared(int arg) {
// 竞争锁资源滴干活
if (tryAcquireShared(arg) < 0)
// 没拿到锁资源，去排队
doAcquireShared(arg);
}
// 读锁竞争锁资源的操作
protected final int tryAcquireShared(int unused) {
// 拿到当前线程
Thread current = Thread.currentThread();
// 拿到state
int c = getState();
// 拿到state的低16位，判断 != 0，有写锁占用着锁资源
// 并且，当前占用锁资源的线程不是当前线程
if (exclusiveCount(c) != 0 && getExclusiveOwnerThread() != current)
// 写锁被其他线程占用，无法获取读锁，直接返回 -1，去排队
return -1;
// 没有线程持有写锁、当前线程持有写锁
// 获取读锁的信息，state的高16位。
int r = sharedCount(c);
// 公平锁：就查看队列是由有排队的，有排队的，直接告辞，进不去if，后面也不用判断（没人排队继续走）
// 非公平锁：没有排队的，直接抢。 有排队的，但是读锁其实不需要排队，如果出现这个情况，大部分是写锁资源刚刚释放，
// 后续Node还没有来记得拿到读锁资源，当前竞争的读线程，可以直接获取
if (!readerShouldBlock() &&
// 判断持有读锁的临界值是否达到
r < MAX_COUNT &&
// CAS修改state，对高16位进行 + 1
compareAndSetState(c, c + SHARED_UNIT)) {
// 省略部分代码！！！！
return 1;
}
return fullTryAcquireShared(current);
}
// 非公平锁的判断
final boolean apparentlyFirstQueuedIsExclusive() {
Node h, s;
return (h = head) != null && // head为null，可以直接抢占锁资源
(s = h.next) != null && // head的next为null，可以直接抢占锁资源
!s.isShared() && // 如果排在head后面的Node，是共享锁，可以直接抢占锁资源。
s.thread != null; // 后面排队的thread为null，可以直接抢占锁资源
}4.4.2 读锁重复流程
=============================重入操作================
前面阐述过，读锁为了记录锁重入的次数，需要让每个读线程用 ThreadLocal 存储重入次数
ReentrantReadWriteLock 对读锁重入做了一些优化操作
============================记录重入次数的核心================
ReentrantReadWriteLock 在内部对 ThreadLocal 做了封装，基于 HoldCount 的对象存储重入次数，在内部有个 count 属性记录，而且每个线程都是自己的 ThreadLocalHoldCounter，所以可以直接对内部的 count 进行
++操作。=======================第一个获取读锁资源的重入次数记录方式================
第一个拿到读锁资源的线程，不需要通过 ThreadLocal 存储，内部提供了两个属性来记录第一个拿到读锁资源线程的信息
内部提供了
firstReader记录第一个拿到读锁资源的线程，firstReaderHoldCount记录firstReader的锁重入次数=====================最后一个获取读锁资源的重入次数记录方式================
最后一个拿到读锁资源的线程，也会缓存他的重入次数，这样
++起来更方便基于
cachedHoldCounter缓存最后一个拿到锁资源现成的重入次数=====================最后一个获取读锁资源的重入次数记录方式================
重入次数的流程执行方式：
1、判断当前线程是否是第一个拿到读锁资源的：如果是，直接将
firstReader以及firstReaderHoldCount设置为当前线程的信息2、判断当前线程是否是
firstReader：如果是，直接对firstReaderHoldCount++即可。3、跟
firstReader没关系了，先获取cachedHoldCounter，判断是否是当前线程。3.1、如果不是，获取当前线程的重入次数，将
cachedHoldCounter设置为当前线程。3.2、如果是，判断当前重入次数是否为 0，重新设置当前线程的锁从入信息到
readHolds（ThreadLocal）中，算是初始化操作，重入次数是 0。3.3、前面两者最后都做
count++
java
protected final int tryAcquireShared(int unused) {
Thread current = Thread.currentThread();
int c = getState();
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return -1;
int r = sharedCount(c);
if (!readerShouldBlock() &&
r < MAX_COUNT &&
compareAndSetState(c, c + SHARED_UNIT)) {
// ===============================================================
// 判断r == 0，当前是第一个拿到读锁资源的线程
if (r == 0) {
// 将firstReader设置为当前线程
firstReader = current;
// 将count设置为1
firstReaderHoldCount = 1;
}
// 判断当前线程是否是第一个获取读锁资源的线程
else if (firstReader == current) {
// 直接++。
firstReaderHoldCount++;
}
// 到这，就说明不是第一个获取读锁资源的线程
else {
// 那获取最后一个拿到读锁资源的线程
HoldCounter rh = cachedHoldCounter;
// 判断当前线程是否是最后一个拿到读锁资源的线程
if (rh == null || rh.tid != getThreadId(current))
// 如果不是，设置当前线程为cachedHoldCounter
cachedHoldCounter = rh = readHolds.get();
// 当前线程是之前的cacheHoldCounter
else if (rh.count == 0)
// 将当前的重入信息设置到ThreadLocal中
readHolds.set(rh);
// 重入的++
rh.count++;
}
// ===============================================================
return 1;
}
return fullTryAcquireShared(current);
}4.4.3 读锁加锁的后续逻辑
java
// tryAcquireShard方法中，如果没有拿到锁资源，走这个方法，尝试再次获取，逻辑跟上面基本一致。
final int fullTryAcquireShared(Thread current) {
// 声明当前线程的锁重入次数
HoldCounter rh = null;
// 死循环
for (;;) {
// 再次拿到state
int c = getState();
// 当前如果有写锁在占用锁资源，并且不是当前线程，返回-1，走排队策略
if (exclusiveCount(c) != 0) {
if (getExclusiveOwnerThread() != current)
return -1;
}
// 查看当前是否可以尝试竞争锁资源（公平锁和非公平锁的逻辑）
else if (readerShouldBlock()) {
// 无论公平还是非公平，只要进来，就代表要放到AQS队列中了，先做一波准备
// 在处理ThreadLocal的内存泄漏问题
if (firstReader == current) {
// 如果当前当前线程是之前的firstReader，什么都不用做
} else {
// 第一次进来是null。
if (rh == null) {
// 拿到最后一个获取读锁的线程
rh = cachedHoldCounter;
// 当前线程并不是cachedHoldCounter，没到拿到
if (rh == null || rh.tid != getThreadId(current)) {
// 从自己的ThreadLocal中拿到重入计数器
rh = readHolds.get();
// 如果计数器为0，说明之前没拿到过读锁资源
if (rh.count == 0)
// remove，避免内存泄漏
readHolds.remove();
}
}
// 前面处理完之后，直接返回-1
if (rh.count == 0)
return -1;
}
}
// 判断重入次数，是否超出阈值
if (sharedCount(c) == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// CAS尝试获取锁资源
if (compareAndSetState(c, c + SHARED_UNIT)) {
if (sharedCount(c) == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
firstReaderHoldCount++;
} else {
if (rh == null)
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
cachedHoldCounter = rh; // cache for release
}
return 1;
}
}
}4.4.4 读线程在AQS队列获取锁资源的后续操作
- 正常如果都是读线程来获取读锁资源，不需要使用到 AQS 队列的，直接 CAS 操作即可。
- 如果写线程持有着写锁，这是读线程就需要进入到 AQS 队列排队，可能会有多个读线程在 AQS 中。
当写锁释放资源后，会唤醒 head 后面的读线程，当 head 后面的读线程拿到锁资源后，还需要查看 next 节点是否也是读线程在阻塞，如果是，那么直接唤醒。
java
// 读锁需要排队的操作
private void doAcquireShared(int arg) {
// 声明Node，类型是共享锁，并且扔到AQS中排队
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
// 拿到上一个节点
final Node p = node.predecessor();
// 如果prev节点是head，直接可以执行tryAcquireShared
if (p == head) {
int r = tryAcquireShared(arg);
if (r >= 0) {
// 拿到读锁资源后，需要做的后续处理
setHeadAndPropagate(node, r);
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
// 找到prev有效节点，将状态设置为-1，挂起当前线程
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
private void setHeadAndPropagate(Node node, int propagate) {
// 拿到head节点
Node h = head;
// 将当前节点设置为head节点
setHead(node);
// 第一个判断更多的是在信号量有处理JDK1.5 BUG的操作。
if (propagate > 0 || h == null || h.waitStatus < 0 || (h = head) == null || h.waitStatus < 0) {
// 拿到当前Node的next节点
Node s = node.next;
// 如果next节点是共享锁，直接唤醒next节点
if (s == null || s.isShared())
doReleaseShared();
}
}4.4.5 读锁的释放锁流程
- 处理重入以及
state的值。 - 唤醒后续排队的
Node。
java
// 读锁释放锁流程
public final boolean releaseShared(int arg) {
// tryReleaseShared：处理state的值，以及可重入的内容
if (tryReleaseShared(arg)) {
// AQS队列的事！
doReleaseShared();
return true;
}
return false;
}
// 1、 处理重入问题 2、 处理state
protected final boolean tryReleaseShared(int unused) {
// 拿到当前线程
Thread current = Thread.currentThread();
// 如果是firstReader，直接干活，不需要ThreadLocal
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
if (firstReaderHoldCount == 1)
firstReader = null;
else
firstReaderHoldCount--;
}
// 不是firstReader，从cachedHoldCounter以及ThreadLocal处理
else {
// 如果是cachedHoldCounter，正常--
HoldCounter rh = cachedHoldCounter;
// 如果不是cachedHoldCounter，从自己的ThreadLocal中拿
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
int count = rh.count;
// 如果为1或者更小，当前线程就释放干净了，直接remove，避免value内存泄漏
if (count <= 1) {
readHolds.remove();
// 如果已经是0，没必要再unlock，扔个异常
if (count <= 0)
throw unmatchedUnlockException();
}
// -- 走你。
--rh.count;
}
for (;;) {
// 拿到state，高16位，-1，成功后，返回state是否为0
int c = getState();
int nextc = c - SHARED_UNIT;
if (compareAndSetState(c, nextc))
return nextc == 0;
}
}
// 唤醒 AQS 中排队的线程
private void doReleaseShared() {
// 死循环
for (;;) {
// 拿到头
Node h = head;
// 说明有排队的
if (h != null && h != tail) {
// 拿到head的状态
int ws = h.waitStatus;
// 判断是否为 -1
if (ws == Node.SIGNAL) {
// 到这，说明后面有挂起的线程，先基于CAS将head的状态从-1，改为0
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue;
// 唤醒后续节点
unparkSuccessor(h);
}
// 这里不是给读写锁准备的，在信号量里说。。。
else if (ws == 0 && !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue;
}
// 这里是出口
if (h == head)
break;
}
}五、死锁问题
演示一个简单的死锁案例：
java
package org.codeart.deadlock;
import java.lang.management.ManagementFactory;
import java.lang.management.ThreadInfo;
import java.lang.management.ThreadMXBean;
public class DeadLockTest {
private static final Object lockA = new Object();
private static final Object lockB = new Object();
public static void main(String[] args) {
Thread t1 = new Thread(() -> {
synchronized (lockA) {
System.out.println("Thread 1: locked lockA");
try {
Thread.sleep(100); // 模拟执行时间，增加死锁几率
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (lockB) {
System.out.println("Thread 1: locked lockB");
}
}
});
Thread t2 = new Thread(() -> {
synchronized (lockB) {
System.out.println("Thread 2: locked lockB");
try {
Thread.sleep(100); // 模拟执行时间，增加死锁几率
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (lockA) {
System.out.println("Thread 2: locked lockA");
}
}
});
t1.start();
t2.start();
// 启动一个死锁检测线程
new Thread(() -> {
ThreadMXBean mbean = ManagementFactory.getThreadMXBean();
while (true) {
long[] deadlockedThreads = mbean.findDeadlockedThreads();
if (deadlockedThreads != null) {
ThreadInfo[] threadInfos = mbean.getThreadInfo(deadlockedThreads, true, true);
System.err.println("===== Detected Deadlock =====");
for (ThreadInfo ti : threadInfos) {
System.err.println(ti.toString()); // 打印死锁线程信息
}
break; // 发现死锁后退出
}
try {
Thread.sleep(500); // 每隔0.5s检查一次
} catch (InterruptedException ignored) {}
}
}, "Deadlock-Detector").start();
}
}我在主线程里面添加了死锁检测，它会主动发现死锁问题并打印日志，打印内容如下：
log
Thread 1: locked lockA
Thread 2: locked lockB
===== Detected Deadlock =====
"Thread-0" prio=5 Id=30 BLOCKED on java.lang.Object@1bcc300f owned by "Thread-1" Id=31
at app//org.codeart.deadlock.DeadLockTest.lambda$main$0(DeadLockTest.java:24)
- blocked on java.lang.Object@1bcc300f
- locked java.lang.Object@13a146c3
at app//org.codeart.deadlock.DeadLockTest$$Lambda/0x000001a3d00031f8.run(Unknown Source)
at java.base@21.0.7/java.lang.Thread.runWith(Thread.java:1596)
at java.base@21.0.7/java.lang.Thread.run(Thread.java:1583)
"Thread-1" prio=5 Id=31 BLOCKED on java.lang.Object@13a146c3 owned by "Thread-0" Id=30
at app//org.codeart.deadlock.DeadLockTest.lambda$main$1(DeadLockTest.java:40)
- blocked on java.lang.Object@13a146c3
- locked java.lang.Object@1bcc300f
at app//org.codeart.deadlock.DeadLockTest$$Lambda/0x000001a3d0003408.run(Unknown Source)
at java.base@21.0.7/java.lang.Thread.runWith(Thread.java:1596)
at java.base@21.0.7/java.lang.Thread.run(Thread.java:1583)