AQS中那些不得不说的理论知识

>>强大,10k+点赞的 SpringBoot 后台管理系统竟然出了详细教程!

点击关注公众号,利用碎片时间学习

来源:blog.csdn.net/weixin_43823391/

article/details/114259377

一、概念

AQS全称为AbstractQueuedSynchronizer(后面都以AQS简称),翻译过来叫做抽象队列同步器,是一个抽象类,其实也是一个单机多线程基础同步框架,这个框架通过对同步状态的原子性管理,实现对多线程的管理。子类应该定义一个非公开的内部类继承AQS,并实现其中方法。此部分介绍以独占模式为主。

子类根据需要需要重写下面的方法:

  • tryAcquire
  • tryRelease
  • tryReleaseShared
  • isHeldExclusively等方法,并确保是线程安全的。

二、AQS实现的基础

1、CAS:是compareandswap的简称,从字面上理解就是比较并更新。CAS操作是由Unsafe工具类来实现的,其操作具有原子性,我们一般通过CAS来改变状态。(状态被volatile修饰,因此具有可见性和有序性,所以CAS改变状态时是线程安全的)

2、队列:用来保存等待操作的资源,其数据结构一般为链表。当线程的请求在短时间内得不到满足时,线程会被包装成某种类型的数据结构放入队列中,当条件满足时则会拿出队列去重新获取锁。

3、状态:AQS及其子类的核心,AQS及其子类所有操作都是依据状态进进行的。状态一般会设置成volatile,保证其具有可见性,一定程度上具有有序性。它为 0 的时候代表没有线程占有锁,可以去争抢这个锁,用 CAS 将 state 设为 1,如果 CAS 成功,说明抢到了锁,这样其他线程就抢不到了。如果锁重入的话,state进行 +1 就可以,解锁就是减 1,直到 state 又变为 0,代表释放锁,所以 lock()unlock()必须要配对。共享模式的话,状态也是进行+1,解锁就是减一。

4、locksupport类的park和unpark方法。AQS队列的阻塞调用了Unsafe类中的park,park方法则借助于操作系统的实现来进行阻塞的,借此实现阻塞的两个特性:

  1. 不耗 CPU 等待;
  2. 线程安全。

三、AQS术语解释

1、队列

整个框架的关键就是如何管理被阻塞的线程的队列,该队列是严格的FIFO队列,因此,框架不支持基于优先级的同步。队列根据需要分为同步队列和条件队列。它们都是通过下面要介绍的AQS内部类Node来实现的。

1.1、 同步队列(阻塞队列)

同步队列是双向链表结构,既然能做双向链表,它可以用来保存等待的线程以及线程的状态等信息。头结点是一个哨兵节点(是一个附加的链表节点,该节点作为第一个节点,但是它其实并不存储任何东西,只是为了操作的方便而引入的)。

1.2、 条件队列(等待队列)

当使用Condition的时候,等待队列的概念就出来了。Condition的获取一般都要与一个锁Lock相关,一个锁上面可以生产多个Condition。即一个锁内的代码块可以新建多个Condition对象。

1.3 同步队列和条件队列的关系

Condition接口的主要实现类是AQS的内部类ConditionObject,每个Condition对象都包含一个等待队列。该队列是Condition对象实现等待/通知的关键。AQS中同步队列与等待队列的关系如下:

AQS中那些不得不说的理论知识

2、Node

AQS的一个内部类。用来包装竞争资源的线程,并将其组装成链表结构。

2.1 prev

同步队列的前驱节点,条件队列没有这个概念。

2.2 next

同步队列的后继节点,条件队列没有这个概念。

2.3 thread

竞争资源的线程。

2.4 nextWaiter

条件队列的下一个节点,同步队列没有这个概念。

2.5 waitStatus

队列中节点的等待状态。

  • static final int CANCELLED = 1; 此节点的线程被取消 独占模式 共享模式
  • static final int SIGNAL = -1; 此节点的后继节点线程被挂起,需要被唤醒 独占模式
  • static final int CONDITION = -2; 此节点的线程在等待信号,也表明当前节点不在同步队列中,而在条件队列中
  • static final int PROPAGATE = -3; 此节点下一个acquireShared应该无条件传播   共享模式

这四个属性就是waitStatus属性的具体状态,还有一个隐式的具体状态,即waitStatus初始化时为0。在独占模式下,我们只需要用到CANCELLED和SIGNAL,这里需要注意的是SIGNAL,它代表的不是自己线程的状态,而是它后继节点的状态,当一个节点的waitStatus被置为SIGNAL时,表明此节点的后继节点被挂起,当此节点释放锁或被取消放弃拿锁时,应该唤醒后继节点。而在共享模式时,我们会用到CANCELLED和PROPAGATE

3、ConditionObject

是AQS的内部类ConditionObject。

3.1 firstWaiter

条件队列的第一个节点。

3.2 lastWaiter

条件队列的最后一个节点。

3.2 await()

3.2.1 创建一个条件队列节点,把自己加入到条件队列中,必要的时候初始化条件队列;

3.2.2 因为调用await的线程都持有锁,所以接下来需要执行AQS的release方法释放当前线程持有的锁,即让出锁,让其他线程执行;

3.2.3 利用park方法将当前线程挂起,等待唤醒;

