深入理解Java并发框架AQS系列(四):共享锁(Shared Lock)

深入理解Java并发框架AQS系列(一):线程
深入理解Java并发框架AQS系列(二):AQS框架简介及锁概念
深入理解Java并发框架AQS系列(三):独占锁(Exclusive Lock)
深入理解Java并发框架AQS系列(四):共享锁(Shared Lock)
深入理解Java并发框架AQS系列(五):条件队列(Condition)

一、前言

那些“简单的”并发代码背后,隐藏着大量信息。。。

独占锁虽说在j.u.c中有现成的实现,但在JAVA的语言层面也同样提供了支持(synchronized);但共享锁却是只存在于AQS中,而它在实际生产中的使用频次丝毫不亚于独占锁,在整个AQS体系中占有举重若轻的地位。而在某种意义上,因为可能同时存在多个线程的并发,它的复杂度要高于独占锁。本章除了介绍共享锁数据结构等,还会重点对焦并发处理,看 doug lea 在并发部分是否有遗漏

j.u.c下支持的并发锁有SemaphoreCountDownLatch等,本章我们采用经典并发类Semaphore来阐述

二、简介

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

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

2.1、waitStatus

在独占锁章节中,我们介绍到了关键的状态标记字段waitStatus,它在独占锁的取值有

  • 0
  • SIGNAL (-1)
  • CANCELLED (1)

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

  • PROPAGATE (-3)

-3这个取值在整个AQS体系中,只存在于共享锁中,它的存在是为了更好的解决并发问题,我们将在后文中详细介绍

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操作

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

两者的不同点在什么地方呢?就在于“唤醒阻塞队列的头结点”的操作。在独占锁时,唤醒头结点的操作,只会有一个线程(加锁成功的线程调用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 表示当前节点已经被标识为强制传播了,直接结束
  • 3、如果此时 h == head,说明在上述逻辑发生时,头结点没有发生变化,那么结束当前操作,否则重复上述步骤。注:AQS中所有节点只有一次当头结点的机会,也就是某个节点当过一次头结点后,便会被抛弃,再无可能第二次成为头结点,这点至关重要

根据以上分析,我们发现,节点的状态流转是通过ws来控制的,即0、-1、-3,乍看上去,貌似不太严谨,那我们来做具体分析

3.2.2、ws状态流转

仅有2个功能点会对ws进行修改,一是将节点加入阻塞队列时,二就是3.2.1中描述的调用锁释放逻辑时;

我们将加入阻塞队列时ws的状态流转再回忆下:

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

综述,我们出一张ws的整体状态流转图

共享锁加入阻塞队列时ws流转

由上图可得知,只要解锁逻辑成功通过CAS将head节点由-1修改为0的话,那么就要负责唤醒阻塞队列中的第一个节点了

整个流转过程有bug吗?我们设想如下场景:共享锁的并发度设置为1,A、B两个线程同时进入加锁逻辑,B线程成功抢到锁,并开始进入同步块,A线程抢锁失败,准备挂到阻塞队列,正常流程是A线程将ws由0修改为-1后,进入挂起状态,但B线程执行较快,已经优先A线程并开始执行解锁逻辑,将ws由0修改为了-3,然后B线程正常结束;A线程发现ws为-3后,将其修改为-1,然后进入挂起。 如果这个场景真实发生的话,A线程将永久处于挂起状态,那岂不是存在漏洞?

然而事实并非如此,因为只要A线程将ws修改为-1后,都要再尝试进行一次获取锁的操作,正是这个操作避免了上述情况的发生,可见aqs是很严谨的

共享锁加入阻塞队列及解锁ws流转示意图

3.3、保证并发度

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

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

共享锁阻塞队列并发度

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

posted @ 2021-04-08 18:07  昔久  阅读(798)  评论(3编辑  收藏  举报