AbstractQueueSychronizer-AQS框架实现原理和应用

最新推荐文章于 2022-12-26 10:03:50 发布

小诚信驿站

最新推荐文章于 2022-12-26 10:03:50 发布

阅读量367

点赞数

CC 4.0 BY-SA版权

分类专栏：聊聊并发编程【Java并发专栏】

本文链接：https://blog.csdn.net/wolf_love666/article/details/119177084

本文介绍了AQS（AbstractQueueSychronizer）的背景、收益和设计理念，它是Java并发包中锁的底层实现。AQS基于CLH锁的改进，提供独占和共享两种模式，实现如ReentrantLock、CountDownLatch等同步器。通过state字段实现CAS操作，支持ConditionObject条件队列。文章还探讨了ReentrantLock、CountDownLatch、ReentrantReadWriteLock的实现原理和使用场景。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

文章目录

一、背景
二、收益
三、名词介绍
四、架构设计
五、模块设计
六、案例实现
- 6.1、不可重入的互斥锁类，独占模式
- 6.2、共享模式类似CountDownLatch
七、源码解读（TODO，待完善）

一、背景

为什么会有AQS框架，基于锁的缘起时分为内置锁sycnhronized但是由于当时还没有进行锁升级，锁粗化，锁优化（JDK1.6版本+）,所以内置锁属于重量级锁，性能比较低，所以出现了多种实现锁的方式。AQS就是基于自旋锁的一种思想演化而来。AQS是基于Doug Lea大神在JDK1.5版本实现出来的。

二、收益

提升使用锁的性能，减少资源损耗。

三、名词介绍

如果不知道CLH锁建议先看下我的之前文章，自旋锁的演进->CLH锁
AbstractQueueSychronizer-AQS是抽象类，内置自旋锁实现的同步队列，封装入队和出队的操作。提供独占、共享、中断等特性的方法。
地位：它是实现同步器的基础组件，并发包中锁的底层就是使用AQS实现的。分为2种模式，独占模式和共享模式。如果将该类用作同步器的基础，需要重新定义state方法和compareAndSetState。
ConditionObject.isHeldExclusively作为判断是否独占。

四、架构设计

4.1、CLH锁

4.2、CLH锁升级-AQS实现

基于CLH锁的改进点为增加后驱指针，形成FIFO先进先出列表。可以实现类似MCN锁的迭代遍历阻塞列表
在这里插入图片描述

4.3、流程设计（举例ReentrantLock公平锁）

在这里插入图片描述原图链接

五、模块设计

5.1、state实现CAS锁

对于大多数依赖于表示状态的单个原子{@code int}值。子类必须定义更改此状态的受保护方法，以及

定义该状态对于获取的对象意味着什么或者被释放。给定这些，这个类中的其他方法排除所有排队和阻塞机制。子类可以维护

