java基础之AQS

Java开发中，我们的应用程序经常会使用多线程提高程序的运行效率，多线程情况下访问线程共享变量可能会带来并发问题，此时就需要并发锁解决并发问题。Java提供了两种类型的并发控制机制：synchonrized关键字和AQS框架，二者各有优势，不过在加锁解锁场景比较灵活的情况下，我们往往会采用AQS框架来解决并发问题。本文会对Java中的AQS框架的结构和源码进行简单介绍。

AQS结构

AQS的全称是AbstractQueuedSynchronizer（抽象的队列式的同步器），AQS定义了一套多线程访问共享资源的同步器框架，许多同步类实现都依赖于它，如常用的ReentrantLock/Semaphore/CountDownLatch等。

如下图所示，AQS主要包含两部分内容：共享资源和等待队列。AQS底层已经对这两部分内容提供了很多方法。

1. 共享资源：共享资源是一个volatile的int类型变量。
2. 等待队列：等待队列是一个线程安全的队列，当线程拿不到锁时，会被park并放入队列。
3. 新线程：非公平情况下，新线程会先尝试直接获取资源，获取不到才进入队列。

核心思想

同步器的核心方法是acquire和release操作，其背后的思想也比较简洁明确。

acquire操作是这样的：

// acquire操作
while (当前同步器的状态不允许获取操作) {
    如果当前线程不在队列中，则将其插入队列
    阻塞当前线程
}
如果线程位于队列中，则将其移出队列

release操作是这样的：

更新同步器的状态
if (新的状态允许某个被阻塞的线程获取成功)
    解除队列中一个或多个线程的阻塞状态

从这两个操作中的思想中我们可以提取出三大关键操作：同步器的状态变更、线程阻塞和释放、插入和移出队列。所以为了实现这两个操作，需要协调三大关键操作引申出来的三个基本组件：

• 同步器状态的原子性管理；
• 线程阻塞与解除阻塞；
• 队列的管理；

同步器状态的原子性管理

AQS类使用单个int（32位）来保存同步状态，并暴露出getState、setState以及compareAndSet操作来读取和更新这个同步状态。其中属性state被声明为volatile，并且通过使用CAS指令来实现compareAndSetState，使得当且仅当同步状态拥有一个一致的期望值的时候，才会被原子地设置成新值，这样就达到了同步状态的原子性管理，确保了同步状态的原子性、可见性和有序性。

线程阻塞与解除阻塞

直到JSR166，阻塞线程和解除线程阻塞都是基于Java的内置管程，没有其它非基于Java内置管程的API可以用来达到阻塞线程和解除线程阻塞。唯一可以选择的是Thread.suspend和Thread.resume，但是它们都有无法解决的竞态问题，所以也没法用，目前该方法基本已被抛弃。具体不能用的原因可以官方给出的答复。

j.u.c.locks包提供了LockSupport类来解决这个问题。方法LockSupport.park阻塞当前线程直到有个LockSupport.unpark方法被调用。unpark的调用是没有被计数的，因此在一个park调用前多次调用unpark方法只会解除一个park操作。另外，它们作用于每个线程而不是每个同步器。一个线程在一个新的同步器上调用park操作可能会立即返回，因为在此之前可以有多余的unpark操作。但是，在缺少一个unpark操作时，下一次调用park就会阻塞。虽然可以显式地取消多余的unpark调用，但并不值得这样做。在需要的时候多次调用park会更高效。park方法同样支持可选的相对或绝对的超时设置，以及与JVM的Thread.interrupt结合 ，可通过中断来unpark一个线程。

队列的管理

整个框架的核心就是如何管理线程阻塞队列，该队列是严格的FIFO队列，因此不支持线程优先级的同步。同步队列的最佳选择是自身没有使用底层锁来构造的非阻塞数据结构，业界主要有两种选择，一种是MCS锁，另一种是CLH锁。其中CLH一般用于自旋，但是相比MCS，CLH更容易实现取消和超时，所以同步队列选择了CLH作为实现的基础。

CLH队列实际并不那么像队列，它的出队和入队与实际的业务使用场景密切相关。它是一个链表队列，通过AQS的两个字段head（头节点）和tail（尾节点）来存取，这两个字段是volatile类型，初始化的时候都指向了一个空节点。

条件队列

上一节的队列其实是AQS的同步队列，这一节的队列是条件队列，队列的管理除了有同步队列，还有条件队列。AQS只有一个同步队列，但是可以有多个条件队列。AQS框架提供了一个ConditionObject类