Java并发编程解析 | 解析AQS基础同步器的设计与实现

关健术语

Picture-Keyword

本文用到的一些关键词语以及常用术语，主要如下：

• 信号量(Semaphore): 是在多线程环境下使用的一种设施，是可以用来保证两个或多个关键代码段不被并发调用，也是作系统用来解决并发中的互斥和同步问题的一种方法。
• 信号量机制(Semaphores)： 用来解决同步/互斥的问题的，它是1965年,荷兰学者 Dijkstra提出了一种卓有成效的实现进程互斥与同步的方法。
• 管程(Monitor) : 一般是指管理共享变量以及对共享变量的操作过程，让它们支持并发的一种机制。

基本概述

在Java领域中，我们可以将锁大致分为基于Java语法层面(关键词)实现的锁和基于JDK层面实现的锁。

在Java领域中, 尤其是在并发编程领域，对于多线程并发执行一直有两大核心问题：同步和互斥。其中：

• 互斥(Mutual Exclusion)：一个公共资源同一时刻只能被一个进程或线程使用，多个进程或线程不能同时使用公共资源。即就是同一时刻只允许一个线程访问共享资源的问题。
• 同步(Synchronization)：两个或两个以上的进程或线程在运行过程中协同步调，按预定的先后次序运行。即就是线程之间如何通信、协作的问题。

针对对于这两大核心问题，利用管程是能够解决和实现的，因此可以说，管程是并发编程的万能钥匙。

虽然，Java在基于语法层面(synchronized 关键字)实现了对管程技术,但是从使用方式和性能上来说，内置锁(synchronized 关键字)的粒度相对过大，不支持超时和中断等问题。

为了弥补这些问题，从JDK层面对其“重复造轮子”，在JDK内部对其重新设计和定义，甚至实现了新的特性。

在Java领域中，从JDK源码分析来看，基于JDK层面实现的锁大致主要可以分为以下4种方式：

• 基于Lock接口实现的锁
• 基于ReadWriteLock接口实现的锁
• 基于AQS基础同步器实现的锁
• 基于自定义API操作实现的锁

从阅读源码不难发现，在Java SDK 并发包主要通过AbstractQueuedSynchronizer(AQS)实现多线程同步机制的封装与定义，而通过Lock 和 Condition 两个接口来实现管程，其中 Lock 用于解决互斥问题，Condition 用于解决同步问题。

一. 基本理论

在并发编程领域，有两大核心问题：一个是互斥，即同一时刻只允许一个线程访问共享资源；另一个是同步，即线程之间如何通信、协作。

在操作系统中，一般有如果I/O操作时，对于阻塞和非阻塞是从函数调用角度来说的，其中：

• 阻塞：如果读写操作没有就绪或者完成，则函数一直等待。
• 非阻塞： 函数立即调用，然后让应用程序轮询循环。

而同步和异步则是从“读写是主要是由谁完成”的角度来说的，其中：

• 同步： 读写操作主要交给应用程序完成
• 异步： 读写操作主要由操作系统完成，一般完成之后，回调函数和事件通知应用程序。

其中，信号量机制(Semaphores)是用来解决同步/互斥的问题的，但是信号量(Semaphore)的操作分散在各个进程或线程中，不方便进行管理，因每次需调用P/V(来自荷兰语 proberen和 verhogen)操作，还可能导致死锁或破坏互斥请求的问题。

由于PV操作对于解决进程互斥/同步编程复杂，因而在此基础上提出了与信号量等价的——“管程技术”。

其中，管程(Monitor)当中定义了共享数据结构只能被管程内部定义的函数所修改，所以如果我们想修改管程内部的共享数据结构的话，只能调用管程内部提供的函数来间接的修改这些数据结构。

一般来说，管程(Monitor)和信号量(Semaphore)是等价的，所谓等价指的是用管程能够实现信号量，也能用信号量实现管程。

在管程的发展历程上，先后出现过Hasen模型、Hoare模型和MESA模型等三种不同的管程模型，现在正在广泛使用的是MESA模型。

在MESA模型中，管程中引入了条件变量(Conditional Variable)的概念，而且每个条件变量都对应有一个等待队列(Wait Queue)。其中，条件变量和等待队列的作用是解决线程之间的同步问题。