其他状态字段，但只有原子更新的{@code int}使用{@link#getState}、{@link方法操作的值对#setState}

和{@link#compareAndSetState}进行跟踪到同步。

5.2、独占/共享模式实现

基于架构图中可知Node节点两个属性shared、exclusive。分别代表独占和共享模式。通常子类实现一种方式，但是也可以两者同时实现，比如ReadWriteLock。

5.2.1、嵌套ConditionObject类，用作Condition实现

这个{@link ConditionObject}的行为当然取决于其同步器实现的语义，此类提供检查、仪器和监视用于内部队列的方法，以及用于条件对象。这些可以根据需要导出到类中使用{@code AbstractQueuedSynchronizer}作为同步机制

这个类的序列化只存储底层原子整数保持状态，因此反序列化的对象为空线程队列。需要序列化的典型子类将定义一个{@code readObject}方法，将其还原为已知的反序列化时的初始状态

isHeldExclustively()判断线程是否正在独占资源

5.2.2、独占锁实现

tryAcquire()获取
tryRelease()释放

5.2.3、共享锁实现

tryAcquireShared()获取共享锁

共享方式。尝试获取资源。负数表示失败;0 表示成功，但没有剩余
可用资源;正数表示成功，且有剩余资源。

tryReleaseShared()释放共享锁

共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回
true，否则返回 false。

5.3、基于AQS实现同步器

需要重新定义使用{@link#getState}、{@link的同步状态#setState}和/或{@link#compareAndSetState}

5.3.1、ReentrantLock

以 ReentrantLock 为例，state 初始化为 0，表示未锁定状态。A 线程
lock()时，会调用 tryAcquire()独占该锁并将 state+1。此后，其他线程再 tryAcquire()时就会失
败，直到 A 线程 unlock()到 state=0(即释放锁)为止，其它线程才有机会获取该锁。当然，释放
锁之前，A 线程自己是可以重复获取此锁的(state 会累加)，这就是可重入的概念。但要注意，
获取多少次就要释放多么次，这样才能保证 state 是能回到零态的。

5.3.2、CountDownLatch

以 CountDownLatch 以例，任务分为 N 个子线程去执行，state 也初始化为 N(注意 N 要与
线程个数一致)。这 N 个子线程是并行执行的，每个子线程执行完后 countDown()一次，state
会 CAS 减 1。等到所有子线程都执行完后(即 state=0)，会 unpark()主调用线程，然后主调用线程
就会从 await()函数返回，继续后余动作。
CountDownLatch 类位于 java.util.concurrent 包下，利用它可以实现类似计数器的功能。比如有
一个任务 A，它要等待其他 4 个任务执行完毕之后才能执行，此时就可以利用 CountDownLatch
来实现这种功能了。

final CountDownLatch latch = new CountDownLatch(2);
	new Thread(){
   
   
		public void run() {
   
   
		 System.out.println("子线程"+Thread.currentThread().getName()+"正在执行");
		Thread.sleep(3000); 
		System.out.println("子线程"+Thread.currentThread().getName()+"执行完毕"); 
		latch.countDown();
	};}.start();
	new Thread(){
   
    
		public void run() {
   
   
			System.out.println("子线程"+Thread.currentThread().getName()+"正在执行"); 
			Thread.sleep(3000); 
		    System.out.println("子线程"+Thread.currentThread().getName()+"执行完毕"); 
		    latch.countDown();
	};}.start();
	System.out.println("等待 2 个子线程执行完毕..."); 
	latch.await();
	System.out.println("2 个子线程已经执行完毕"); 
	System.out.println("继续执行主线程");
}

5.3.2.1、CountDownLatch与join方法的区别

一个区别是调用一个子线程的join()方法后，该线程会一直被阻塞直到子线程运行完毕，而CountDownLach则使用计数器来允许子线程运行完毕或者在运行中递减技术。也就是CountDownLach可以在子线程运行的任何时候让await方法返回而不一定必须等到线程结束。另外，使用线程池来管理线程时候一般都是直接添加Runnable到线程池，这时候就没有办法再调用线程join方法，就是说countDownLatch相比join方法让我们对线程同步有更灵活的控制。

5.3.2.2、CountDownLatch优缺点

首先在初始化CountDownLatch时候设置状态值（计数器值），当多个线程调用counDown方法时候实际是原子性递减AQS的状态值。当线程调用await方法后当前线程会被放入AQS的阻塞队列等待计数器为0再返回，其他线程调用countDown方法让计数器值递减1，当计数器值变为0时候，当前线程还要调用AQS的doReleaseShared方法来激活由于调用await方法而被阻塞的线程。

5.3.3、ReentrantReadWriteLock

实现独占和共享两种方式
一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现 tryAcquire-
tryRelease、tryAcquireShared-tryReleaseShared 中的一种即可。但 AQS 也支持自定义同步器
同时实现独占和共享两种方式，如 ReentrantReadWriteLock。

5.3.3.1、实现原理（写少读多）

满足写少读多的场景：
读写锁内部维护了ReadLock和一个WriteLock，它们依赖Sync实现具体功能。而Sync继承自AQS，并且也提供了公平和非公平的实现。因为AQS只维护了一个state状态，而ReentrantReadWriteLock则需要维护读状态和写状态。一个state值如何维护2种状态，则可以使用高16位表示读状态，也就是获取到读锁的次数，低16位表示获取到写锁的线程可重入次数

5.3.3.2、代码实现

  /*
         * Read vs write count extraction constants and functions.
         * Lock state is logically divided into two unsigned shorts:
         * The lower one representing the exclusive (writer) lock hold count,
         * and the upper the shared (reader) hold count.
         */

        static final int SHARED_SHIFT   = 16;
        共享锁（读锁）状态单位值65536
        static final int SHARED_UNIT    = (1 << SHARED_SHIFT);
        共享锁线程数最大个数65535
        static final int MAX_COUNT      = (1 << SHARED_SHIFT) - 1;
        排他锁（写锁）掩码，二进制，15个1
        static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;

        返回读锁线程数
        static int sharedCount(int c)    { return c >>> SHARED_SHIFT; }
        返回写锁可重入个数
        static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

5.3.4、循环屏障CyclicBarrier(解决CountDownLatch缺点)

如果希望循环使用，推荐使用ReentrantLock实现的CyclicBarrier。
循环屏障详细说明

5.3.5、信号量Semphore

5.3.5.1、实现原理

Semphore与CountDownLach有些不同，它内部的计数器是递增的，并且在一开始初始化Semaphore时候可以指定一个初始值，但是并不需要知道需要同步的线程个数，而是在需要同步的地方调用acquire方法时候指定需要同步的线程个数。

实现原理：定义了资源总量state=permits，当state>0时候获得锁，并将state减1，当state=0时候只能等待其他线程释放锁，当释放锁时候state加1，其他等待线程又能获得这个锁。当Semphore的permits定义为1就是互斥锁，当permits>1时候就是共享锁
可以看下代码实例如下：

5.3.5.2、实现代码

package test;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Semaphore;

/**
 * @author xcxyz
 * @create 2019-04-19 7:05
 **/
public class Demo {
   
   
    //创建一个信号量,当大于0时候获取锁，获取锁state-1，当大于1可重入锁，等于1互斥锁
    private  static Semaphore semaphore = new Semaphore(0);

    //开启线程测试
    public static void main(String args[]){
   
   
        ExecutorService executorService = Executors.newFixedThreadPool(2);
        ///添加线程A到线程池
        executorService.submit(new Runnable() {
   
   
            @Override
            public void run() {
   
   
                try{
   
   
                    System.out.println(Thread.currentThread()+"over");
                    semaphore.release();
                }catch (Exception e){
   
   
                    e.printStackTrace();
                }
            }
        });
        executorService.submit(new Runnable() {
   
   
            @Override
            public void run() {
   
   
                try{
   
   
                    System.out.println(Thread.currentThread()+"over");
                    semaphore.release();
                }catch (Exception e){
   
   
                    e.printStackTrace();
                }
            }
        });
        try {
   
   

            semaphore.acquire(2);
            System.out.println("all over");
            //关闭线程池
            executorService.shutdown();
        }catch (Exception e){
   
   
            e.printStackTrace();
        }
    }
}

在这里插入图片描述

构造函数入参为0，说明当前信号量计数器值为0，然后main函数向线程池添加两个任务，在每个线程内部调用信号量的release方法，这相当于计数器值递增1.最后acquire方法，相当于执行这里的线程会一直阻塞，直到信号量变为2，线程都执行完毕，才可以返回。而这一点也在某种程度上可以先执行其他线程，然后聚合线程和循环屏障类似。

六、案例实现

6.1、不可重入的互斥锁类，独占模式

 * class Mutex implements Lock, java.io.Serializable {
   
   
 *
 *   // 我们的助手帮助类-抽象队列同步器实现的同步类
 *   private static class Sync extends AbstractQueuedSynchronizer {
   
   
 *     // 记录是否独占状态，如果==1为独占
 *     protected boolean isHeldExclusively() {
   
   
 *       return getState() == 1;
 *     }
 *
 *     // 如果state=0获取这个锁
 *     public boolean tryAcquire(int acquires) {
   
   
 *       assert acquires == 1; // 然而没使用
 *       if (compareAndSetState(0, 1)) {
   
   
 *         setExclusiveOwnerThread(Thread.currentThread());
 *         return true;
 *       }
 *       return false;
 *     }
 *
 *     // 通过设置state=0释放这个锁
 *     protected boolean tryRelease(int releases) {
   
   
 *       assert releases == 1; // Otherwise unused
 *       if (getState() == 0) throw new IllegalMonitorStateException();
 *       setExclusiveOwnerThread(null);
 *       setState(0);
 *       return true;
 *     }
 *
 *     // 提供一个锁的条件
 *     Condition newCondition() {
   
    return new ConditionObject(); }
 *
 *     // 正确的反序列化
 *     private void readObject(ObjectInputStream s)
 *         throws IOException, ClassNotFoundException {
   
   
 *       s.defaultReadObject();
 *       setState(0); // 重置未锁状态=0
 *     }
 *   }
 *
 *   // sync完成了所有操作，如下列表
 *   private final Sync sync = new Sync();
 *
 *   public void lock()                {
   
    sync.acquire(1); }
 *   public boolean tryLock()          {
   
    return sync.tryAcquire(1); }
 *   public void unlock()              {
   
    sync.release(1); }
 *   public Condition newCondition()   {
   
    return sync.newCondition(); }
 *   public boolean isLocked()         {
   
    return sync.isHeldExclusively(); }
 *   public boolean hasQueuedThreads() {
   
    return sync.hasQueuedThreads(); }
 *   public void lockInterruptibly() throws InterruptedException {
   
   
 *     sync.acquireInterruptibly(1);
 *   }
 *   public boolean tryLock(long timeout, TimeUnit unit)
 *       throws InterruptedException {
   
   
 *     return sync.tryAcquireNanos(1, unit.toNanos(timeout));
 *   }
 * }}

6.2、共享模式类似CountDownLatch

class BooleanLatch {
   
   
 *    
 *   private static class Sync extends AbstractQueuedSynchronizer {
   
   
       //是否发生信号
 *     boolean isSignalled() {
   
    return getState() != 0; }
 *     //尝试获取共享锁
 *     protected int tryAcquireShared(int ignore) {
   
   
 *       return isSignalled() ? 1 : -1;
 *     }
 *     //尝试释放共享锁
 *     protected boolean tryReleaseShared(int ignore) {
   
   
 *       setState(1);
 *       return true;
 *     }
 *   }
 *   //sync完成所有操作，如下列表
 *   private final Sync sync = new Sync();
 *   public boolean isSignalled() {
   
    return sync.isSignalled(); }
 *   public void signal()         {
   
    sync.releaseShared(1); }
 *   public void await() throws InterruptedException {
   
   
 *     sync.acquireSharedInterruptibly(1);
 *   }
 * }}

