多线程(十五)AQS介绍

前言

  1995年sun公司发布了第一个Java语言版本，可以说从jdk1.1到jdk1.4期间java的使用主要是在移动应用和中小型企业应用中，在此类领域中基本不用设计大型并发场景，当然也没有大型互联网公司使用java，因为担心它本身的性能。在互联网及服务器硬件迅猛的发展下，sun公司更加注重企业级应用方面，毫无疑问高并发是一个重要的主题，于是在J2SE5.0（jdk1.5）代号为老虎的版本中增加了更加强大的并发相关的操作包——java.util.concurrent。此后java在高并发中表现优异，很多大型互联网公司都使用java作为主要开发语言，例如阿里巴巴、ebay等，这些公司系统的访问绝对是属于世界级的大型并发场景，反映了java在大型并发场景是可行的。Jdk的并发包提供了各种锁及同步机制，其实现的核心类是AbstractQueuedSynchronizer，我们简称为AQS框架，它为不同场景提供了实现锁及同步机制的基本框架，为同步状态的原子性管理、线程的阻塞、线程的解除阻塞及排队管理提供了一种通用的机制。

  Jdk的并发包（juc）的作者是Doug Lea，但其中思想却是结合了多位大师的智慧，如果你想深入理解juc的相关理论可以参考Doug Lea写的《The_java.util.concurrent_Synchronizer_Framework》论文。从这里可以找到AQS的理论基础，包括框架的基本原理、需求、设计、实现思路、用法及性能，由于这些方面篇幅较大，本文不打算涉及所有方面，主要将针对AQS类的结构及相关操作进行分析。

  ASQ将线程封装到一个Node里面，并维护一个CHL Node FIFO队列，它是一个非阻塞的FIFO队列，也就是说在并发条件下往此队列做插入或移除操作不会阻塞，是通过自旋锁和CAS保证节点插入和移除的原子性，实现无锁快速插入。

  其实AbstractQueuedSynchronizer主要就是维护了一个state属性、一个FIFO队列和线程的阻塞与解除阻塞操作。state表示同步状态，它的类型为32位整型，对state的更新必须要保证原子性。这里的队列是一个双向链表，每个节点里面都有一个prev和next，它们分别是前一个节点和后一个节点的引用。需要注意的是此双向链表除了链头其他每个节点内部都包含一个线程，而链头可以理解为一个空节点。

对于队列的结构我们需要深入理解下，下图展示的是组成双向链表其中一个节点的结构,该节点包含五个主要元素，表示的意思如下表:

            

属性	含义
Node prev	前驱节点，指向前一个节点
Node next	后续节点，指向后一个节点
Node nextWaiter	用于存储condition队列的后续节点
Thread thread	入队列时的当前线程
int waitStatus	有五种状态： ① SIGNAL,值为-1，表示当前节点的后续节点中的线程通过park被阻塞了，当前节点在释放或取消时要通过unpark解除它的阻塞。 ② CANCELLED，值为1，表示当前节点的线程因为超时或中断被取消了。 ③ CONDITION，值为-2，表示当前节点在condition队列中。 ④ PROPAGATE，值为-3，共享模式的头结点可能处于此状态，表示无条件往下传播，引入此状态是为了优化锁竞争，使队列中线程有序地一个一个唤醒。 ⑤ 0，除了以上四种状态的第五种状态，一般是节点初始状态。

---

  前驱节点prev的引入主要是为了完成超时及取消语义，前驱节点取消后只需向前找到一个未取消的前驱节点即可；后续节点的引入主要是为了优化后续节点的查找，避免每次从尾部向前查找；nextWaiter用于表示condition队列的后续节点，此时prev和next属性将不再使用，而且节点状态处于Node.CONDITION; waitStatus表示的是后续节点状态，这是因为AQS中使用CLH队列实现线程的结构管理，而CLH结构正是用前一节点某一属性表示当前节点的状态，这样更容易实现取消和超时功能。

---

分析

  在前面博客中，LZ讲到了ReentrantLock、ReentrantReadWriteLock、Semaphore、CountDownLatch，他们都有各自获取锁的方法，同时相对于Java的内置锁，他们具有明显的优势：花最小的空间开销创建锁、最少的时间开销获得锁、使用更加方便灵活。

  参考Java的内置锁，对于JUC同步器而言，他应该具备两个最基本的功能：获取锁，释放锁。其中获取锁应该是先判断当前状态是否可以获取，如果不可以获取则处于阻塞状态，释放应该是释放后修改状态，让其他线程能够得到该锁（唤醒其他线程），如下：