而对于解决线程之间的互斥问题，将共享变量(Shared Variable)及其对共享变量的操作统一封装起来，一般主要是实现一个线程安全的阻塞队列(Blocking Queue)，将线程不安全的队列封装起来，对外提供线程安全的操作方法，例如入队操作(Enqueue)和出队操作(Dequeue)。

在Java领域中，对于Java语法层面实现的锁(synchronized 关键字)， 其实就是参考了 MESA 模型，并且对 MESA 模型进行了精简，一般在MESA 模型中，条件变量可以有多个，Java 语言内置的管程(synchronized)里只有一个条件变量。

这就意味着，被synchronized 关键字修饰的代码块或者直接标记静态方法以及实例方法，在编译期会自动生成相关加锁(lock)和解锁(unlock)的代码，即就是monitorenter和monitorexit指令。

对于synchronized 关键字来说，主要是在Java HotSpot(TM) VM 虚拟机通过Monitor(监视器)来实现monitorenter和monitorexit指令的。

同时，在Java HotSpot(TM) VM 虚拟机中，每个对象都会有一个监视器，监视器和对象一起创建、销毁。

监视器相当于一个用来监视这些线程进入的特殊房间，其义务是保证（同一时间）只有一个线程可以访问被保护的临界区代码块。

本质上，监视器是一种同步工具，也可以说是JVM对管程的同步机制的封装实现，主要特点是：

• 同步：监视器所保护的临界区代码是互斥地执行的。一个监视器是一个运行许可，任一线程进入临界区代码都需要获得这个许可，离开时把许可归还。
• 协作：监视器提供Signal机制，允许正持有许可的线程暂时放弃许可进入阻塞等待状态，等待其他线程发送Signal去唤醒；其他拥有许可的线程可以发送Signal，唤醒正在阻塞等待的线程，让它可以重新获得许可并启动执行。

在Hotspot虚拟机中，监视器是由C++类ObjectMonitor实现的，ObjectMonitor类定义在ObjectMonitor.hpp文件中，其中：

v7MaNT.png

• Owner： 指向的线程即为获得锁的线程
• Cxq：竞争队列（Contention Queue），所有请求锁的线程首先被放在这个竞争队列中
• EntryList：对象实体列表，表示Cxq中那些有资格成为候选资源的线程被移动到EntryList中。
• WaitSet：类似于等待队列，某个拥有ObjectMonitor的线程在调用Object.wait()方法之后将被阻塞，然后该线程将被放置在WaitSet链表中。

同时，管程与Java中面向对象原则(Object Oriented Principle)也是非常契合的，主要体现在 java.lang.Object类中wait()、notify()、notifyAll() 这三个方法，其中：

• wait()方法： 阻塞线程并且进入等待队列
• notify()方法：随机地通知等待队列中的一个线程
• notifyAll()方法： 通知等待队列中的所有线程

不难发现，在Java中synchronized 关键字及 java.lang.Object类中wait()、notify()、notifyAll() 这三个方法都是管程的组成部分。

由此可见，我们可以得到一个比较通用的并发同步工具基础模型，大致包含如下几个内容，其中：

• 条件变量(Conditional Variable)： 利用线程间共享的变量进行同步的一种工作机制
• 共享变量((Shared Variable))：一般指对象实体对象的成员变量和属性
• 阻塞队列(Blocking Queue)：共享变量(Shared Variable)及其对共享变量的操作统一封装
• 等待队列(Wait Queue)：每个条件变量都对应有一个等待队列(Wait Queue),内部需要实现入队操作(Enqueue)和出队操作(Dequeue)方法
• 变量状态描述机(Synchronization Status)：描述条件变量和共享变量之间状态变化，又可以称其为同步状态
• 工作模式(Operation Mode)： 线程资源具有排他性，因此定义独占模式和共享模式两种工作模式

综上所述，条件变量和等待队列的作用是解决线程之间的同步问题；共享变量与阻塞队列的作用是解决线程之间的互斥问题。

二.AQS基础同步器的设计与实现

在Java领域中,同步器是专门为多线程并发设计的同步机制，主要是多线程并发执行时线程之间通过某种共享状态来实现同步，只有当状态满足这种条件时线程才往下执行的一种同步机制。

对于多线程实现实现并发处理机制来说，一直以来，多线程都存在2个问题：

• 线程之间内存共享，需要通过加锁进行控制，但是加锁会导致性能下降，同时复杂的加锁机制也会增加编程编码难度
• 过多线程造成线程之间的上下文切换，导致效率低下