七、源码解读（TODO，待完善）


public abstract class AbstractQueuedSynchronizer
    extends AbstractOwnableSynchronizer
    implements java.io.Serializable {
   
   

    private static final long serialVersionUID = 7373984972572414691L;

    /**
     * 构造一个AQS实例，并初始化state=0
     */
    protected AbstractQueuedSynchronizer() {
   
    }

    /**
     * 等待队列Node类
     *
     * <p>等待队列是 a "CLH" (Craig, Landin, and
     * Hagersten) 锁队列的变体. CLH locks 常被用于自旋锁. 
     * 我们通过使用其作为同步器来保证在节点前的一个线程信息的一些控制权. status字段用来保证记录线程的轨迹.
       原先任务发布的时候，节点被通知. 队列中的每个节点（不是服务）作为一个特定通知风格的监控并持有单个等待线程。
       虽然这个status属性不能控制是否线程被授权锁等，如果这个线程是第一次进入队列可能会尝试获取锁，
       但是虽然是作为第一个并不能保证成功，仅仅是给予竞争的权力。因此当前发布的竞争的线程可能需要重新等待
  
     * <p>给队列添加一个 CLH 锁, 自动会添加到队列尾部 。对于双端队列，仅仅需要添加头部属性即可.
     * <pre>
     *      +------+  prev +-----+       +-----+
     * head |      | <---- |     | <---- |     |  tail
     *      +------+       +-----+       +-----+
     * </pre>
     *
     * <p> 插入到CLH队列要求仅仅是单个原子操作在尾部，因此有一个简单的分工边界从未加入队列到队列。
     相似的，正在减少队列仅仅涉及更新头部。然后对于节点决定谁是成功的，需要花费多点的工作。
     由于超时或者中断，部分情况下可能被取消
     *
     * <p> "prev" 链接 (未被使用在 CLH 锁), 主要需要处理取消.如果一个节点被取消了，他的成功者正常来说被重现链接到非被取消的
       原有事物. 针对于自旋锁的解释, 可以参考论文 papers by Scott and Scherer at
     * http://www.cs.rochester.edu/u/scott/synchronization/
     *
     * <p>使用 "next" 链接实现阻塞方法.
     * 对于每个节点的线程ID保存在他自己的节点。因此一个原先任务信号唤醒下一个节点通过游动next链接来决定它是哪个线程
      成功的要避免与后面进入队列的竞争. 通过从自动检查后必要的更新尾部，当一个成功者出现null，
      这个东西被解决。或者换句不同说法，next链接是一种优化以至于我们不经常需要向后扫描。
     *
     * <p>取消引入一些保守原则.  因为我们必须对于其他节点取消进行调查，我们能错失关注是否一个被取消的节点是在我们前面或者后面
       总是被未停止成功。需要平衡哪个是先前的事物哪个是之后的事物
  
     *
     * <p>CLH队列需要一个伪头部节点来开始，但是我们不能再结构上创建他们，因为他将被浪费掉如果从来没有