AQS(AbstractQueuedSynchronizer)解析
AbstractQueuedSynchronizer是JUC包下的一个重要的类,JUC下的关于锁相关的类(如:ReentrantLock)等大部分是以此为基础实现的。那么我们就来分析一下AQS的原理。
1:通过以前的了解,我们先明白几个有用信息。
1:实现基于FIFO(一个先进先出的队列)
2:通过一个原子变量(atomic int) state来标识锁的状态(获取和释放)
3:子类应该通过自定义改变原子变量的方法来代表锁的获取和释放
4:底层是基于unsafe包的CAS操作,我们这里不做说明。
2:既然是一个队列,那么我们看一下这个队列的节点,部分代码如下
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; Node nextWaiter; final boolean isShared() {
return nextWaiter == SHARED;
} final Node predecessor() throws NullPointerException {
Node p = prev;
if (p == null)
throw new NullPointerException();
else
return p;
} Node() { // Used to establish initial head or SHARED marker
} Node(Thread thread, Node mode) { // Used by addWaiter
this.nextWaiter = mode;
this.thread = thread;
} Node(Thread thread, int waitStatus) { // Used by Condition
this.waitStatus = waitStatus;
this.thread = thread;
}
}
这个类比较简单,我们可以看出这个队列其实就是一个保存了线程信息的双向链表。其中 SHARED和EXCLUSIVE这两个属性分别标识了共享和独占(共享锁和独占锁)。我们特殊关注一下waitStatus这个属性,他有以下几个状态
SIGNAL: 表明它的下一个节点的线程正在被阻塞(park);当前节点释放锁或者被取消时,它必须唤醒(unpark)下一个节点的线程;
CANCELLED:该节点因为超时或者中断被取消,该状态的节点永远不会改变当前状态(会一直保持 CANCELLED 状态),同时该节点永远不会再被阻塞。
CONDITION:该节点目前位于一个条件队列,在其状态改变之前他不会转移到同步队列中,并且当他转移到同步队列时它的状态会被设置为默认值。
PROPAGATE:共享同步模式会无条件的传播给其它节点,当节点为头结点时在 doReleaseShared 方法中被设置为该状态来保证状态继续传播。
0:非上述4中状态,有可能是刚获取signal,此时它的值是0,也有可能是新建的head节点
如果上面的有些状态你看的云里雾里,不明所以的话不要紧,可以先有个大致印象。在后续的代码中看到这些状态时再结合这些解释看,就会清晰不少。
3下面是几个比较基础的方法,我们可以看下
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
这个方法就是往队列尾部添加节点,比较简单,我们不再多说。
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;
}
这个方法是对enq方法的封装,也没啥好说的。但是我们能看到先快速添加到队列尾部,失败的话再通过enq循环尝试添加。
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);
}
这个方法的作用很明显了,就是唤醒当前节点的后续节点。在这之前会尝试更改锁标志状态,如果失败了也没关系,因为后置节点的线程会继续更改。但是,你有没有发现,在查找非空非取消状态的节点的时候竟然从后往前找,这感觉不太合理啊。从前往后找不是能更快的找到后置非空非取消状态的节点吗?我们记着这个问题继续看。
4:接下来我们看下独占模式下的获取锁的代码
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}protected boolean tryAcquire(int arg) {
throw new UnsupportedOperationException();
}
acquire和release分别对应了加锁和解锁。但是方法体中tryAcquire和tryRelease方法没有具体实现,因为不同的锁对公平,非公平,重入,不可重入的要求不同,所以这部分的自由度比较高,需要自己定制。
我们看acquire方法:首先通过tryAcquire来获取锁,如果获取失败,则通过addWaiter将当前线程添加到队列尾部,然后通过acquireQueued来判断当前节点的线程是该阻塞呢还是不断尝试获取锁。看下面代码
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 static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
/*
* This node has already set status asking a release
* to signal it, so it can safely park.
*/
return true;
if (ws > 0) {
/*
* Predecessor was cancelled. Skip over predecessors and
* indicate retry.
*/
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
/*
* waitStatus must be 0 or PROPAGATE. Indicate that we
* need a signal, but don't park yet. Caller will need to
* retry to make sure it cannot acquire before parking.
*/
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
} private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
acquireQueued方法会判断当前节点的前置节点是不是head节点,如果是且尝试获取到了锁(说明head节点已经释放锁),那么则设置当前节点为head节点,当先线程也不需要阻塞。如果前置阶段不为head节点或者尝试获取锁失败,那么就通过shouldParkAfterFailedAcquire方法来判断该线程是不是应该阻塞。
在shouldParkAfterFailedAcquire方法中我们可以看到对各种 waitStatus 状态的处理。特别注意ws>0时的处理:这段逻辑将队列中最后一个节点链接到了前一个没有CANCELLED的节点,即剔除了中间状态为CANCELLED的节点。这个确保了最后节点的前一个节点的状态为SIGNAL。这样的话下次循环该线程就可以放心park了。
5:接下来我们看下独占模式下的释放锁的代码
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
} protected boolean tryRelease(int arg) {
throw new UnsupportedOperationException();
}
代码逻辑比较清晰:当锁释放成功后,要唤醒下一个节点的线程。同样的tryRelease需要自己实现。
我们看看是如何唤醒下个节点的线程的。
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);
}
这个逻辑也比较简单,从后往前找到第一个状态不为CANCELLED的节点,并通过unpark唤醒它的线程。(注意这里仍然是从后向前遍历)
这里要注意一点:当head和s之间存在CANCELLED节点时,s.prev节点是CANCELLED节点(这点可能会在6里出问题)
6:线程被唤醒后?
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);
}
}
前面我们看到线程是在 acquireQueued 方法的 parkAndCheckInterrupt() 这被阻塞的。当它被唤醒后,仍在这个循环里。下次循环就能获取到锁了。
但是被唤醒节点的前置节点一定是head节点吗?理论上是的,但是通过5我们知道也可能不是head节点,而是一个CANCELLED节点。
那么被唤醒节点的前置节点是CANCELLED节点怎么处理了呢。根据逻辑,又进入了 shouldParkAfterFailedAcquire 方法,这个方法会清除两个节点间的CANCELLED节点。在经过这个方法后,就能保证在下次循环中被唤醒节点的前置节点就是head节点。
6:为什么从后向前遍历?
看了半天也没看出来为啥从后向前遍历。
我们看了 volatile Node next 属性的注释
/**
* Link to the successor node that the current node/thread
* unparks upon release. Assigned during enqueuing, adjusted
* when bypassing cancelled predecessors, and nulled out (for
* sake of GC) when dequeued. The enq operation does not
* assign next field of a predecessor until after attachment,
* so seeing a null next field does not necessarily mean that
* node is at end of queue. However, if a next field appears
* to be null, we can scan prev's from the tail to
* double-check. The next field of cancelled nodes is set to
* point to the node itself instead of null, to make life
* easier for isOnSyncQueue.
*/
volatile Node next;
红字表出来的意思是,"enq操作在当前节点加入队列后,才将前置节点的next指向最后的节点。这说明我们从前向后遍历时,看到一个next为null的节点并不意味着他是最后一个节点。但是从后向前遍历却能避免这个问题"
结合代码我们再看一下
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
8 node.prev = t;
9 if (compareAndSetTail(t, node)) {
10 t.next = node;
return t;
}
}
}
}
对应的8,9,10行。因为不是原子操作,有可能出现:第9行执行成功后(此时新节点已经添加到了队列尾部),有个线程从前到后遍历各个节点,由于前置节点t.next==null,所以新追加到队列尾部的节点无法被扫描到。相反的从后向前的话,第8行就避免了这个问题。
7:总结
1:AQS的本质是CAS自旋 volatile 变量
2:阻塞的线程被有序的排列在FIFO中
3:线程的阻塞和唤醒用的是LockSupport.park()和LockSupport.unpark()
4: sleep, wait, park的区别:
sleep, 进入TIMED_WAITING状态,不出让锁;
wait, 进入TIMED_WAITING状态,出让锁,并进入对象的等待队列,必须结合sychronized使用。
park, 进入WAITING状态,对比wait不需要获得锁就可以让线程WAITING,通过unpark唤醒
关于线程阻塞和等待状态的区别见:https://blog.csdn.net/Mrxingyong/article/details/95164329
AQS(AbstractQueuedSynchronizer)解析的更多相关文章
- 高并发第十一弹:J.U.C -AQS(AbstractQueuedSynchronizer) 组件:Lock,ReentrantLock,ReentrantReadWriteLock,StampedLock
既然说到J.U.C 的AQS(AbstractQueuedSynchronizer) 不说 Lock 是不可能的.不过实话来说,一般 JKD8 以后我一般都不用Lock了.毕竟sychronize ...
- AQS(AbstractQueuedSynchronizer)介绍-01
1.概述 AQS( AbstractQueuedSynchronizer ) 是一个用于构建锁和同步器的框架,许多同步器都可以通过AQS很容易并且高效地构造出来.如: ReentrantLock 和 ...
- 从ReentrantLock看AQS (AbstractQueuedSynchronizer) 运行流程
从ReentrantLock看AQS (AbstractQueuedSynchronizer) 运行流程 概述 本文将以ReentrantLock为例来讲解AbstractQueuedSynchron ...
- AQS原理解析 AbstractQueuedSynchronizer
AQS实现原理 https://blog.csdn.net/ym123456677/article/details/80381354 https://www.cnblogs.com/keleli ...
- 高并发第十单:J.U.C AQS(AbstractQueuedSynchronizer) 组件:CountDownLatch. CyclicBarrier .Semaphore
这里有一篇介绍AQS的文章 非常好: Java并发之AQS详解 AQS全名:AbstractQueuedSynchronizer,是并发容器J.U.C(java.lang.concurrent)下lo ...
- 高并发编程-AQS深入解析
要点解说 AbstractQueuedSynchronizer简称AQS,它是java.util.concurrent包下CountDownLatch/FutureTask/ReentrantLock ...
- AbstractQueuedSynchronizer解析
AbstractQueuedSynchronizer简称为AQS,是juc里很基本的一个包,juc里很多工具类是基于AQS实现的,理解了AQS,其它很多juc工具类也会比较清楚了. 1.方法简述 ge ...
- 5. AQS(AbstractQueuedSynchronizer)抽象的队列式的同步器
5.1 AbstractQueuedSynchronizer里面的设计模式--模板模式 模板模式:父类定义好了算法的框架,第一步做什么第二步做什么,同时把某些步骤的实现延迟到子类去实现. 5.1.1 ...
- AQS(AbstractQueuedSynchronizer)应用案例-02
1.概述 通过对AQS源码的熟悉,我们可以通过实现AQS实现自定义的锁来加深认识. 2.实现 1.首先我们确定目标是实现一个独占模式的锁,当其中一个线程获得资源时,其他线程再来请求,让它进入队列进行公 ...
随机推荐
- CQRS+ES项目解析-Diary.CQRS
在<当我们在讨论CQRS时,我们在讨论些神马>中,我们讨论了当使用CQRS的过程中,需要关心的一些问题.其中与CQRS关联最为紧密的模式莫过于Event Sourcing了,CQRS与ES ...
- 在Docker中跑Hadoop与镜像制作
重复造轮子,这里使用重新打包生成一个基于Docker的Hadoop镜像: Hadoop集群依赖的软件分别为:jdk.ssh等,所以只要这两项还有Hadoop相关打包进镜像中去即可: 配置文件准 ...
- 微信小程序 存储数据到本地以及本地获取数据
1.wx存储数据到本地以及本地获取数据 存到本地就是存到你的手机 wx.setStorageSync与wx.setStorage 1.1 wx.setStorageSync(string key, a ...
- ASP.NET4.0中JavaScript脚本调用Web Service 方法
环境:VS2019 .net 4.0 framework 根据教材使用ScriptManager在JavaScript中调用Web service 时,失败.现将过程和解决方法记录如下: 1.定义W ...
- springmvc: No converter found for return value of type
刚开始学习springmvc的童鞋,相信很多都需要过这种情况,报错信息如下 org.springframework.http.converter.HttpMessageNotWritableExcep ...
- Linux 实验 [Day 01]
目录 1. Linux 简介(略过) 2. Linux 基本概念及操作:命令.快捷键与通配符 2.1 基础命令 2.2 终端快捷键 2.3 通配符 2.4 帮助命令 3. 用户及文件权限管理 3.1 ...
- java之枚举和注解
JDK1.5新增的enum关键字用于定义枚举类. 枚举类和普通类的区别: 使用enum定义的枚举类默认继承了java.lang.Enum类: 枚举类的构造器只能使用private修饰符: 枚举类的所有 ...
- Java对象导论
Java对象导论 1.1 抽象过程 万物皆对象. 程序是对象的集合(即:类),他们通过发送消息(调用方法)来告知彼此要做的. 每个对象都有自己的由其他对象所构成的存储(引用其他对象或基本类型,即组合) ...
- Prometheus学习系列(三)之Prometheus 概念:数据模型、metric类型、任务、实例
前言 本文来自Prometheus官网手册1.Prometheus官网手册2 和 Prometheus简介 说明 Prometheus从根本上存储的所有数据都是时间序列: 具有时间戳的数据流只属于单个 ...
- List<string>和string[]数组之间的相互转换,需要的朋友可以参考下
1,从System.String[]转到List<System.String> System.String[] str={"str","string" ...