【JDK】JDK源码分析-AbstractQueuedSynchronizer(3)
概述
前文「JDK源码分析-AbstractQueuedSynchronizer(2)」分析了 AQS 在独占模式下获取资源的流程,本文分析共享模式下的相关操作。
其实二者的操作大部分是类似的,理解了前面对独占模式的分析,再分析共享模式就相对容易了。
共享模式
方法概述
与独占模式类似,共享模式下也有与之类似的相应操作,分别如下:
1. acquireShared(int arg): 以共享模式获取资源,忽略中断;
2. acquireSharedInterruptibly(int arg): 以共享模式获取资源,响应中断;
3. tryAcquireSharedNanos(int arg, long nanosTimeout): 以共享模式获取资源,响应中断,且有超时等待;
4. releaseShared(int arg): 释放资源,唤醒后继节点,并确保传播。
它们的操作与独占模式也比较类似,下面具体分析。
方法分析
1. 共享模式获取资源(忽略中断)
acquireShared:
public final void acquireShared(int arg) {
// 返回值小于 0,表示获取失败
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
} // 尝试以共享模式获取资源(返回值为 int 类型)
protected int tryAcquireShared(int arg) {
throw new UnsupportedOperationException();
}
与独占模式的 tryAcquire 方法类似,tryAcquireShared 方法在 AQS 中也抛出异常,由子类实现其逻辑。
不同的地方在于,tryAcquire 方法的返回结果是 boolean 类型,表示获取成功与否;而 tryAcquireShared 的返回结果是 int 类型,分别为:
1) 负数:表示获取失败;
2) 0:表示获取成功,但后续共享模式的获取会失败;
3) 正数:表示获取成功,后续共享模式的获取可能会成功(需要进行检测)。
若 tryAcquireShared 获取成功,则直接返回;否则执行 doAcquireShared 方法:
private void doAcquireShared(int arg) {
// 把当前线程封装成共享模式的 Node 节点,插入主队列末尾
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
// 中断标志位
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
// 若前驱节点为头节点,则尝试获取资源
if (p == head) {
int r = tryAcquireShared(arg);
// 这里表示当前线程成功获取到了资源
if (r >= 0) {
// 设置头节点,并传播状态(注意这里与独占模式不同)
setHeadAndPropagate(node, r);
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
// 是否应该休眠(与独占模式相同,不再赘述)
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
// 取消操作(与独占模式相同)
cancelAcquire(node);
}
}
doAcquireShared 方法会把当前线程封装成一个共享模式(SHARED)的节点,并插入主队列末尾。addWaiter(Node mode) 方法前文已经分析过,不再赘述。
该方法与 acquireQueued 方法的区别在于 setHeadAndPropagate 方法,把当前节点设置为头节点之后,还会有传播(propagate)行为:
private void setHeadAndPropagate(Node node, int propagate) {
// 记录旧的头节点
Node h = head; // Record old head for check below
// 将 node 设置为头节点
setHead(node);
/*
* Try to signal next queued node if:
* Propagation was indicated by caller,
* or was recorded (as h.waitStatus either before
* or after setHead) by a previous operation
* (note: this uses sign-check of waitStatus because
* PROPAGATE status may transition to SIGNAL.)
* and
* The next node is waiting in shared mode,
* or we don't know, because it appears null
*
* The conservatism in both of these checks may cause
* unnecessary wake-ups, but only when there are multiple
* racing acquires/releases, so most need signals now or soon
* anyway.
*/
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
// 后继节点为空或共享模式唤醒
if (s == null || s.isShared())
doReleaseShared();
}
}
doReleaseShared:
private void doReleaseShared() {
/*
* Ensure that a release propagates, even if there are other
* in-progress acquires/releases. This proceeds in the usual
* way of trying to unparkSuccessor of head if it needs
* signal. But if it does not, status is set to PROPAGATE to
* ensure that upon release, propagation continues.
* Additionally, we must loop in case a new node is added
* while we are doing this. Also, unlike other uses of
* unparkSuccessor, we need to know if CAS to reset status
* fails, if so rechecking.
*/
for (;;) {
// 这里的头节点已经是上面设置后的头节点了
Node h = head;
// 由于该方法有两个入口(setHeadAndPropagate 和 releaseShared),需考虑并发控制
if (h != null && h != tail) {
int ws = h.waitStatus;
if (ws == Node.SIGNAL) {
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue; // loop to recheck cases
// 唤醒后继节点
unparkSuccessor(h);
}
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue; // loop on failed CAS
}
// 若头节点不变,则跳出循环;否则继续循环
if (h == head) // loop if head changed
break;
}
}
该方法与独占模式下的获取方法 acquire 大体相似,不同在于该方法中,节点获取资源后会传播状态,即,有可能会继续唤醒后继节点。值得注意的是:该方法有两个入口 setHeadAndPropagate 和 releaseShared,可能有多个线程操作,需考虑并发控制。
此外,本人对于将节点设置为 PROPAGATE 状态的理解还不是很清晰,网上说法也不止一种,待后续研究明白再补充。
2. 以共享模式获取资源(响应中断)
该方法与 acquireShared 类似:
public final void acquireSharedInterruptibly(int arg)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
if (tryAcquireShared(arg) < 0)
doAcquireSharedInterruptibly(arg);
}
tryAcquireShared 方法前面已分析,若获取资源失败,则会执行 doAcquireSharedInterruptly 方法:
private void doAcquireSharedInterruptibly(int arg)
throws InterruptedException {
// 把当前线程封装成共享模式节点,并插入主队列
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
if (p == head) {
int r = tryAcquireShared(arg);
if (r >= 0) {
setHeadAndPropagate(node, r);
p.next = null; // help GC
failed = false;
return;
}
}
// 与 doAcquireShared 相比,区别在于这里抛出了异常
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}
从代码可以看到,acquireSharedInterruptibly 方法与 acquireShared 方法几乎完全一样,不同之处仅在于前者会抛出 InterruptedException 异常响应中断;而后者仅记录标志位,获取结束后才响应。
3. 以共享模式获取资源(响应中断,且有超时)
代码如下(该方法可与前文独占模式下的超时获取方法比较分析):
public final boolean tryAcquireSharedNanos(int arg, long nanosTimeout)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
return tryAcquireShared(arg) >= 0 ||
doAcquireSharedNanos(arg, nanosTimeout);
}
doAcquireSharedNanos:
private boolean doAcquireSharedNanos(int arg, long nanosTimeout)
throws InterruptedException {
if (nanosTimeout <= 0L)
return false;
final long deadline = System.nanoTime() + nanosTimeout;
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
if (p == head) {
int r = tryAcquireShared(arg);
if (r >= 0) {
setHeadAndPropagate(node, r);
p.next = null; // help GC
failed = false;
return true;
}
}
nanosTimeout = deadline - System.nanoTime();
if (nanosTimeout <= 0L)
return false;
if (shouldParkAfterFailedAcquire(p, node) &&
nanosTimeout > spinForTimeoutThreshold)
LockSupport.parkNanos(this, nanosTimeout);
if (Thread.interrupted())
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}
该方法可与独占模式下的超时等待方法 tryAcquireNanos(int arg, long nanosTimeout) 进行对比,二者操作基本一致,不再详细分析。
4. 释放资源,唤醒节点,传播状态
如下:
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}
tryReleaseShared:
protected boolean tryReleaseShared(int arg) {
throw new UnsupportedOperationException();
}
doReleaseShared() 方法前面已经分析过了。本方法与独占模式的 release 方法类似,不同的地方在于“传播”二字。
场景分析
为了便于理解独占模式和共享模式下队列和节点的状态,下面简要举例分析。
场景如下:有 T0~T4 共 5 个线程按先后顺序获取资源,其中 T2 和 T3 为共享模式,其他均为独占模式。
就此场景分析:T0 先获取到资源(假设占用时间较长),而后 T1~T4 再获取则失败,会依次进入主队列。此时主队列中各个节点的状态示意图如下:
之后,T0 操作完毕并释放资源,会将 T1 唤醒。T1(独占模式) 会从 acquireQueued(final Node node, int arg) 方法的循环中继续获取资源,这时会获取成功,并将 T1 设置为头节点(T 被移除)。此时主队列节点示意图如下:
此时,T1 获取到资源并进行相关操作。
而后,T1 操作完释放资源,并唤醒下一个节点 T2,T2(共享模式) 继续从 doAcquireShared(int) 方法的循环中执行。此时 T2 获取资源成功,将自身设为头节点(T1 被移除),由于后继节点 T3 也是共享模式,因此 T1 会继续唤醒 T3;T3 唤醒后的操作与 T2 相同,但后继节点 T4 不是共享模式,因此不再继续唤醒。此时队列节点状态示意图如下:
此时,T2 和 T3 同时获取到资源。
之后,当二者都释放资源后会唤醒 T4:
T4 获取资源的与 T1 类似。
PS: 该场景仅供参考,只为便于理解,若有不当之处敬请指正。
小结
本文分析了以共享模式获取资源的三种方式,以及释放资源的操作。分别为:
1. acquireShared: 共享模式获取资源,忽略中断;
2. acquireSharedInterruptibly: 共享模式获取资源,响应中断;
3. tryAcquireSharedNanos: 共享模式获取资源,响应中断,有超时;
4. releaseShared: 释放资源,唤醒后继节点,并确保传播。
并简要分析一个场景下主队列中各个节点的状态。此外,AQS 中还有嵌套类 ConditionObject 及条件队列的相关操作,后面涉及到的时候再进行分析。
单独去分析 AQS 的源码比较枯燥,后文会结合 ReentrantLock、CountdownLatch 等常用并发工具类的源码进行分析。
上述解析是参考其他资料及个人理解,若有不当之处欢迎指正。
相关阅读:
JDK源码分析-AbstractQueuedSynchronizer(2)
JDK源码分析-AbstractQueuedSynchronizer(1)
Stay hungry, stay foolish.
PS: 本文首发于微信公众号【WriteOnRead】。
【JDK】JDK源码分析-AbstractQueuedSynchronizer(3)的更多相关文章
- 【JDK】JDK源码分析-AbstractQueuedSynchronizer(2)
概述 前文「JDK源码分析-AbstractQueuedSynchronizer(1)」初步分析了 AQS,其中提到了 Node 节点的「独占模式」和「共享模式」,其实 AQS 也主要是围绕对这两种模 ...
- JDK Collection 源码分析(2)—— List
JDK List源码分析 List接口定义了有序集合(序列).在Collection的基础上,增加了可以通过下标索引访问,以及线性查找等功能. 整体类结构 1.AbstractList 该类作为L ...
- JDK AtomicInteger 源码分析
@(JDK)[AtomicInteger] JDK AtomicInteger 源码分析 Unsafe 实例化 Unsafe在创建实例的时候,不能仅仅通过new Unsafe()或者Unsafe.ge ...
- 【JDK】JDK源码分析-AbstractQueuedSynchronizer(1)
概述 前文「JDK源码分析-Lock&Condition」简要分析了 Lock 接口,它在 JDK 中的实现类主要是 ReentrantLock (可译为“重入锁”).ReentrantLoc ...
- 设计模式(十八)——观察者模式(JDK Observable源码分析)
1 天气预报项目需求,具体要求如下: 1) 气象站可以将每天测量到的温度,湿度,气压等等以公告的形式发布出去(比如发布到自己的网站或第三方). 2) 需要设计开放型 API,便于其他第三方也能接入气象 ...
- AQS框架源码分析-AbstractQueuedSynchronizer
前言:AQS框架在J.U.C中的地位不言而喻,可以说没有AQS就没有J.U.C包,可见其重要性,因此有必要对其原理进行详细深入的理解. 1.AQS是什么 在深入AQS之前,首先我们要搞清楚什么是AQS ...
- JDK Collection 源码分析(3)—— Queue
@(JDK)[Queue] JDK Queue Queue:队列接口,对于数据的存取,提供了两种方式,一种失败会抛出异常,另一种则返回null或者false. 抛出异常的接口:add,remove ...
- JDK Collection 源码分析(1)—— Collection
JDK Collection JDK Collection作为一个最顶层的接口(root interface),JDK并不提供该接口的直接实现,而是通过更加具体的子接口(sub interface ...
- 【JDK】JDK源码分析-ReentrantLock
概述 在 JDK 1.5 以前,锁的实现只能用 synchronized 关键字:1.5 开始提供了 ReentrantLock,它是 API 层面的锁.先看下 ReentrantLock 的类签名以 ...
随机推荐
- visudo 与 /etc/sudoers
增加多个用户免密码登录 User_Alias USER_OPS = zouyi,hanerhui,shibeibei,gaoxudong,xiaoyuelin,wangsongfeng,sunjian ...
- Python绘制语谱图+时域波形
"""Python绘制语谱图""" """Python绘制时域波形""" # 导 ...
- IO侦探:多进程写ceph-fuse单文件性能瓶颈侦查
近期接到ceph用户报案,说是多进程direct写ceph-fuse的单个文件,性能很低,几乎与单进程direct写文件的性能一样.关乎民生,刻不容缓,笔者立即展开侦查工作~ 一.复现案情,寻踪追记 ...
- xshell传送文件
xshel是一款非常好的ssh远程登入的软件,最近在玩hadoop发现的想把widows上的文件通过xshell直接传送到虚拟机中 这个解决方法还是非常不错的 https://jingyan.baid ...
- Codeforces Gym101201B:Buggy Robot(BFS + DP)
题目链接 题意 给出一个n*m的地图,还有一个操作序列,你原本是要按照序列执行操作的,但是你可以修改操作:删除某些操作或者增加某些操作,问从'R'到'E'最少需要多少次修改操作. 思路 和上次比赛做的 ...
- POJ 3301:Texas Trip(计算几何+三分)
http://poj.org/problem?id=3301 题意:在二维平面上有n个点,每个点有一个坐标,问需要的正方形最小面积是多少可以覆盖所有的点. 思路:从第二个样例可以看出,将正方形旋转45 ...
- Vs连接Mysql数据库
Vs连接Mysql数据库步骤 1. 首先下载mysql数据库,安装,建库建表 https://www.yiibai.com/mysql/getting-started-with-mysql-store ...
- Oracle数据库----视图
--创建简单视图--建立用于查询员工号.姓名.工资的视图.create view emp_viewasselect empno,ename,sal from emp; --查询视图select * f ...
- C语言学习书籍推荐《学通C语言的24堂课》下载
下载地址:点我 编辑推荐 <学通C语言的24堂课>:用持续激励培养良好习惯以良好习惯铸就伟大梦想——致亲爱的读者朋友在开始学习<学通C语言的24堂课>的同时,强烈建议读者朋友同 ...
- python 的一些小项目
1.在线教育平台(视频播放) 2.仿微信网页版(语音.视频.文字聊天) 3.高德API + Python 解决租房问题 4.仿知乎 5.Django打造文件分享系统.文件管理.搜索引擎(仿云盘) 6. ...