AbstractQueuedSynchronizer内部机制_以ReentrantLock为例解析
(以下解析均以1.8代码为准)
说到java中的锁，最常用的方法就包括ReentrantLock的lock和unlock方法。那么这两个方法是如何实现的呢 ？今天我们就来试着解析一下，顺便了解java concurrent包中非常关键的一个类:AbstractQueuedSynchronizer。
以下是ReentrantLock中的lock与unlock方法：
public void lock() {
sync.lock();
}
public void unlock() {
sync.release(1);
}
打完，收工！
(开玩笑啦)
看来ReentrantLock只是个傀儡，实际管理的是sync。我们看下其中Sync的源码：
abstract static class Sync extends AbstractQueuedSynchronizer {
/**
* Performs {@link Lock#lock}. The main reason for subclassing
* is to allow fast path for nonfair version.
*/
abstract void lock();
/**
* Performs non-fair tryLock. tryAcquire is implemented in
* subclasses, but both need nonfair try for trylock method.
*/
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;
}
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
protected final boolean isHeldExclusively() {
// While we must in general read state before owner,
// we don't need to do so to check if current thread is owner
return getExclusiveOwnerThread() == Thread.currentThread();
}
final boolean isLocked() {
return getState() != 0;
}
}
其中Sync有两个实现类，分别完成公平/非公平锁。
/**
* Sync object for non-fair locks
*/
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
/**
* Performs lock. Try immediate barge, backing up to normal
* acquire on failure.
*/
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
}
/**
* Sync object for fair locks
*/
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
acquire(1);
}
/**
* Fair version of tryAcquire. Don't grant access unless
* recursive call or no waiters or is first.
*/
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
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;
}
}
Sync完成了一些方法，但幕后规定大体框架的还是AbstractQueuedSynchronizer(AQS)，继承关系如下图:
AQS数据结构
head: volatile Node, 等待队列的头节点，懒加载，hread和prev都是null。第一个有资格抢CPU资源的是head的后继节点。
tail: volatile Node, 等待队列尾节点，懒加载
state: volatile int, 同步状态
spinForTimeoutThreshold: final long。小于这个阈值时，认为自旋比使用带超时的park更高效。默认为1000纳秒
exclusiveOwnerThread: transient Thread。锁的排他持有线程，这里有transient是因为序列化没有意义：当前主机的线程在解序列化之后是没有什么用处的。
waitStatus状态：
- CANCELLED(1，由于interrupt或者timeout导致，到这个状态之后不会转换到其他状态)
- SIGNAL(-1，独占模式下，下一个节点通过park被阻塞了，当前节点被释放后需要unpark下个节点)
- CONDITION(-2，当前节点在Condition Queue里面，即正在等待条件变量。这个节点在这个状态下不会被作为Sync Queue中的节点看待)
- PROPAGATE(-3，后续节点会传播唤醒的操作，共享模式下起作用)
- 0，不属于以上任何情况
通常只要检查waitStatus符号，如果是负数说明正在等待信号量，如果>0说明被cancel了，不用写很多"waitStatus== *"的判断
非公平锁具体实现
那么究竟是如何通过一个AQS就能完成锁的实现呢？下图展示了两个线程调用ReentrantLock的lock方法，可能产生的调用顺序：
接下来我们按照时间顺序来依次探究他们的源代码
步骤1: Thread1尝试CAS(compareAndSet)
compareAndSetState直接通过C++实现的unsafe调用操作系统层面的原子方法
- 如果当前值与expect相同，则将值设置为update。这里的比较与设置作为一个原子的整体，不会出现因指令重排序导致设置时值已改变的问题。
- 如果当前值与expect不同，则直接返回false。
以下为compareAndSetState的源码：
protected final boolean compareAndSetState(int expect, int update) {
// See below for intrinsics setup to support this
return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}
由于此时AQS还没有被任何线程更改，所以操作成功，AQS状态修改为1。
步骤2: Thread2争抢锁
此时Thread2也想获取锁，因此也调用了compareAndSetState(0,1)。但是由于当前AQS的状态已经变为1，Thread2的CAS失败了。
步骤3: Thread1设置ownerThread
此时Thread1已杜绝其它线程通过CAS更新AQS状态，可以通过setExclusiveOwnerThread方法声明"现在我是话事人"。以下是setExclusiveOwnerThread，很简单：
protected final void setExclusiveOwnerThread(Thread thread) {
exclusiveOwnerThread = thread;
}
步骤4: Thread2等待获取锁
回顾一下lock方法：
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
Thread2在compareAndSetState失败后，只能通过acquire方法成为候选的等待线程。这里的逻辑是排他锁的核心，值得慢慢细说。
步骤4.1: Thread2再次tryAcquire&阻塞
以下是acquire的源码：
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
static void selfInterrupt() {
Thread.currentThread().interrupt();
}
其中tryAcquire是AQS的抽象方法，返回是否成功获取到资源，由具体的子类实现(如文首提到的ReentrantLock中的NonFairSync类)。acquireQueued(addWaiter(Node.EXCLUSIVE), arg)则实现了未获取到资源后阻塞等待的逻辑。
在等待的过程中我们就会接触到AQS内部的等待队列，在队列中的head为一个空节点，tail为一个指针。head后的第一个节点在队伍中有最优先的资格获取资源。
为方便讨论，假设当前的队列中有一个处于等待状态的节点(节点状态默认为0，关于节点状态转换的解析，详见文末的另一篇文章)，如下图：
现在 Thread2 进行了一次tryAcquire，但是由于锁还在Thread1手上，所以tryAcquire失败了。Thread2需要阻塞等待唤醒。
addWaiter
Thread2 首先调用 addWaiter，它为当前线程创建指定模式下的节点，并加入等待队列。入参是Node.EXCLUSIVE或者Node.SHARED。如果tail不为空，直接尝试使用CAS更新tail，如果CAS失败或者tail为空，则使用enq方法(此篇文章不再展开)无限循环设置tail。
private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure
Node pred = tail;
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
enq(node);
return node;
}
调用addWaiter之后，等待队列的状态如下所示:
acquireQueued
创建成功节点后，Thread2通过acquireQueued方法阻塞等待其它线程唤醒它。如果在阻塞的过程中被中断了，则返回true，由acquire方法调用selfInterrupt方法处理中断。以下是acquireQueued的源码：
/**
* Acquires in exclusive uninterruptible mode for thread already in
* queue. Used by condition wait methods as well as acquire.
*
* @param node the node
* @param arg the acquire argument
* @return {@code true} if interrupted while waiting
*/
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
private void setHead(Node node) {
head = node;
node.thread = null;
node.prev = null;
}
整体上，acquireQueued方法不断获取当前节点的前驱节点，并按照分支进行如下处理：
- 如果前驱节点是head，说明当前节点在队伍中排第一顺位，尝试调用tryAcquire获取资源。
- 如果成功获取资源，则将当前节点更新为head(thread和prev都会被清空，成为一个空节点)，并返回false。于是当前线程成功获取锁，且不会触发selfInterrupted。
- 如果前驱节点不是head或者没有成功获取资源，则调用shouldParkAfterFailedAcquire判断是否可以阻塞
- 如果可以阻塞，则调用parkAndCheckInterrupt挂起当前线程
- 如果暂时不可以阻塞，则继续进行循环，直到阻塞/成功获取锁
分支1的代码均已了解，下面我们了解一下分支2：
shouldParkAfterFailedAcquire&parkAndCheckInterrupt
shouldparkAfterFailedAcquire负责检查并更新节点状态，并返回是否可以阻塞当前线程，以下是源代码：
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
/*
* 前驱节点也在等待
* 因此当获取失败时，可以直接调用park堵塞，返回true
*/
return true;
if (ws > 0) {
/*
* 前驱节点状态为CANCELLED，向前查找非CANCELLED的节点作为prev
*
*/
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
/*
* 状态为0或者PROPAGATE，设置前驱节点状态为SIGNAL
*
*
*/
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
- 如果前驱节点状态为SIGNAL则返回true。
- 如果前驱节点状态为CANCELLED，则前驱节点没必要再留在队列中。向前不断查找，找到第一个非CANCELLED的节点，返回false。
- 如果是其他情况，需要设置前驱节点状态为SIGNAL，以便前驱节点用完锁之后可以唤醒自己，返回false。
由于调用处是个无限循环，会不断tryAcquire，如果第一次此方法返回false，接下来pred的状态就会变成SIGNAL，最终还是会返回true。
在我们的例子中，Thread2没有被中断，而是进入队列等待了，等待队列如下图：
一旦shouldparkAfterFailedAcquire返回true，则调用parkAndCheckInterrupt挂起当前线程：
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
cancelAcquire
如果拿到锁/出现异常，调用cancelAcquire。cancelAcquire会清理队列中的CANCELLED的状态，并将当前的node状态更新为cancelled。
- 如果当前node为tail，清空队列
- 如果当前不是tail，前驱也不是head，则将前驱连接到下一个wait状态的节点
- 如果当前不是tail，但前驱是head，则unpark下一个wait状态的节点
/**
* Cancels an ongoing attempt to acquire.
*
* @param node the node
*/
private void cancelAcquire(Node node) {
// Ignore if node doesn't exist
if (node == null)
return;
node.thread = null;
// Skip cancelled predecessors
Node pred = node.prev;
while (pred.waitStatus > 0)
node.prev = pred = pred.prev;
// predNext is the apparent node to unsplice. CASes below will
// fail if not, in which case, we lost race vs another cancel
// or signal, so no further action is necessary.
Node predNext = pred.next;
// Can use unconditional write instead of CAS here.
// After this atomic step, other Nodes can skip past us.
// Before, we are free of interference from other threads.
node.waitStatus = Node.CANCELLED;
// If we are the tail, remove ourselves.
if (node == tail && compareAndSetTail(node, pred)) {
compareAndSetNext(pred, predNext, null);
} else {
// If successor needs signal, try to set pred's next-link
// so it will get one. Otherwise wake it up to propagate.
int ws;
if (pred != head &&
((ws = pred.waitStatus) == 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 {
unparkSuccessor(node);
}
node.next = node; // help GC
}
}
步骤5.1: Thread1调用unlock
unlock直接转发到release方法，源码如下:
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
release首先调用tryRelease归还资源，并尝试通过unparkSuccessor唤醒head后的第一个节点。唤醒方式：找到第一个处于等待状态的线程，并调用LockSupport.unpark唤醒对应线程。具体实现如下：
private void unparkSuccessor(Node node) {
/*
* If status is negative (i.e., possibly needing signal) try
* to clear in anticipation of signalling. It is OK if this
* fails or if status is changed by waiting thread.
*/
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
/*
* Thread to unpark is held in successor, which is normally
* just the next node. But if cancelled or apparently null,
* traverse backwards from tail to find the actual
* non-cancelled successor.
*/
Node s = node.next;
if (s == null || s.waitStatus > 0) {
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
if (s != null)
LockSupport.unpark(s.thread);
}
现在我们假设Thread1释放锁之后，当前第一个节点拿到锁，使用完之后也释放掉锁，Thread2就会被第一个节点unpark。此时队列如下图：
一旦Thread2被unpark，就会继续执行acquireQueued中的循环。既然现在它是第一个节点了，只要成功执行tryAcquire，Thread2就终于可以翻身农奴把歌唱，持有锁了！
last question
一切看起来很美好，那为什么叫这种锁nonFair锁呢？
ans: 因为在lock时会先尝试CAS，此时可能锁刚被另一个线程释放，那么CAS成功就会抢占队列头的节点，导致插队。
公平锁实现
公平锁与非公平锁的区别仅在于FairSync中的lock和tryAcquire实现不同:
/**
* Sync object for fair locks
*/
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
acquire(1);
}
/**
* Fair version of tryAcquire. Don't grant access unless
* recursive call or no waiters or is first.
*/
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
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;
}
}
lock
对比非公平锁，公平锁的lock方法不会首先尝试CAS，避免了上一节最后一小段中"插队"的情况，但同时也导致了一定程度的效率下降。
tryAcquire
下面是非公平锁的tryAcquire方法(非公平锁的方法nonFairTryAcquire在Sync中，这样的代码结构看起来有点错乱，在11中已经改为FairSync和NonFairSync各实现一个tryAcquire了，结构看起来正常许多)
// 非公平锁的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()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
可以看到，唯一的区别在于公平锁在CAS之前会调用hasQueuedPredecessors方法:
public final boolean hasQueuedPredecessors() {
// The correctness of this depends on head being initialized
// before tail and on head.next being accurate if the current
// thread is first in queue.
Node t = tail; // Read fields in reverse initialization order
Node h = head;
Node s;
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
此方法检查是否有线程在当前线程之前排队，在以下情况返回false:
- head与tail相同，即队列为空
- head.next!=null且head.next的线程为当前线程，即当前线程在等待队列中排名第一
只有hasQueuedPredecessors方法返回false，即没有任何线程在当前线程之前，当前线程才可以使用CAS尝试获取资源。
除了Sync对象中lock和tryAcquire方法，公平锁与非公平锁的实现是一模一样的，在此不再赘述。
总结
之前我也看过一些java源码解析，通常都是一个个方法地讲解当前类，但却难以将各个方法串联起来。本篇文章试着通过解析ReentrantLock的lock和unlock方法来了解AbstractQueuedSynchronizer的实现细节。篇幅原因，对于AQS中节点状态的转换过程和共享锁的实现没有详细解析。但我的一位老哥碰巧也写了一篇关于AQS内部节点状态转换细节的文章，可以移步学习。