Java 并发编程AQS基本介绍

what-什么是AQS?

AQS是AbstractQueuedSynchronizer的简称。直译就是“抽象队列同步器”。
它定义了一套多线程访问共享资源的同步框架，需要同步类实现都依赖于它，如ReentrantLock、ReentrantReadWriteLock、StampedLock、CountDownLath、CyclicBarrier等

why-为什么需要AQS？

如果不用AQS，也能实现同步器。例如可以用重入锁实现信号量或信号量实现重入锁。但是这样做起来相互调用，相互为底层，会带来复杂性、开销及不灵活。
如果同样的效果但能够比其它形式更加的简洁，那么开发者就会统一用一个底层的同步框架来构建同步器，因此AQS就诞生了。
其中在j.u.c包中大部分的类都是基于AQS实现的，用户也可以自定义自己的同步器，基于AQS这个基础组件可以构建j.u.c的各种工具类

how-AQS的设计和结构

具体的结构如图所示：

它维护了一个volatile int state（代表共享资源）
一个FIFO的线程等待队列（多线程资源争用被阻塞的时候会进入此队列）
CLH队列是一个锁模型，是一个虚拟的双向队列（虚拟的双向队列即不存在队列示例，仅存在节点之间的关联关系），AQS就是用CLH队列锁实现的

基本流程如下：

多线程请求资源过程中（acquire）：
- 如果被请求的共享资源空闲，则讲当前的请求资源的线程设为有效的工作线程，并且将共享资源设置为锁定状态
- 如果被请求的共享资源被占用，那么就将获取不到锁的线程加入FIFO队列中（队尾）
对于获取锁的线程，移出等待队列（release）：
- 更新同步器的状态
- 如果新的状态允许某个被阻塞的线程获取成功则解除队列中一个或多个线程的阻塞状态

AQS的主要数据结构

组件	数据结构
同步状态	volatile int state
阻塞	LockSupport类
同步队列	Node节点
条件队列	ConditionObject

同步器状态的原子性管理