因此，在并发编程领域中，一直有一个很重要的设计原则： “ 不要通过内存共享来实现通信，而应该通过通信来实现内存共享。”

简单来说，就是尽可能通过消息通信，而不是内存共享来实现进程或者线程之间的同步。

其中，同步器是专门为多线程并发设计的同步机制，主要是多线程并发执行时线程之间通过某种共享状态来实现同步，只有当状态满足这种条件时线程才往下执行的一种同步机制。

由于在不同的应用场景中，对于同步器的需求也会有所不同，一般在我们自己去实现和设计一种并发工具的时候，都需会考虑以下几个问题：

• 是否支持响应中断？ 如果阻塞状态的线程能够响应中断信号，也就是说当我们给阻塞的线程发送中断信号的时候，能够唤醒它，那它就有机会释放曾经持有的锁。
• 是否支持超时？如果线程在一段时间之内没有获取到锁，不是进入阻塞状态，而是返回一个错误，那这个线程也有机会释放曾经持有的锁。
• 是否支持非阻塞地获取锁资源 ？ 如果尝试获取锁失败，并不进入阻塞状态，而是直接返回，那这个线程也有机会释放曾经持有的锁。

从阅读JDK源码不难发现，主要是采用设计模式中模板模式的原则，JDK将各种同步器中相同的部分抽象封装成了一个统一的基础同步器，然后基于基础同步器为模板通过继承的方式来实现不同的同步器。

也就是说，在实际开发过程中，除了直接使用JDK实现的同步器，还可以基于这个基础同步器我们也可以自己自定义实现符合我们业务需求的同步器。

在JDK源码中，同步器位于java.util.concurrent.locks包下，其基本定义是AbstractQueuedSynchronizer类，即就是我们常说的AQS同步器。

1. 设计思想

一个标准的AQS同步器主要有同步状态机制，等待队列，条件队列，独占模式，共享模式等五大核心要素组成。

JDK的JUC(java.util.concurrent.)包中提供了各种并发工具，但是大部分同步工具的实现基于AbstractQueuedSynchronizer类实现，其内部结构主要如下：

• 同步状态机制(Synchronization Status)：主要用于实现锁(Lock)机制，是指同步状态，其要求对于状态的更新必须原子性的
• 等待队列(Wait Queue)：主要用于存放等待线程获取到的锁资源，并且把线程维护到一个Node(节点)里面和维护一个非阻塞的CHL Node FIFO(先进先出)队列，主要是采用自旋锁+CAS操作来保证节点插入和移除的原子性操作。
• 条件队列(Condition Queue)：用于实现锁的条件机制，一般主要是指替换“等待-通知”工作机制，主要是通过ConditionObject对象实现Condition接口提供的方法实现。
• 独占模式(Exclusive Mode)：主要用于实现独占锁，主要是基于静态内部类Node的常量标志EXCLUSIVE来标识该节点是独占模式
• 共享模式(Shared Mode)：主要用于实现共享锁，主要是基于静态内部类Node的常量标志SHARED来标识该节点是共享模式

其中，对于AbstractQueuedSynchronizer类的实现原理，我们可以从如下几个方面来看：

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

    private static final long serialVersionUID = 7373984972572414691 L;


    protected AbstractQueuedSynchronizer() {}

    /**
     * 等待队列： head-头节点
     */
    private transient volatile Node head;

    /**
     * 等待队列： tail-尾节点
     */
    private transient volatile Node tail;

    /**
     * 同步状态：32位整数类型，更新同步状态(state)时必须保证其是原子性的
     */
    private volatile int state;

    /**
     * 自旋锁消耗超时时间阀值(threshold)： threshold < 1000ns时，表示竞争时选择自旋；threshold > 1000ns时，表示竞争时选择系统阻塞
     */
    static final long spinForTimeoutThreshold = 1000 L;

    /**
     * CAS原子性操作
     */
    private static final Unsafe unsafe = Unsafe.getUnsafe();

    /**
     * stateOffset
     */
    private static final long stateOffset;

    /**
     * headOffset
     */
    private static final long headOffset;

    /**
     * tailOffset
     */
    private static final long tailOffset;

    /**
     * waitStatusOffset
     */
    private static final long waitStatusOffset;

    /**
     * nextOffset
     */
    private static final long nextOffset;


    static {
        try {
            stateOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("state"));
            headOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("head"));
            tailOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("tail"));
            waitStatusOffset = unsafe.objectFieldOffset(Node.class.getDeclaredField("waitStatus"));
            nextOffset = unsafe.objectFieldOffset(Node.class.getDeclaredField("next"));

        } catch (Exception ex) {
            throw new Error(ex);
        }
    }
        
            private final boolean compareAndSetHead(Node update)  {
        return unsafe.compareAndSwapObject(this, headOffset, null, update);
    }
        
            private final boolean compareAndSetTail(Node expect, Node update) {
        return unsafe.compareAndSwapObject(this, tailOffset, expect, update);
    }
        
            private static final boolean compareAndSetWaitStatus(Node node,
                                                         int expect,
                                                         int update) {
        return unsafe.compareAndSwapInt(node, waitStatusOffset,
                                        expect, update);
    }
        
            private static final boolean compareAndSetNext(Node node,
                                                   Node expect,
                                                   Node update) {
        return unsafe.compareAndSwapObject(node, nextOffset, expect, update);
    }
        
            protected final boolean compareAndSetState(int expect, int update) {
        return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
    }

}