lock:  
        while(state){                //  
            getLock();            //获取锁  
            return currentThread;        //返回当前线程  
        }  

        release:  
        updateState();                //修改状态      
        notify other thread;            //唤醒其他线程  

  我们知道，在JUC中，各个同步器获取锁和释放锁的方法都不相同，比如：lock.lock()、Semaphore.acquire()、 CountDownLatch.await()等等，假如他们都各自实现各自的方法，那么这个JUC框架顶多只能算一个中下等的框架设计了。这是AQS腾空出世，AQS作为一个核心的处理框架，他提供了大量的同步操作，同时用户还可以在此类的基础上进行自定义，实现自己的同步器。其主要框架如下：

  从上图可以看出AQS是JUC同步器的基石。下面就AQS涉及的技术原理简单阐述下，以后会对其做详细的说明。

---

1、状态位state

AQS用的是一个32位的整型来表示同步状态的，它是用volatile修饰的：

private volatile int state;  

在互斥锁中它表示着线程是否已经获取了锁，0未获取，1已经获取了，大于1表示重入数。同时AQS提供了getState()、setState()、compareAndSetState()方法来获取和修改该值：

protected final int getState() {  
            return state;  
        }  

        protected final void setState(int newState) {  
            state = newState;  
        }  

        protected final boolean compareAndSetState(int expect, int update) {  
            return unsafe.compareAndSwapInt(this, stateOffset, expect, update);  
        }  

这些方法需要java.util.concurrent.atomic包的支持，采用CAS操作，保证其原则性和可见性。

---

2、CLH同步队列

  在前面就提到过AQS内部维护着一个FIFO的CLH队列，所以AQS并不支持基于优先级的同步策略。至于为何要选择CLH队列，主要在于CLH锁相对于MSC锁，他更加容易处理cancel和timeout，同时他具备进出队列快、无所、畅通无阻、检查是否有线程在等待也非常容易（head != tail,头尾指针不同）。当然相对于原始的CLH队列锁，ASQ采用的是一种变种的CLH队列锁：

1、原始CLH使用的locked自旋，而AQS的CLH则是在每个node里面使用一个状态字段来控制阻塞，而不是自旋。

2、为了可以处理timeout和cancel操作，每个node维护一个指向前驱的指针。如果一个node的前驱被cancel，这个node可以前向移动使用前驱的状态字段。

3、head结点使用的是傀儡结点。

---

3、共享锁、互斥锁

  在AQS维护的CLH队列锁中，每个节点（Node）代表着一个需要获取锁的线程。该Node中有两个常量SHARE、EXCLUSIVE。其中SHARE代表着共享模式，EXCLUSIVE代表着独占模式。

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;  
            /////////  

        }  

  其中共享模式是允许多个线程可以获取同一个锁，而独占模式则一个锁只能被一个线程持有，其他线程必须要等待。

  比如：ReentrantReadWriteLock，我们知道ReentrantReadWriteLock的中也有一个叫Sync的内部类继承了AQS，而AQS的队列可以同时存放共享锁和独占锁，对于ReentrantReadWriteLock来说分别代表读锁和写锁，当队列中的头节点为读锁时，代表读操作可以执行，而写操作不能执行，因此请求写操作的线程会被挂起，当读操作依次推出后，写锁成为头节点，请求写操作的线程被唤醒，可以执行写操作，而此时的读请求将被封装成Node放入AQS的队列中。如此往复，实现读写锁的读写交替进行。

---

4、阻塞、唤醒

  我们知道在使用Java内置锁时，可以使用wait、notify方法来阻塞、唤醒线程，但是AQS并没有采用该模式，而是通过LockSupport.park() 和 LockSupport.unpark() 的本地方法来实现线程的阻塞和唤醒。

参考文章：
深度解析Java8 – AbstractQueuedSynchronizer的实现分析（上）;
深度解析Java8 – AbstractQueuedSynchronizer的实现分析（下）;
Java并发框架——什么是AQS框架;
多线程(扩展篇)Unsafe类;

原文地址： Java并发框架——什么是AQS框架;
【Java并发编程实战】—–“J.U.C”：AQS分析（一）