// 共享变量，使用volatile修饰保证线程可见性
private volatile int state;// 返回同步状态的当前值
protected final int getState() {return state;
}
// 设置同步状态的值
protected final void setState(int newState) {state = newState;
}
// 原子地（CAS操作）将同步状态值设置为给定值update如果当前同步状态的值等于expect（期望值）
protected final boolean compareAndSetState(int expect, int update) {return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

在j.u.c中的做法如源码所示，将state声明为volatile，并且通过CAS指令实现原子更新，这样就达到了同步状态的原子性管理，确保了同步状态的原子性、可见性、有序性。

线程阻塞与解除阻塞

在之前，线程的阻塞与解除线程阻塞都是基于java的内置管程，没有其它非基于Java内置管程的API可以用来达到阻塞线程和解除线程阻塞。唯一可以选择的是Thread.suspend和Thread.resume，但是他们无法解决竞态问题，所以没办法使用，已被抛弃（官方抛弃原因答复）

后来到JDK1.6中，j.u.c.locks包提供了LockSupport类来解决上述问题。
方法LockSupport.park阻塞当前线直到有LockSupport.unpack方法被调用才会继续执行。
LockSupport具有如下特性：

unpark调用没有被计数，在一次park调用之前可以多次调用unpark，最终只会解除一个unpark操作。
park、unpark是作用于每个线程而不是每个同步器
park方法支持超时设置、响应Thread.interrupt，可以通过中断来unpark一个线程

同步队列

AQS的核心其实就是如何管理线程阻塞队列，该队列是严格的FIFO队列，所以线程的优先级设置在对队列中无效。

在业界中，实现同步队列的主要有两种选择：CLH锁和MCS锁，其中CLH一般用于自旋，相比于MCS，CLH更加容易实现取消和超时，所以AQS同步队列选择CLH作为实现基础，也可以说AQS是CLH的一个变种

队列的入队、出队过程

首先我们来看下在队列中Node节点的数据结构：

可以看出线程是包含在Node节点中，同时记录着上一个节点和下一个节点的引用

默认的AQS的head和tail都指向一个空节点：

入队操作：
当有新的等待节点入队时，由于CLH是FIFO队列，故在当前队列的尾节点插入。在加入队列这个操作中，同时可能有多个node需要加入，所以一定要保证线程安全，因此同步器提供了一个CAS方法，它需要传递当前线程期待的尾节点和当前节点，只有符合要求才会设置成功

出队操作：
同因为是FIFO，获取到AQS同步状态的必然是首节点，当首节点的线程释放同步状态时，会唤醒后续节点，而后续节点会在获取AQS同步状态成功的时候将自己设置为首节点。设置首节点的动作是由获取到同步状态成功的线程来完成。

这里好像没有CAS操作？确实没有，因为每次只有一个线程能够成功获取到同步状态，所以不需要像入队那样做CAS操作

条件队列

AQS除了同步队列，还包含一个条件队列。AQS只有一个同步队列，但可以有多个条件队列。条件队列指的是ConditionObject类，主要是给维护独占同步的类以及实现Lock接口的类使用

ConditionObject类实现了Condition接口，而Condition接口提供了类似Object管程式的方法，如await、signal、singnalAll操作，还扩展了带有超时、检测和监控的方法。

和Object.wait、notify、notifyAll区别？

对于操作ConditionObject，要当前线程持有锁且要操作的条件（Condition）属于该锁，condition操作才是合法的，ConditionObject关联ReentrantLock后的表现和Object内置的方法基本一样
区别还有：ConditionObject的方法名称、额外的功能、用户可以为每个锁声明多个条件

条件队列移动到同步队列（signal）

如图所示，条件队列有自己单独的队列进行管理。当调用signal操作时，将条件队列中的节点从条件队列转移到同步队列中

同步队列移动到条件队列（await）

await操作就是当前线程节点同同步队列进入条件队列进行等待，大致示意图如下：

在同步队列中释放节点，让后将节点添加到条件队列的队尾中。

因条件超时或Thread.interrupt导致取消了条件等待await如何处理？
在JSR133修订后，最终规则如下：

如果中断发生在signal操作之前，await必须要在重新获取到锁后抛出InterruptedException
如果中断发生在signal之后，await必须返回且不抛异常，同时设置程序的中断状态

AQS的两种资源共享方式

独占资源（Exclusive）

同时只有一个线程能执行，如ReentrantLock。其中获取同步状态的方式又分为公平锁和非公平锁

公平锁：按照线程在队列中的排队顺序，先到者先拿到锁，后到者后拿到锁
非公平锁：当线程要获取锁时，无视等待队列直接去尝试抢锁，谁抢到就是谁的。如果没有抢到则乖乖去排队等待（公平锁）

共享资源（Share）

同时可以有多个线程获取锁执行，如Semaphore、CountDownLatch、CyclicBarrier、ReadWriteLock的Read锁

扩展

AQS的主要方法及其作用

属性、方法	描述、作用
int getState()	获取当前同步状态
void setState(int newState)	设置当前同步状态
boolean compareAndSetState(int expect, int update)	通过CAS设置当前状态，此方法保证状态设置的原子性
boolean tryAcquire(int arg)	钩子方法，独占式获取同步状态，AQS没有具体实现，具体实现都在子类中，实现此方法需要查询当前同步状态并判断同步状态是否符合预期，然后再CAS设置同步状态
boolean tryRelease(int arg)	钩子方法，独占式释放同步状态，AQS没有具体实现，具体实现都在子类中，等待获取同步状态的线程将有机会获取同步状态
int tryAcquireShared(int arg)	钩子方法，共享式获取同步状态，AQS没有具体实现，具体实现都在子类中，返回大于等于0的值表示获取成功，反之失败
boolean tryReleaseShared(int arg)	钩子方法，共享式释放同步状态，AQS没有具体实现，具体实现都在子类中
boolean isHeldExclusively()	钩子方法，AQS没有具体实现，具体实现都在子类中，当前同步器是否在独占模式下被线程占用，一般该方法表示是否被当前线程所独占
`void acquire(int arg)`	模板方法，独占式获取同步状态，如果当前线程获取同步状态成功，则由该方法返回，否则会进入同步队列等待，此方法会调用子类重写的tryAcquire方法
void acquireInterruptibly(int arg)	模板方法，与acquire相同，但是此方法可以响应中断，当前线程未获取到同步状态而进入同步队列中，如果当前线程被中断，此方法会抛出InterruptedException并返回
boolean tryAcquireNanos(int arg, long nanosTimeout)	模板方法，在acquireInterruptibly基础上增加了超时限制，如果当前线程在超时时间内没有获取到同步状态，则会返回false,如果获取到了则会返回true
`boolean release(int arg)`	模板方法，独占式的释放同步状态，该方法会在释放同步状态后，将同步队列中的第一个节点包含的线程唤醒
void acquireShared(int arg)	模板方法，共享式的获取同步状态，如果当前系统未获取到同步状态，将会进入同步队列等待，与acquire的主要区别在于同一时刻可以有多个线程获取到同步状态
void acquireSharedInterruptibly(int arg)	模板方法，与acquireShared一致，但是可以响应中断
boolean tryAcquireSharedNanos(int arg, long nanosTimeout)	模板方法，在acquireSharedInterruptibly基础上增加了超时限制
boolean releaseShared(int arg)	模板方法，共享式的释放同步状态
Collection getQueuedThreads()	模板方法，获取等待在同步队列上的线程集合
`Node int waitStatus`	等待状态1、CANCELLED，值为1，在同步队列中等待的线程等待超时或者被中断，需要从同步队列中取消等待，节点进入该状态后将不会变化；2、 SIGNAL，值为-1，后续节点的线程处于等待状态，而当前节点的线程如果释放了同步状态或者被取消，将会通知后续节点，使后续节点的线程得以运行；3、 CONDITION，值为-2，节点在条件队列中，节点线程等待在Condition上，当其他线程对Condition调用了signal()方法后，该节点将会从条件队列中转移到同步队列中，加入到对同步状态的获取中；4、 PROPAGATE，值为-3，表示下一次共享式同步状态获取将会无条件地传播下去
Node prev	前驱节点，当节点加入同步队列时被设置
Node next	后续节点
Thread thread	获取同步状态的线程
Node nextWaiter	条件队列中的后续节点，如果当前节点是共享的，那么这个字段将是一个SHARED变量，也就是说节点类型（独占和共享）和条件队列中的后续节点共用同一个字段
LockSupport void park()	阻塞当前线程，如果调用unpark方法或者当前线程被中断，才能从park方法返回
LockSupport void unpark(Thread thread)	唤醒处于阻塞状态的线程
ConditionObject Node firstWaiter	条件队列首节点
ConditionObject Node lastWaiter	条件队列尾节点
void await()	当前线程进入等待状态直到signal或中断，当前线程将进入运行状态且从await方法返回的情况，包括：其他线程调用该Condition的signal或者signalAll方法，且当前线程被选中唤醒；其他线程调用interrupt方法中断当前线程；如果当前线程从await方法返回表明该线程已经获取了Condition对象对应的锁
void awaitUninterruptibly()	和await方法类似，但是对中断不敏感
long awaitNanos(long nanosTimeout)	当前线程进入等待状态直到被signal、中断或者超时。返回值表示剩余的时间。
boolean awaitUntil(Date deadline)	当前线程进入等待状态直到被signal、中断或者某个时间。如果没有到指定时间就被通知，方法返回true，否则表示到了指定时间，返回false
void signal()	唤醒一个等待在Condition上的线程，该线程从等待方法返回前必须获得与Condition相关联的锁
void signalAll()	唤醒所有等待在Condition上的线程，能够从等待方法返回的线程必须获得与Condition相关联的锁

看到这，我们对AQS的数据结构应该基本上有一个大致的认识

什么是SMP架构、NUMA架构？什么是CLH锁模型、MCS锁模型？

SMP（Symmetric Multi-Processor）多处理器结构

对称多处理器结构，指服务器中多个CPU对称工作，每个CPU访问内存地址所需时间相同。其主要特征是共享，包含对CPU，内存，I/O等进行共享。

SMP能够保证内存一致性，但这些共享的资源很可能成为性能瓶颈，随着CPU数量的增加，每个CPU都要访问相同的内存资源，可能导致内存访问冲突，可能会导致CPU资源的浪费。常用的PC机就属于这种。
NUMA（Non-Uniform Memory Access）非一致存储访问结构

非一致存储访问，将CPU分为CPU模块，每个CPU模块由多个CPU组成，并且具有独立的本地内存、I/O槽口等，模块之间可以通过互联模块相互访问，

访问本地内存的速度将远远高于访问远地内存(系统内其它节点的内存)的速度，这也是非一致存储访问的由来。NUMA较好地解决SMP的扩展问题，

当CPU数量增加时，因为访问远地内存的延时远远超过本地内存，系统性能无法线性增加。
MPP（Massive Parallel Processing）海量并行处理结构

与NUMA架构类似，区别在于每一个模块都是一个节点，每个节点通过互联网络进行连接、协同工作完成任务，在用户交互来看就是一个服务器系统（就是分布式）
什么是CLH锁模型（Craig, Landin, and Hagersten locks）（助记词：吃了哈）

是一个自旋锁，能确保无饥饿性，提供先来先服务的公平性。

CLH锁也是一种基于链表的可扩展、高性能、公平的自旋锁，申请线程只在本地变量上自旋，它不断轮询前驱的状态，如果发现前驱释放了锁就结束自旋。
由于自旋过程中，监控的时前置节点的变量，因此在SMP架构的共享内容模式中能够更好的提供性能
什么是MCS锁模型（John Mellor-Crummey and Michael Scott）（助记词：买CS）

与CLH最大的不同并不是链表是显示还是隐式，而是线程自旋的规则不同：CLH是在前趋结点的locked域上自旋等待，而MCS是在自己的结点的locked域上自旋等待。正因为如此，它解决了CLH在NUMA系统架构中获取locked域状态内存过远的问题。

总结来说，AQS中的链表就是为了实现上面介绍的模型，它是针对CLH锁模型的一个变种

总结

本文介绍了什么是AQS以及它的作用、基本的数据结构、AQS的运行原理等内容。在之后的文章中将会对AQS源码进行深入分析