[1]. AbstractQueuedSynchronizer类的实现原理是继承了基于AbstractOwnableSynchronizer类的抽象类，其中主要对AQS同步器的通用特性和方法进行抽象封装定义，主要包括如下方法：

public abstract class AbstractOwnableSynchronizer
implements java.io.Serializable {


    private static final long serialVersionUID = 3737899427754241961 L;


    protected AbstractOwnableSynchronizer() {}

    /**
     *  同步器拥有者
     */
    private transient Thread exclusiveOwnerThread;

    /**
     * 设置同步器拥有者：把线程当作参数传入，指定某个线程为独享
     */
    protected final void setExclusiveOwnerThread(Thread thread) {
        exclusiveOwnerThread = thread;
    }

    /**
     * 获取同步器拥有者：获取指定的某个线程
     */
    protected final Thread getExclusiveOwnerThread() {
        return exclusiveOwnerThread;
    }
}

• setExclusiveOwnerThread(Thread thread)方法： 把某个线程作为参数传入，从而设置AQS同步器的所有者，即就是我们设置的某个线程
• getExclusiveOwnerThread()方法： 获取当前AQS同步器的所有者，即就是我们指定的某个线程

[2]. 对于同步状态(state)，其类型是32位整数类型，并且是被volatile修饰的，表示在更新同步状态(state)时必须保证其是原子性的。

[3]. 对于等待队列的结构，主要是在Node定义了head和tail变量，其中head表示头部节点，tail表示尾部节点

[4].对于等待队列的结构提到的Node类来说，主要内容如下：

  static final class Node {
      /** Marker to indicate a node is waiting in shared mode */
      static final Node SHARED = new Node();
            
      /** Marker to indicate a node is waiting in exclusive mode */
      static final Node EXCLUSIVE = null;

      /** waitStatus value to indicate thread has cancelled */
      static final int CANCELLED = 1;
            
      /** waitStatus value to indicate successor's thread needs unparking */
      static final int SIGNAL = -1;
            
      /** waitStatus value to indicate thread is waiting on condition */
      static final int CONDITION = -2;
            
      /**
       * waitStatus value to indicate the next acquireShared should
       * unconditionally propagate
       */
      static final int PROPAGATE = -3;

      /**
       * Status field, taking on only the values:
       *   SIGNAL:     The successor of this node is (or will soon be)
       *               blocked (via park), so the current node must
       *               unpark its successor when it releases or
       *               cancels. To avoid races, acquire methods must
       *               first indicate they need a signal,
       *               then retry the atomic acquire, and then,
       *               on failure, block.
       *   CANCELLED:  This node is cancelled due to timeout or interrupt.
       *               Nodes never leave this state. In particular,
       *               a thread with cancelled node never again blocks.
       *   CONDITION:  This node is currently on a condition queue.
       *               It will not be used as a sync queue node
       *               until transferred, at which time the status
       *               will be set to 0. (Use of this value here has
       *               nothing to do with the other uses of the
       *               field, but simplifies mechanics.)
       *   PROPAGATE:  A releaseShared should be propagated to other
       *               nodes. This is set (for head node only) in
       *               doReleaseShared to ensure propagation
       *               continues, even if other operations have
       *               since intervened.
       *   0:          None of the above
       *
       *
       * The field is initialized to 0 for normal sync nodes, and
       * CONDITION for condition nodes.  It is modified using CAS
       * (or when possible, unconditional volatile writes).
       */
      volatile int waitStatus;

      /**
       * Link to predecessor node that current node/thread relies on
       */
      volatile Node prev;

      /**
       * Link to the successor node that the current node/thread
       */
      volatile Node next;

      /**
       * The thread that enqueued this node.  Initialized on
       * construction and nulled out after use.
       */
      volatile Thread thread;

      /**
       * Link to next node waiting on condition, or the special
       */
      Node nextWaiter;

      /**
       * Returns true if node is waiting in shared mode.
       */
      final boolean isShared() {
          return nextWaiter == SHARED;
      }


      final Node predecessor() throws NullPointerException {
          Node p = prev;
          if (p == null)
              throw new NullPointerException();
          else
              return p;
      }

      Node() { // Used to establish initial head or SHARED marker
      }

      Node(Thread thread, Node mode) { // Used by addWaiter
          this.nextWaiter = mode;
          this.thread = thread;
      }

      Node(Thread thread, int waitStatus) { // Used by Condition
          this.waitStatus = waitStatus;
          this.thread = thread;
      }
  }

