JUC并发编程高级篇第七章之AQS(读写锁的优化实践)

爱吃糖的靓仔

已于 2023-04-11 10:30:37 修改

阅读量505

点赞数

分类专栏： # 并发编程文章标签： java 开发语言

于 2023-04-10 18:19:54 首次发布

本文链接：https://blog.csdn.net/qq_42292373/article/details/130017260

版权

并发编程专栏收录该内容

22 篇文章 1 订阅

订阅专栏

文章详细介绍了AQS（AbstractQueuedSynchronizer）的核心概念，包括其作为锁和同步组件的基础，如何通过FIFO队列管理线程等待，以及在ReentrantLock中的具体应用。AQS通过state变量和CLH队列变体实现线程的阻塞和唤醒，简化了锁的实现。文章通过ReentrantLock的lock()方法，展示了加锁的三个阶段：尝试加锁、线程入列和线程阻塞。

摘要由CSDN通过智能技术生成

1、AQS简介

1.1、什么是AQS

主要用于解决锁分配给"谁"的问题体就是一个抽象的FIFO队列来完成资源获取线程的排队工作，并通过一个int类变量表示持有锁的状态
比如常用的lock. unlock ，他们如何锁住线程的？阻塞的线程阻塞实现的具体逻辑是什么,这些统统都是AQS实现，可以这么说AQS提出统一规范并简化了锁的实现，将其抽象出来屏蔽了同步状态管理、同步队列的管理和维护、阻塞线程排队和通知、唤醒机制等，
是一切锁和同步组件实现的公共基础部分，由AQS由此衍生出了许多我们耳熟能详的JUC工具类ReentrantLock；CountDownLatch；ReetrantReadWriteLock；Semaphore …
可以这么说AQS就是JUC编程核心中的核心！！！！！

1.2、AQS 能干嘛

抢到资源的线程直接使用处理业务，抢不到资源的必然涉及一种排队等候机制(AQS实现的）。抢占资源失败的线程继续去等待，但等候线程仍然保留获取锁的可能且获取锁流程仍在继续。(AQS实现的）
如果共享资源被占用，就需要一定的阻塞等待唤醒机制来保证锁分配(AQS实现的）。这个机制主要用的是CLH队列的变体实现的，将暂时获取不到锁的线程加入到队列中，这个队列就是AQS同步队列的抽象表现。它将要请求共享资源的线程及自身的等待状态封装成队列的结点对象(Node)，通过CAS、自旋以及LockSupport park()的方式，维护state变量的状态，使并发达到同步的效果。

解释说明：AQS使用一个volatile的int类型的成员变量来表示周步状态，通过内置的FIFO队列来完成资源获取的排队工作将每条要去抢占资源的线程封装成- -个Node节点来实现锁的分配，通过CAS完成对State值的修改。

在这里插入图片描述

2、AQS的源码深度讲解和分析

因为ReentrantLock就是AQS实现的，所以本次通过ReentrantLock来讲解下AQS具体的实现逻辑

2.1、ReentrantLock的基本架构

从源码中我们可以看出公平锁和非公平的锁，唯一区别就在于：公平锁多加了一个HasQueuePredecessor（) 方法其他和非公平锁实现一致；
在这里插入图片描述

2.2、lock()

还是老规矩, 先给出思维导图 ; 思维导图流程图如下
在这里插入图片描述

A线程第一个来, 线程没有争抢,先办理业务
第一个线程A进来了,没有和他争抢,此时抢占锁,把state状态修改为1,并赋值当前线程为抢占线程;
在这里插入图片描述

B线程尝试抢锁,失败了,打算进入到等待席(tryAcquire)
第二个线程B尝试抢占锁,但是CAS比较失败,进入到acquire(1),再进入到tryAcquire->子类的nonfairTryAcquire; 此时c=1 并且 getExclusiveOwnerThread != threadB 返回false

acquire源码↓↓↓↓
在这里插入图片描述
nonfairTryAcquire源码

B线程进入到等待席(tryAcquire->addWaiter)
线程B封装到Node节点中,检查下席位有没有数据,没有数据的话,进入到enq(node)；
在这里插入图片描述

enq方法自己给我们New Node一个新节点[不是线程B节点哦],放到头结点;双向链表中，第一个节点为虚节点(也叫哨兵节点)，其实并不存储任何信息，只是占位。真正的第一个有数据的节点，是从第二个节点开始的。.
在这里插入图片描述

因为他是for(; ; ) 第二次检查,把队尾指向线程B,然后进行new Node进行cas,并且
在这里插入图片描述

C线程抢占锁,入队(tryAcquire->addWaiter) ; 和之前相比,因为尾结点不为null ,线程C第一次进入了compareAndSetTail

此时队列的头和node之前的顺序进行关联
在这里插入图片描述

B节点进入到等待席,修改前置节点的waitStatus=-1
acquire->acquireQueued->shouldParkAfterFailedAcquire
判断头节点是不是虚节点,如果是B线程再抢抢,如果抢不到则进入到shouldParkAfterFailedAcquire

此时New Node的waitStatus为0, 并不等于-1,我们进入compareAndSetWaitStatus
在这里插入图片描述
把前置节点(头节点)的waitStatus修改为-1

此时B线程因为因为自旋的原因;进入到了waitStates=-1(代表线程已经准备好了,就等资源释放了)的逻辑
waitStatus=-1 parkAndCheckInterrupt方法
acquire->acquireQueued->shouldParkAfterFailedAcquire && parkAndCheckInterrupt
在这里插入图片描述
我们可以看到如下的代码 , 从中我们得出结论AQS的线程阻塞考得是LockSupport.park方法

private final boolean parkAndCheckInterrupt() {
        LockSupport.park(this);
        return Thread.interrupted();
    }

C节点进入到等待席,修改前置节点[B节点]的waitStatus=-1
acquire->acquireQueued->shouldParkAfterFailedAcquire
然后进入LockSuppport , 然后其他的线程反复进入到这个循环

3、整个ReentrantLock的加锁过程，可以分为三个阶

1、尝试加锁;
2、加锁失败，线程入列;
3、线程入队列后，进入阻塞状态。