Java传家宝：微信公众号(Java传家宝)、Java传家宝-CSND
AQS
AbstractQueuedSynchronizer抽象同步队列，俗称AQS，是Java 并发包的基础工具类，是实现 ReentrantLock、CountDownLatch、Semaphore、FutureTask 等类的基础。
首先看一下AQS中有哪些基本属性：
// 头结点，你直接把它当做 当前持有锁的线程
private transient volatile Node head;
// 同步队列尾节点
private transient volatile Node tail;
// 标记当前锁的状态 0代表没有被占用，大于 0 代表有线程持有当前锁
private volatile int state;
// 继承的AbstractOwnableSynchronizer的属性，标记当前拥有互斥锁的线程
private transient Thread exclusiveOwnerThread;
另外Node类型的节点是指AQS将线程包装为一个个的节点，是AQS的内部类。如下：
static final class Node {
// 标记为共享锁 默认
static final Node SHARED = new Node();
// 标记为互斥锁
static final Node EXCLUSIVE = null;
// 线程状态 取值在下面 1 0 -1 -2 -3
volatile int waitStatus;
// 当前线程取消获取锁
static final int CANCELLED = 1;
// 表示当前node的后继节点对应的线程需要被唤醒
static final int SIGNAL = -1;
// 表明该线程在条件等待队列
static final int CONDITION = -2;
// 指示下一个获取共享应无条件传播
static final int PROPAGATE = -3;
// 前驱节点
volatile Node prev;
// 后继节点
volatile Node next;
// 当前线程
volatile Thread thread;
// 状态
Node nextWaiter;
Node() { // 用于建立初始化的头节点或者共享锁标志
}
Node(Thread thread, Node mode) { // 用于 addWaiter
this.nextWaiter = mode;
this.thread = thread;
}
Node(Thread thread, int waitStatus) { // 用于 Condition
this.waitStatus = waitStatus;
this.thread = thread;
}
}
通过上述源码结构，大概能得到AQS的结构，如下：
ReentrantLock(FairSync)
AQS是一个抽象类，是实现JUC并发包下相关类实现的基础，我们通过研究ReentrantLock的公平锁来理解AQS是如何工作的。在ReentrantLock中定义了一个Sync的内部静态抽类，继承了AQS，然后通过FairSync和NonFairSync继承Sync实现先相关功能。如下：
abstract static class Sync extends AbstractQueuedSynchronizer {
//...
}
static final class NonfairSync extends Sync {
//...
}
static final class FairSync extends Sync {
//...
}
lock
首先看公平锁的加锁流程，我们通常通过.Lock()的方式加锁，看下源码如何工作：
// ReentrantLock
static final class FairSync extends Sync {
// 加锁
final void lock() {
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
// ...
}
}
// AQS
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
tryAcquire
可以看到首先是通过acquire(1)==>tryAcquire(arg)，看一下tryAcquire(arg)里面的逻辑：
// ReentrantLock FairSync
protected final boolean tryAcquire(int acquires) {
// 获取当前线程
final Thread current = Thread.currentThread();
// 获取当前锁状态
int c = getState();
if (c == 0) {
// 锁状态为0 表示没有被占用
if (!hasQueuedPredecessors() && // 看一下队列中有没有等待的线程
compareAndSetState(0, acquires)) { // 没有就CAS替换状态为1 表示占用锁
setExclusiveOwnerThread(current); // 替换成功就设置当前线程为持有锁的线程并且返回true
return true;
}
}
// 不为0 表示被占用 判断是不是被当前线程占用
else if (current == getExclusiveOwnerThread()) {
// 是则状态+1，表示重入
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc); // 更新状态
return true;
}
// 1 锁未被占用 && (队列有等待的线程||CAS替换失败)
// 2 锁被占用 && 不是当前线程
return false;
}
CAS：先定义三个变量，V表示要更新的变量，E表示当前值，U表示需要将V更新的值
- V == E 则更新 V = U 返回 true表示成功
- V != E , 不做操作 返回 false表示失败
总结一下tryAcquire的操作：
- 首先判断锁是否被占用，
- 未被占用公平锁的操作是判断队列中是否有等待的线程，没有则尝试CAS获取锁，获取成功则返回true，失败就返回false。
- 被占用了则判断是否是当前线程占用，是就状态+1，返回true，不是就返回false。
可以看到，tryAcquire的返回true的过程，没有队列等待的过程(线程挂起，线程唤醒的额外操作)，表示先尝试获取一下，开销不大。在画个流程图吧：
addWaiter
然后我们在回到acquire方法看：
public final void acquire(int arg) {
if (!tryAcquire(arg) && // 返回true 直接加锁成功返回了
acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) // tryAcquire返回false 进入
selfInterrupt();
}
可以看到，尝试获取tryAcquire返回true则加锁成功，直接返回即可，我们看返回false之后的逻辑，先进入addWaiter(Node.EXCLUSIVE)方法：
// mode = Node.EXCLUSIVE == null 可以看前面AQS的属性 默认为null
private Node addWaiter(Node mode) {
// 包装当前线程为一个节点
Node node = new Node(Thread.currentThread(), mode);
// 获取尾节点
Node pred = tail;
if (pred != null) {
// 尾节点不为空 设置当前线程的前驱节点prev为当前尾节点tail
node.prev = pred;
if (compareAndSetTail(pred, node)) { // CAS替换尾节点为当前线程
pred.next = node; // 成功则设置当前尾节点的后继节点为当前线程 并返回当前线程节点
return node;
}
}
// 尾节点为空||CAS失败
// cAS失败说明被其他线程抢先入队了
enq(node);
return node;
}
// 尾节点为空||CAS失败 node = 当前线程节点
private Node enq(final Node node) {
for (;;) {
// 拿到新的尾节点
Node t = tail;
if (t == null) { // 尾节点为空
if (compareAndSetHead(new Node())) // 初始化头节点 空node 不代表线程
tail = head; // 初始化尾节点为头节点
} else {
// 尾节点不为空，即上个函数CAS失败，或者刚在上一步初始化
// 同样的入队操作 不过在for (;;)循环体中 一直入队
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
可以发现addWaiter的目的就是让当前线程节点入队，这里流程图就不画了，没什么东西，大概说一下：
- 拿到尾节点，不为空，CAS入队
- 尾节点为空，说明队列为空，初始化头尾节点，在下一次循环中让当前线程入队
- 尾节点不为空，CAS失败，说明被其他线程抢先入队，自己去循环体中一直进行入队操作
流程图如下：
acquireQueued
然后我们在回到acquire方法看：
public final void acquire(int arg) {
if (!tryAcquire(arg) && // 返回true 直接加锁成功返回了
acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) // tryAcquire返回false 进入
selfInterrupt();
}
// acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) ==>> acquireQueued(当前线程节点, arg))
这个时候addWaiter已经返回了当前线程节点，进入acquireQueued查看里面的逻辑：
// AQS
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor(); // 简单的获取前驱节点
// p == head说明当前线程节点是队列第一个那么直接尝试获取锁
if (p == head && tryAcquire(arg)) {
// 成功了设置头节点为当前获取锁的线程节点
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted; // 返回false
}
// 当前线程不是队头||尝试获取锁失败
// 看字面意思 需要挂起获取锁失败的节点吗？
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt()) // 返回true执行下面的parkAndCheckInterrupt挂起操作
interrupted = true; // 设置中断为true
}
} finally {
// 什么时候 failed 会为 true???
// tryAcquire() 方法抛异常的情况
if (failed)
cancelAcquire(node);
}
}
// 看字面意思 需要挂起获取锁失败的节点吗？ 就是操作waitStatus 可以看下AQS中这个属性的作用
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
// 拿到前驱节点的waitStatus
int ws = pred.waitStatus;
if (ws == Node.SIGNAL) // ==-1直接返回true
return true;
if (ws > 0) { // >0说明前驱节点取消了获取锁
// 修改当前线程节点的前驱节点为前驱的前驱
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);// 一直到前驱节点waitStatus < 0
pred.next = node;
} else {
// waitStatus != -1 & < 0；CAS替换前驱节点的waitStatus为-1
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
// ws ！= -1 返回false
return false;
}
// shouldParkAfterFailedAcquire返回true
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this); // 挂起当前线程 线程停止在这里等待唤醒
return Thread.interrupted();
}
可以看到acquireQueued的操作大概就是如果当前线程节点是队头，尝试去获取锁，成功直接返回，失败则根据前驱节点的状态考虑是否挂起线程还是继续去抢锁，大概说一下：
- 拿到当前线程节点的前驱节点，判断是否为head节点，是就尝试获取锁，不是就考虑是否挂起。获取成功返回中断值，默认为false
- 获取锁失败，也去考虑是否挂起，如果前驱waitStatus的状态为-1，那么直接挂起当前线程 下次唤醒设置中断为true
- 如果 waitStatus > 0 则修改当前线程节点的前驱节点直到前驱节点的waitStatus == -1 且下一次循环重新获取锁
- 如果waitStatus!=-1&<0，则CAS替换前驱节点的waitStatus = -1且下一次循环重新获取锁
大概画一下流程图：
整个ReentrantLock的加锁流程就是这样，下面分析下解锁流程。
unlock
首先，解锁操作，释放锁并且将之前通过LockSupport.park(this)挂起的线程唤醒。首先看一下解锁的源码：
public void unlock() {
sync.release(1);
}
public final boolean release(int arg) {
if (tryRelease(arg)) { // 尝试释放锁
Node h = head;
// 头节点存在且头节点waitStatus不为0
if (h != null && h.waitStatus != 0)
// 唤醒线程
unparkSuccessor(h);
return true;
}
return false;
}
tryRelease
可以看到通过调用链unlock==> release ==>tryRelease，看一下尝试释放锁是怎么工作的：
protected final boolean tryRelease(int releases) {
int c = getState() - releases; // status-1
if (Thread.currentThread() != getExclusiveOwnerThread()) // 只有锁拥有线程才能释放锁
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) { // 说明当前锁被完全释放 更新锁的拥有线程为null
free = true;
setExclusiveOwnerThread(null);
}
setState(c); // 更新状态
return free; // 完全释放返回true 还在重入状态返回false
}
通过源码剖析，大概知道尝试释放锁就是修改锁状态status-1，如果为0则完全释放返回true，否则还在重入状态，返回false。
unparkSuccessor
然后我们回到release方法：
public final boolean release(int arg) {
if (tryRelease(arg)) { // 尝试释放锁
Node h = head;
// 头节点存在且头节点waitStatus不为0
if (h != null && h.waitStatus != 0)
// 唤醒线程
unparkSuccessor(h);
return true;
}
return false;
}
如果在重入状态就不做其他操作了，直接返回false。假设已经完全释放锁资源了，即status==0，那么就拿到头节点，判断头节点存在且头节点waitStatus不为0，唤醒线程unparkSuccessor，看一下实现：
private void unparkSuccessor(Node node) {
int ws = node.waitStatus; // 拿到头节点的waitStatus
if (ws < 0) // <0，则CAS替换为0
compareAndSetWaitStatus(node, ws, 0);
Node s = node.next; // 头节点的后继节点s
if (s == null || s.waitStatus > 0) { // s不存在或取消获取锁
s = null;
// 从后往前遍历，找到waitStatus<=0的所有节点中排在最前面的 《重》
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
// s最终会是waitStatus<=0的所有节点中排在最前面的
if (s != null)
LockSupport.unpark(s.thread); // 唤醒该节点对应的线程
}
这步是由于tryRelease失败，并且当前存在头节点且waitStatus!=0执行的，在这里面首先是将头节点的waitStatus修改为0，然后先判断队头是否在抢锁，没有则从后往前遍历拿到waitStatus<=0的所有节点中排在最前面的节点，唤醒对应的线程。
思考：为何要从后往前遍历？从前往后不是更快吗？
首先给答案，为了避免多线程并发出现遍历断链的情况，即不能遍历到所有的节点。我们先看一下AQS是如何入队的，在加锁流程有解析，这边贴过来，只贴了enq部分，addWrite也有入队操作，道理是一样的：
// 尾节点为空||CAS失败 node = 当前线程节点
private Node enq(final Node node) {
for (;;) {
Node t = tail; // 拿到尾节点
// ...
node.prev = t; //1 设置当前线程节点的前驱节点为尾节点
if (compareAndSetTail(t, node)) { //2 CAS替换尾节点为当前线程节点
t.next = node; //3 将当前线程节点设置为之前的尾节点的后继节点
return t;
}
}
}
可以看到，分为3个步骤才完全入队，CLH队列是一个双向队列，每个节点保留了前后节点的地址，在1中，先完成了前驱节点的设置，在此刻就可以从后往前遍历了且不会断链，但从后往前的话，由于后继节点未设置，那么此刻遍历到该节点就会认为后续无节点。在3中后完成了后继节点的设置，此刻才能从前往后不出差错。
此时，设想一个场景，线程A执行到1后，时间片轮到线程B执行，并且走完了1->2->3，那么此刻是一个什么场景
如图同步队列会出现这种情况，此时如果线程C执行unlock，唤醒线程，从前往后就会出现问题：
ReentrantLock(NonFairSync)
这里简单说下区别即可，看下加锁操作：
final void lock() {
if (compareAndSetState(0, 1)) // 直接尝试CAS
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1); // CAS失败才进入
}
首先，这里直接尝试CAS获取锁，失败才进入acquire方法，这个方法没有区别，看一下tryAcquire方法：
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
final boolean nonfairTryAcquire(int acquires) {
// ...
if (c == 0) {
// 别的不说，这里没有判断当前队列是否有其他线程等待，直接CAS
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
//...
}
其次，在tryAcquire阶段，少了对同步队列是否有等待线程的判断，其实我们从公平和非公平字面意思也能理解了。
232
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