• 标记Node的工作模式常量标记：主要维护了SHARED和EXCLUSIVE等2个静态字面常量，其中 SHARED 用于标记Node中是共享模式，EXCLUSIVE:用于标记Node中是独享模式
• 标记等待状态的静态字面常量标记： 主要维护了0(表示无状态)，SIGNAL(-1,表示后续节点中的线程通过park进入等待，当前节点在释放和取消时，需要通过unpark解除后后续节点的等待)，CANCELLED(1,表示当前节点中的线程因为超时和中断被取消)，CONDITION(-2,表示当前节点在条件队列中)，PROPAGATE(-3,SHARED共享模式的头节点描述状态，表示无条件往下传播)等5个静态字面常量
• 维护了一个等待状态(waitStatus): 主要用于描述等待队列中节点的状态，其取值范围为0(waitStatus=0,表示无状态)，SIGNAL(waitStatus=-1,表示等待信号状态)，CANCELLED(waitStatus=1,表示取消状态)，CONDITION(waitStatus=-2,表示条件状态)，PROPAGATE(waitStatus=-3,表示SHARED共享模式状态)等5个静态字面常量，CAS操作时写入，默认值为0。
• 维护了Node的2个结构节点变量： 主要是prev和next，其中，prev表示前驱节点，next表示后续节点，表示构成双向向链表，构成了等待队列的数据结构
• 维护了一个状态工作模式标记： 主要是维护了一个nextWaiter，用于表示在等待队列中当前节点在是共享模式还是独享模式，而对于条件队列来说，用于组成单向链表结构
• 维护了一个线程对象变量： 主要用于记录当前节点中的线程thread

[5].对于自旋锁消耗超时时间阀值(spinForTimeoutThreshold),主要表示系统依据这个阀值来选择自旋方式还是系统阻塞。一般假设这个threshold，当 threshold < 1000ns时，表示竞争时选择自旋；否则，当threshold > 1000ns时，表示竞争时选择系统阻塞

[6].对于带有Offset 等变量对应各自的句柄，主要用于执行CAS操作。在JDK1.8版本之前，CAS操作主要通过Unsafe类来说实现；在JDK1.8版本之后，已经开始利用VarHandle来替代Unsafe类操作实现。

[7].对于CAS操作来说，主要提供了如下几个方法：

• compareAndSetState(int expect, int update)方法：CAS操作原子更新状态
• compareAndSetHead(Node update)方法：CAS操作原子更新头部节点
• compareAndSetTail(Node expect, Node update)方法：CAS操作原子更新尾部节点
• compareAndSetWaitStatus(Node node, int expect,int update)方法：CAS操作原子更新等待状态
• compareAndSetNext(Node node,Node expect,Node update)方法：CAS操作原子更新后续节点

[8].除此之外，还包括许多辅助的操作方法，具体可参考源码分析。

2. 基本实现

一个标准的AQS同步器最核心底层设计实现是一个非阻塞的CHL Node FIFO(先进先出)队列数据结构，通过采用自旋锁+CAS操作的方法来保证原子性操作。

总的来说，一个AQS基础同步器，底层的数据结构采用的是一个非阻塞的CHL Node FIFO(先进先出)队列数据结构，而实现的核心算法则是采用自旋锁+CAS操作的方法。

