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阶段,少了对同步队列是否有等待线程的判断,其实我们从公平和非公平字面意思也能理解了。