3.2.4 其他线程调用signal()方法唤醒该线程(该方法是隐式的,在代码中没有体现,因为是多线程执行,体现在signal())

  • 将节点从条件队列转移到等待队列
  • 调用unpark方法唤醒线程
  • 重新竞争锁。这个步骤也很关键,这里可以区分公平锁和非公平锁的业务。

3.3 signal()

3.3.1 将条件队列中的的节点(firstWaiter)转移到同步队列中

3.3.2 把刚转移到同步队列中的节点前驱的waitstatus改为SIGNAL(-1),用来唤醒后继节点。

4、队列同步器模式

4.1 共享模式

同一时间只有一个线程能拿到锁执行。

4.2 独占模式

同一时间有多个线程可以拿到锁协同工作。

4.3 公平锁

多个线程按照申请锁的顺序去获得锁,线程会直接进入队列去排队,永远都是队列的第一位才能得到锁。

4.4 非公平锁

多个线程去获取锁的时候,会直接去尝试获取,获取不到,再去进入等待队列,如果能获取到,就直接获取到锁。

4.5 可重入锁

广义上的可重入锁指的是可重复可递归调用的锁,在外层使用锁之后,在内层仍然可以使用,并且不发生死锁(前提得是同一个对象或者class),这样的锁就叫做可重入锁。ReentrantLock和synchronized都是可重入锁。

在ReentrantLock上的体现:

final boolean nonfairTryAcquire(int acquires) {  //这里我就跳过着讲解了,ReentrantLock模式使用的是非公平锁,这样能提高系统的响应性能
    final Thread current = Thread.currentThread();
    int c = getState();  //获取资源的状态,
    if (c == 0) {     //为0就是别人还没有获取到锁,这个时候当前线程就可以获取到锁
        if (compareAndSetState(0, acquires)) { //用cas的方式获取到锁
            setExclusiveOwnerThread(current);  //这个方法里面就只有这一句  exclusiveOwnerThread = thread; 设置当前线程是独占线程
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {   //重点来了,这个方法就是主要判断是不是可重入的,如果之前的判断资源的状态是被上锁了,就会执行到这里,如果判断是本线程
        int nextc = c + acquires;  //把资源的的请求次数加1
        if (nextc < 0// 当然也不是可以不限加的,如果超出的int的范围,抛出一个error的错误
            throw new Error("Maximum lock count exceeded");
        setState(nextc);  //设置资源状态
        return true;
    }
    return false;
}

总结:ReentrantLock可重入主要体现在current == getExclusiveOwnerThread()这个判断方法上面。如果是当前重入线程,资源状态添加请求数,注意释放的时候也是要释放这个多次的。

5、acquire(int arg) 线程竞争锁

竞争锁方法的路径tryAcquire()->addWaiter()->acquireQueued()->selfInterrupt(),其中tryAcquire()需要根据不同的业务场景,由不同实现类实现。由于是多线程模式,该方法使用了很多for (;;)来确保业务一定执行,具体可以参考源码。对应下面四个步骤:

5.1、竞争锁。竞争成功终止操作,竞争失败执行以下步骤;

5.2、将线程包装成独占式节点,并入队,放到队尾;

5.3、 当前线程加入等待队列后,会通过acquireQueued方法基于CAS自旋不断尝试获取资源,直至获取到资源竞争成功移除该节点并终止操作;

竞争失败修改前驱节点waitstatus=SIGNAL(-1),则会调用park阻塞线程。

5.4、 自我中断锁(用户线程第一次获取锁失败之后,进入CLH队列,此时会中断该线程)。

6、release(int arg) 线程释放锁

释放锁的路径tryRelease()->unparkSuccessor(),其中tryAcquire()需要根据不同的业务场景,由不同实现类实现,

6.1 由于模板模式,不同的子类实现不同,一般是修改锁状态;

6.2 获取等待队列的头节点,调用unpark()唤醒后继节点的线程。

7、为什么唤醒后继节点中,是从后向前遍历?

因为cancelAcquire方法的处理过程中只设置了next的变化,没有设置prev的变化,在最后有这样一行代码:node.next = node。并发情况下从前向后遍历的话,可能就死循环了,所以这时只有prev是稳定的。

唤醒后继节点的线程后,被唤醒的线程在parkAndCheckInterrupt方法,返回线程在park过程中是否被用户中断过,然后到acquireQueued方法中,如果该节点的前驱节点是头节点,则尝试获取资源,成功获取资源后,将是否被中断标识返回acquire方法,如果被中断过,那此时中断。

如果被唤醒的线程所在节点的前继节点不是头结点,经过shouldParkAfterFailedAcquire的调整(清除无效(waitState=CANCELLED)的节点),也会移动到等待队列的前面,直到其前继节点为头结点。

,如果该节点的前驱节点是头节点,则尝试获取资源,成功获取资源后,将是否被中断标识返回acquire方法,如果被中断过,那此时中断。如果被唤醒的线程所在节点的前继节点不是头结点,经过shouldParkAfterFailedAcquire的调整(清除无效(waitState=CANCELLED)的节点),也会移动到等待队列的前面,直到其前继节点为头结点。

推荐:

主流Java进阶技术(学习资料分享)

AQS中那些不得不说的理论知识
PS:因为公众号平台更改了推送规则,如果不想错过内容,记得读完点一下“在看”,加个“星标”,这样每次新文章推送才会第一时间出现在你的订阅列表里。“在看”支持我们吧!

原文始发于微信公众号(Java笔记虾):AQS中那些不得不说的理论知识