深入理解Java并发框架AQS系列（一）：线程
深入理解Java并发框架AQS系列（二）：AQS框架简介及锁概念
深入理解Java并发框架AQS系列（三）：独占锁（Exclusive Lock）
深入理解Java并发框架AQS系列（四）：共享锁（Shared Lock）

一、前言

独占锁虽说在

j.u.c

synchronized

j.u.c

Semaphore

CountDownLatch

Semaphore

二、简介

共享锁其实是相对独占锁而言的，涉及到共享锁就要聊到并发度，即同一时刻最多允许同时执行线程的数量。上图所述的并发度为3，即在同一时刻，最多可有3个人在同时过河。

但共享锁的并发度也可以设置为1，此时它可以看作是一个特殊的独占锁

2.1、

waitStatus

在独占锁章节中，我们介绍到了关键的状态标记字段

waitStatus

• 0

• SIGNAL (-1)

• CANCELLED (1)

而这些取值在共享锁中也都存在，含义也保持一致，而除了上述这3个取值外，共享锁还额外引入了新的取值：

• PROPAGATE (-3)

且

-3

2.2、使用场景

本人参加的某性能挑战赛中，有这样一个场景：数据产生于CPU，且有12个线程在不断的制造数据，而这些数据需要持久化到磁盘中，由于数据产生的非常快，此时的瓶颈卡在IO上；磁盘的性能经过基准测试，发现每次写入8K数据，且开4个线程写入时，能将IO打满；但如何控制在同一时刻，最多有4个线程进行IO写入呢？

其实这是一个典型的使用共享锁的场景，我们用三四行代码即可解决

// 设置共享锁的并发度为4
Semaphore semaphore = new Semaphore(4);
// 加锁
semaphore.acquire();
// 执行数据存储
storeIO();
// 释放锁
semaphore.release();

三、并发

3.1、独占锁 vs 共享锁

共享锁的整体流程与独占锁相似，都是首先尝试去获取资源（子类逻辑，一般是CAS操作）

• 如果能拿到资源，那么进入同步块执行业务代码；当同步块执行 ad8 完毕后，唤醒阻塞队列的头结点
• 如果资源已空，那么进入阻塞队列并挂起，等待被其他线程唤醒

两者的不同点在什么地方呢？就在于“唤醒阻塞队列的头结点”的操作。在独占锁时，唤醒头结点的操作，只会有一个线程（加锁成功的线程调用

release()

直观感觉这样设计不太合理：如果多个线程同时去唤醒头结点，而头结点只能被唤醒一次，假定阻塞队列中有20个节点，那这些节点只能等待上一个节点执行完毕后才会被唤醒，无形中共享锁的并发度变成了1。要解决这个疑问，我们先来看共享锁的释放逻辑

3.2、锁释放

先来思考一下锁释放需要做的事儿

• 1、阻塞队列的第一个节点一定要被激活；这个问题看似不值一提，却相当重要，区别于独占锁，共享锁的锁释放是存在并发的，在高并发的流量下，一定要保证阻塞队列的第一个有效节点被激活，否则会导致阻塞队列永久性的挂死
• 2、保证激活阻塞队列时的并发度；这个问题同样也是独占锁不存在的，也就是我们在3.1提出的问题；假定这样一种场景：“共享锁的并发度为10，阻塞队列中有100个待处理的节点，而此时又没有新的加锁请求，如何保证在激活阻塞队列时，保持10的并发度？”

共享锁如何解决这两个问题呢？我们接下来逐一阐述

3.2.1、调用点

与独占锁不同，共享锁调用“锁释放”有2个地方（注：AQS的一个阻塞队列是可以同时添加独占节点、共享节点的，为了简化模型，我们这里暂不讨论这种混合模型）

• a、某线程同步块执行完毕，正常调用解锁逻辑；此点与独占锁一致
• b、在每次更换头结点时，如果满足以下任一条件，同样会调用“锁释放”；更换头结点的操作，其实此时已经意味着当前线程已经加锁成功 b.1、有额外的资源可用；拿信号量举例，当发现信号量数量>0时，表示有额外资源可用
• b.2、旧的头结点或当前头结点的

  ws < 0

那这两个点调用的时候，是否存在并发呢？有同学会说“a存在并发，b是串行的”；其实此处b也是存在并发的，例如线程1更换了head节点后，准备执行“锁释放”逻辑，正在此时，线程2正常锁释放后，唤醒了新的head节点（线程3），线程3又会执行更换head节点，并准备执行“锁释放”逻辑；此时线程1跟线程3都准备执行“锁释放”逻辑

既然“锁释放”存在这么多并发，那就一定要保证“锁释放”逻辑是幂等的，那它又是如何做到呢？

3.2.1、锁释放

直接贴一下它的源码吧，释放锁的代码寥寥几笔，却很难说它简单

private void doReleaseShared() {
for (;;) {
Node h = head;
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;
}
}

对应的流程图如下：

我们简单描述一下锁释放做的事儿

• 1、首选获取头结点的快照，并将其赋予变量

  h

  ，同时获取

  h.waitStatus

  ，并标记位

  ws

• 2、判断

  ws

  的状态

  ws == -1

  表示下一个节点已经挂起，或即将挂起。如果只要发现是-1状态，就进行线程唤起的话，因为存在并发，可能导致目标线程被唤起多次，故此处需要通过CAS进行抢锁，保证只有一个线程去唤起

• ws == 0

  如果发现节点

  ws

  为0，此处会存在两种情况（情况1：节点刚新建完毕，还未进入阻塞队列；情况2：节点由-1修改为了0），不管哪种情况，都强制将其由-1改为-3，标记位强制传播，此处是否存在漏洞？

• ws == -3

  表示当前节点已经被标识为强制传播了，直接结束

h == head

根据以上分析，我们发现，节点的状态流转是通过

ws

3.2.2、

ws

状态流转

仅有2个功能点会对

ws

我们将加入阻塞队列时

ws

• 状态为0（初始状态），加入阻塞队列前，需要将前节点修改为-1，然后进入线程挂起
• 状态为-3（强制传播状态，被解锁线程标记），加入阻塞队列前，同样需要将前节点修改为-1，然后进入线程挂起

综述，我们出一张

ws

由上图可得知，只要解锁逻辑成功通过CAS将head节点由

-1

0

整个流转过程有bug吗？我们设想如下场景：共享锁的并发度设置为1，A、B两个线程同时进入加锁逻辑，B线程成功抢到锁，并开始进入同步块，A线程抢锁失败，准备挂到阻塞队列，正常流程是A线程将

ws

ws

ws

然而事实并非如此，因为只要A线程将

ws

3.3、保证并发度

阻塞队列中节点的激活顺序是什么样呢？其实激活顺序3.2章节已经描述的较为清楚，解锁的逻辑只负责激活头节点，那如何保证共享锁的并发度？

我们还是假定这样一个场景：共享锁的并发度为5，阻塞队列中有20个节点，只有head节点已被唤醒，且没有新的请求进入，我们希望在同一时刻，同时有5个节点处于激活状态。针对上述场景，aqs如何做到呢？

其实head节点被激活时，在第一时间会通知后续节点，并将其唤醒，然后才会执行同步块逻辑，保证了等待中的节点快速激活