首先，对于非阻塞的CHL Node FIFO(先进先出)队列数据结构，一般来说，FIFO(First In First Out,先进先出)队列是一个有序列表，属于抽象型数据类型(Abstract Data Type,ADT),所有的插入和删除操作都发生在队首(Front)和队尾(Rear)两端，具有先进先出的特性。

    /**
     * 等待队列： head-头节点
     */
    private transient volatile Node head;

    /**
     * 等待队列： tail-尾节点
     */
    private transient volatile Node tail;
        
    /**
     * Inserts node into queue, initializing if necessary. See picture above.
     * @param node the node to insert
     * @return node's predecessor
     */
    private Node enq(final Node node) {
        for (;;) {
            Node t = tail;
            if (t == null) { // Must initialize
                if (compareAndSetHead(new Node()))
                    tail = head;
            } else {
                node.prev = t;
                if (compareAndSetTail(t, node)) {
                    t.next = node;
                    return t;
                }
            }
        }
    }

    /**
     * Creates and enqueues node for current thread and given mode.
     *
     * @param mode Node.EXCLUSIVE for exclusive, Node.SHARED for shared
     * @return the new node
     */
    private Node addWaiter(Node mode) {
        Node node = new Node(Thread.currentThread(), mode);
        // Try the fast path of enq; backup to full enq on failure
        Node pred = tail;
        if (pred != null) {
            node.prev = pred;
            if (compareAndSetTail(pred, node)) {
                pred.next = node;
                return node;
            }
        }
        enq(node);
        return node;
    }

在AQS同步器的源码中，主要是通过静态内部类Node来实现的这个非阻塞的CHL Node FIFO(先进先出)队列数据结构， 维护了两个变量head和tail，其中head对应队首(Front)，tail对应队尾(Rear)。同时，还定义了addWaiter(Node mode)方法来表示入队操作，其中有个enq(final Node node)方法，主要用于初始化队列中head和tail的设置。

其次，AQS同步器以CLH锁为基础，其中CLH锁是一种自旋锁，对于自旋锁的实现方式来看，主要可以分为普通自旋锁和自适应自旋锁，CLH锁和MCS锁等4种，其中：

• 普通自旋锁：多个线程不断自旋，不断尝试获取锁，其不具备公平性和由于要保证CPU和缓存以及主存之间的数据一致性，其开销较大。
• 自适应自旋锁：主要是为解决普通自旋锁的公平性问题，引入了一个排队机制，一般称为排他自旋锁，其具备公平性，但是没有解决保证CPU和缓存以及主存之间的数据一致性问题，其开销较大。
• CLH锁：通过一定手段将线程对于某一个共享变量的轮询竞争转化为一个线程队列，且队列中的线程各自轮询自己本地变量。
• MCS锁：主旨在于解决 CLH锁的问题，也是基于FIFO队列，与CLH锁不同是，只对本地变量自旋，前驱节点负责通知MCS锁中线程自适结束。

自旋锁是一种实现同步的方案，属于一种非阻塞锁，与常规锁主要的区别就在于获取锁失败之后的处理方式不同，主要体现在：

• 一般情况下，常规锁在获取锁失败之后，会将线程阻塞并适当时重新唤醒
• 而自旋锁则是使用自旋来替换阻塞操作，主要是线程会不断循环检查该锁是否被释放，一旦释放线程便会获取锁资源。

从本质上讲，自旋是一钟忙等待状态，会一直消耗CPU的执行时间。一般情况下，常规互斥锁适用于持有锁长时间的情况，自旋锁适合持有时间短的情况。

其中，对于CLH锁来说，其核心是为解决同步带来的花销问题，Craig，Landim，Hagersten三人发明了CLH锁，其中主要是：

• 构建一个FIFO(先进先出)队列，构建时主要通过移动尾部节点tail来实现队列的排队，每个想获得锁的线程都会创建一个新节点(next)并通过CAS操作原子操作将新节点赋予给tail，当前线程轮询前一个节点的状态。
• 执行完线程后，只需将当前线程对应节点状态设置为解锁即可，主要是判断当前节点是否为尾部节点，如果是直接设置尾部节点设置为空。由于下一个节点一直在轮询，所以可以获得锁。

CLH锁将众多线程长时间对资源的竞争，通过有序化这些线程将其转化为只需要对本地变量检测。唯一存在竞争的地方就是入队之前对尾部节点tail 的竞争，相对来说，当前线程对资源的竞争次数减少，这节省了CPU缓存同步的消耗，从而提升了系统性能。

