精美图文讲解Java AQS 共享式获取同步状态以及Semaphore的应用
| 好看请赞，养成习惯
你有一个思想，我有一个思想，我们交换后，一个人就有两个思想
If you can NOT explain it simply, you do NOT understand it well enough
现陆续将Demo代码和技术文章整理在一起 Github实践精选 ，方便大家阅读查看，本文同样收录在此，觉得不错，还请Star🌟
看到本期内容这么少，是不是心动了呢？
前言
上一篇万字长文 Java AQS队列同步器以及ReentrantLock的应用 为我们读 JUC 源码以及其设计思想做了足够多的铺垫，接下来的内容我将重点说明差异化，如果有些童鞋不是能很好的理解文中的一些内容，强烈建议回看上一篇文章，搞懂基础内容，接下来的阅读真会轻松加愉快
AQS 中我们介绍了独占式获取同步状态的多种情形：
- 独占式获取锁
- 可响应中断的独占式获取锁
- 有超时限制的独占式获取锁
AQS 提供的模版方法里面还差共享式获取同步状态没有介绍，所以我们今天来揭开这个看似神秘的面纱
AQS 中的共享式获取同步状态
独占式是你中没我，我中没你的的一种互斥形式，共享式显然就不是这样了，所以他们的唯一区别就是：
同一时刻能否有多个线程同时获取到同步状态
简单来说，就是这样滴：
我们知道同步状态 state 是维护在 AQS 中的，抛开可重入锁的概念，我在上篇文章中也提到了，独占式和共享式控制同步状态 state 的区别仅仅是这样：
所以说想了解 AQS 的 xxxShared 的模版方法，只需要知道它是怎么控制 state 的就好了
AQS共享式获取同步状态源码分析
为了帮助大家更好的回忆内容，我将上一篇文章的两个关键内容粘贴在此处，帮助大家快速回忆，关于共享式，大家只需要关注【骚紫色】就可以了
自定义同步器需要重写的方法
AQS 提供的模版方法
故事就从这里说起吧 (你会发现和独占式惊人的相似)，关键代码都加了注释
public final void acquireShared(int arg) {
// 同样调用自定义同步器需要重写的方法，非阻塞式的尝试获取同步状态，如果结果小于零，则获取同步状态失败
if (tryAcquireShared(arg) < 0)
// 调用 AQS 提供的模版方法，进入等待队列
doAcquireShared(arg);
}
进入 doAcquireShared 方法：
private void doAcquireShared(int arg) {
// 创建共享节点「SHARED」，加到等待队列中
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);
}
}
上面代码第 18 行我们提到和独占式获取同步状态的区别，贴心的给大家一个更直观的对比：
差别只在这里，所以我们就来看看 setHeadAndPropagate(node, r) 到底干了什么，我之前说过 JDK 源码中的方法命名绝大多数还是非常直观的，该方法直译过来就是 【设置头并且传播/繁衍】。独占式只是设置了头，共享式除了设置头还多了一个传播，你的疑问应该已经来了：
啥是传播，为什么会有传播这个设置呢？
想了解这个问题，你需要先知道非阻塞共享式获取同步状态返回值的含义：
这里说的传播其实说的是 propagate > 0 的情况，道理也很简单，当前线程获取同步状态成功了，还有剩余的同步状态可用于其他线程获取，那就要通知在等待队列的线程，让他们尝试获取剩余的同步状态
如果要让等待队列中的线程获取到通知，需要线程调用 release 方法实现的。接下来，我们走近 setHeadAndPropagate 一探究竟，验证一下
// 入参，node： 当前节点
// 入参，propagate：获取同步状态的结果值，即上面方法中的变量 r
private void setHeadAndPropagate(Node node, int propagate) {
// 记录旧的头部节点，用于下面的check
Node h = head;
// 将当前节点设置为头节点
setHead(node);
// 通过 propagate 的值和 waitStatus 的值来判断是否可以调用 doReleaseShared 方法
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
// 如果后继节点为空或者后继节点为共享类型，则进行唤醒后继节点
// 这里后继节点为空意思是只剩下当前头节点了，另外这里的 s == null 也是判断空指针的标准写法
if (s == null || s.isShared())
doReleaseShared();
}
}
上面方法的大方向作用我们了解了，但是代码中何时调用 doReleaseShared 的判断逻辑还是挺让人费解的，为什么会有这么一大堆的判断，我们来逐个分析一下：
这里的空判断有点让人头大，我们先挑出来说明一下：
排除了其他判断条件的干扰，接下来我们就专注分析 propagate 和 waitStatus 两个判断条件就可以了，这里再将 waitStatus 的几种状态展示在这里，帮助大家理解，【骚粉色】是我们一会要用到的：
propagate > 0
上面已经说过了，如果成立，直接短路后续判断，然后根据 doReleaseShared 的判断条件进行释放
propagate > 0 不成立， h.waitStatus < 0 成立 （注意这里的h是旧的头节点）
什么时候 h.waitStatus < 0 呢？抛开 CONDITION 的使用，只剩下 SIGNAL 和 PROPAGATE，想知道这个答案，需要提前看一下 doReleaseShared() 方法了：
private void doReleaseShared() {
for (;;) {
Node h = head;
if (h != null && h != tail) {
int ws = h.waitStatus;
if (ws == Node.SIGNAL) {
// CAS 将头节点的状态设置为0
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue; // loop to recheck cases
// 设置成功后才能跳出循环唤醒头节点的下一个节点
unparkSuccessor(h);
}
else if (ws == 0 &&
// 将头节点状态CAS设置成 PROPAGATE 状态
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue; // loop on failed CAS
}
if (h == head) // loop if head changed
break;
}
}
从 doReleaseShared() 方法中可以看出：
-
如果让 h.waitStatus < 0 成立，只能将其设置成 PROPAGATE = -3 的情况，设置成功的前提是 h 头节点 expected 的状态是 0；
-
如果 h.waitStatus = 0，是上述代码第 8 行 CAS 设置成功，然后唤醒等待中的线程
所以猜测，当前线程执行到 h.waitStatus < 0 的判断前，有另外一个线程刚好执行了 doReleaseShared() 方法，将 waitStatus 又设置成PROPAGATE = -3
这个理解有点绕，我们还是来画个图理解一下吧：
可能有同学还是不太能理解这么写的道理，我们一直说 propagate <> = 0 的情况，propagate = 0 代表的是当时/当时/当时 尝试获取同步状态没成功，但是之后可能又有共享状态被释放了，所以上面的逻辑是以防这种万一，你懂的，严谨的并发就是要防止一切万一，现在结合这个情景再来理解上面的判断你是否豁然开朗了呢？
继续向下看，
前序条件不成立，(h = head) == null || h.waitStatus < 0 注意这里的h是新的头节点）
有了上面铺垫，这个就直接画个图就更好理解啦，其实就是没有那么巧有另外一个线程掺合了
相信到这里你应该理解共享式获取同步状态的全部过程了吧，至于非阻塞共享式获取同步状态和带有超时时间获取同步状态，结合本文讲的 setHeadAndPropagate 逻辑和独占式获取同步状态的实现过程过程来看，真是一毛一样，这里就不再累述了，赶紧打开你的 IDE 去验证一下吧
我们分析了AQS 的模版方法，还一直没说 tryAcquireShared(arg) 这个方法是如何被重写的，想要了解这个，我们就来看一看共享式获取同步状态的经典应用 Semaphore
Semaphore 的应用及源码分析
Semaphore 概念
Semaphore 中文多翻译为 【信号量】，我还特意查了一下剑桥辞典的英文解释：
其实就是信号标志（two flags），比如红绿灯，每个交通灯产生两种不同行为
- Flag1-红灯：停车
- Flag2-绿灯：行车
在 Semaphore 里面，什么时候是红灯，什么时候是绿灯，其实就是靠 tryAcquireShared(arg) 的结果来表示的
- 获取不到共享状态，即为红灯
- 获取到共享状态，即为绿灯
所以我们走近 Semaphore ，来看看它到底是怎么应用 AQS 的，又是怎样重写 tryAcquireShared(arg) 方法的
Semaphore 源码分析
先看一下类结构
看到这里你是否有点跌眼镜，和 ReentrantLock 相似的可怕吧，如果你有些陌生，再次强烈建议你回看上一篇文章 Java AQS队列同步器以及ReentrantLock的应用 ，这里直接提速对比看公平和非公平两种重写的 tryAcquireShared(arg) 方法，没有意外，公平与否，就是判断是否有前驱节点
方法内部只是计算 state 的剩余值，那 state 的初始值是多少怎么设置呢？当然也就是构造方法了：
public Semaphore(int permits) {
// 默认仍是非公平的同步器，至于为什么默认是非公平的，在上一篇文章中也特意说明过
sync = new NonfairSync(permits);
}
NonfairSync(int permits) {
super(permits);
}
super 方法，就会将初始值给到 AQS 中的 state
也许你发现了，当我们把 permits 设置为1 的时候，不就是 ReentrantLock 的互斥锁了嘛，说的一点也没错，我们用 Semaphore 也能实现基本互斥锁的效果
static int count;
//初始化信号量
static final Semaphore s
= new Semaphore(1);
//用信号量保证互斥
static void addOne() {
s.acquire();
try {
count+=1;
} finally {
s.release();
}
}
But（英文听力中的重点），Semaphore 肯定不是为这种特例存在的，它是共享式获取同步状态的一种实现。如果使用信号量，我们通常会将 permits 设置成大于1的值，不知道你是否还记得我曾在 为什么要使用线程池? 一文中说到的池化概念，在同一时刻，允许多个线程使用连接池，每个连接被释放之前，不允许其他线程使用。所以说 Semaphore 可以允许多个线程访问一个临界区，最终很好的做到一个限流/限流/限流 的作用
虽然 Semaphore 能很好的提供限流作用，说实话，Semaphore 的限流作用比较单一，我在实际工作中使用 Semaphore 并不是很多，如果真的要用高性能限流器，Guava RateLimiter 是一个非常不错的选择，我们后面会做分析，有兴趣的可以提前了解一下
关于 Semaphore 源码，就这么三下五除二的结束了
总结
不知你有没有感觉到，我们的节奏明显加快了，好多原来分散的点在被疯狂的串联起来，如果按照这个方式来阅读 JUC 源码，相信你也不会一头扎进去迷失方向，然后沮丧的退出 JUC 吧，然后面试背诵答案，然后忘记，然后再背诵？
跟上节奏，关于共享式获取同步状态，Semaphore 只不过是非常经典的应用，ReadWriteLock 和 CountDownLatch 日常应用还是非常广泛的，我们接下来就陆续聊聊它们吧
灵魂追问
- Semaphore 的 permits 设置成1 “等同于” 简单的互斥锁实现，那它和 ReentrantLock 的区别还是挺大的，都有哪些区别呢？
- 你在项目中是如何使用 Semaphore 的呢？
参考
- Java 并发实战
- Java 并发编程的艺术
- https://blog.csdn.net/anlian523/article/details/106319294