但是同时也有一个问题，CLH锁虽然解决了大量线程同时操作同一个变量时带来的开销问题，如果前驱节点和当前节点在本地主存中不存在，则访问时间过长，也会引起性能问题。

为了让CLH锁更容易实现取消和超时的功能，AQS同步器在设计时进行了改造，主要体现在：节点的结构和节点等待机制。其中：

• 节点的结构： 主要引入了头节点和尾节点，分别指向队列头部和尾部，对于锁的相关操作都与其息息相关，并且每个节点都引入了前驱节点和后继节点。
• 节点等待机制： 主要在原来的自旋基础上增加了系统阻塞唤醒，主要体现在 自旋锁消耗超时时间阀值(threshold)： threshold < 1000ns时，表示竞争时选择自旋；threshold > 1000ns时，表示竞争时选择系统阻塞。

由此可见，主要是通过前驱节点和后继节点的引用连接起来形成一个链表队列，其中对于入队，检测节点，出队，判断超时，取消节点等操作主要如下：

• 入队(enqueue): 主要采用一个无限循环进行CAS操作，即就是使用自旋方式竞争直到成功。
• 检测节点(checkedPrev): 一般在入队完成后，主要是检测判断当前节点的前驱节点是否为头节点， 一般自旋方式是直接进入循环检测，而系统阻塞方式是当前线程先检测，其中如果是头节点并成功获取锁，则直接返回，当前线程不阻塞，否则对当前线程进行阻塞。
• 出队(dequeue):主要负责唤醒等待队列中的后继节点，并且按照条件往下传播有序执行
• 判断超时(checkedTimeout): 队列中等待锁的线程可能因为中断或者超时的情况，当总耗时大于等于自定义耗时就直接返回，即就是
• 取消节点(cancel): 主要是对于中断和超时而涉及到取消操作，而且这样的情况不再参与锁竞争，即就是一般通过调用compareAndSetNext(Node node, Node expect,Node update)来进行CAS操作。

最后，AQS同步器中使用了CAS操作，其中CAS(Compare And Swap,比较并交换)操作时一种乐观锁策略，主要涉及三个操作数据：内存值，预期值，新值，主要是指当且仅当预期值和内存值相等时才去修改内存值为新值。

一般来说，CAS操作的具体逻辑，主要可以分为三个步骤：

• 首先，检查某个内存值是否与该线程之前取到值一样。
• 其次，如果不一样，表示此内存值已经被别的线程修改，需要舍弃本次操作。
• 最后，如果时一样，表示期间没有线程更改过，则需要用新值执行更新内存值。

除此之外，需要注意的是CAS操作具有原子性，主要是由CPU硬件指令来保证，并且通过Java本地接口(Java Native Interface,JNI)调用本地硬件指令实现。

当然，CAS操作避免了悲观策略独占对象的 问题，同时提高了并发性能，但是也有以下三个问题：

• 乐观策略只能保证一个共享变量的原子操作，如果是多个变量，CAS便不如互斥锁，主要是CAS操作的局限所致。
• 长时间循环操作可能导致开销过大。
• 经典的ABA问题： 主要是检查某个内存值是否与该线程之前取到值一样，这个判断逻辑不严谨。解决ABA问题的核心在于，引入版本号，每次更新变量值更新版本号。

而在AQS同步器中，为了保证并发实现保证原子性，而且是硬件级别的原子性，一般是通过JNI(Java native interface,Java 本地接口)方式让Java代码调用C/C++本地代码。

需要注意的是，在Java领域中，对于CAS操作实现，主要有亮点问题：

• JDK1.8版本之前，CAS操作主要使用Unsafe类来执行底层操作，一般并发和线程操作时，主要用compareAndSwapObject，compareAndSwapInt，compareAndSwapLong等来实现CAS，而对于线程调度主要是park和unpark方法，其主要在sun.misc包下面。
• JDK1.8版本之后，JDK1.9的CAS操作主要使用VarHandle类，只是用VarHandle替代了一部分Unsafe类的操作，但是对于新版本中Unsafe，本质上Unsafe类会间接调用jdk.internal.misc包下面Unsafe类来实现。

版权声明：本文为博主原创文章，遵循相关版权协议，如若转载或者分享请附上原文出处链接和链接来源。