队列同步器（AQS）
队列同步器AbstractQueuedSynchronizer（以下简称同步器），是用来构建锁或者其他同步组件的基础框架，它使用了一个int成员变量表示同步状态，通过内置的FIFO队列来完成资源获取线程的排队工作，并发包的作者（Doug Lea）期望它能够成为实现大部分同步需求的基础。
队列同步器的基本结构
同步器依赖内部的同步队列（一个FIFO双向队列）来完成同步状态的管理。同步队列中的节点（Node）用来保存"获取同步状态失败的线程"引用、等待状态以及前驱和后继节点。
同步器包含了两个节点类型的引用，一个指向头节点，而另一个指向尾节点。
public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer
implements java.io.Serializable {
......
private transient volatile Node head;//头节点
private transient volatile Node tail;//尾节点
private volatile int state;//*同步状态*
......
static final class Node {
volatile int waitStatus;//等待状态
volatile Node prev;//前驱
volatile Node next;//后继
volatile Thread thread;//线程引用
......
}
......
} 注：Node类型的prev、next属性以及AbstractQueuedSynchronizer类型的head 、tail属性都设置为volatile，保证可见性。
自定义同步组件的设计思路
同步器的主要使用方式是继承，子类通过继承同步器并实现它的抽象方法来管理同步状态，在抽象方法的实现过程中免不了要对同步状态进行更改，这时就需要使用同步器提供的3个方法（getState()、setState(int newState)、compareAndSetState(int expect,int update)）来进行操作，因为它们能够保证状态的改变是安全的
子类推荐被定义为自定义同步组件的静态内部类，同步器自身没有实现任何同步接口，它仅仅是定义了若干同步状态获取和释放的方法来供自定义同步组件使用，同步器既可以支持独占式地获取同步状态，也可以支持共享式地获取同步状态，这样就可以方便实现不同类型的同步组件（ReentrantLock、ReentrantReadWriteLock和CountDownLatch等)
同步器是实现锁（也可以是任意同步组件）的关键，在锁的实现中聚合（组合）同步器，利用同步器实现锁的语义。可以这样理解二者之间的关系：锁是面向使用者的，它定义了使用者与锁交互的接口（比如可以允许两个线程并行访问），隐藏了实现细节；同步器面向的是锁的实现者，它简化了锁的实现方式，屏蔽了同步状态管理、线程的排队、等待与唤醒等底层操作。锁和同步器很好地隔离了使用者和实现者所需关注的领域。
同步器的设计是基于模板方法模式的，也就是说，使用者需要继承同步器并重写指定的方法，随后将同步器组合在自定义同步组件的实现中，并调用同步器提供的模板方法，而这些模板方法将会调用使用者重写的方法。
重写同步器指定的方法时，需要使用同步器提供的如下3个方法来访问或修改同步状态。
getState()：获取当前同步状态。
setState(int newState)：设置当前同步状态。
compareAndSetState(int expect,int update)：使用CAS设置当前状态，该方法能够保证状态设置的原子性
独占式同步组件的设计
同步器可重写的方法
/*Attempts to acquire in exclusive mode. This method should query if the state of the object
permits it to be acquired in the exclusive mode, and if so to acquire it.*/
//独占式获取同步状态，实现该方法需要查询当前状态并判断同步状态是否符合预期，然后再进行CAS设置同步状态
protected boolean tryAcquire(int arg)
/*Attempts to set the state to reflect a release in exclusive mode.*/
//独占式释放同步状态，等待获取同步状态的线程将有机会获取同步状态
protected boolean tryRelease(int arg)
/*Returns true if synchronization is held exclusively with respect to the current (calling) thread. */
//当前同步器是否在独占模式下被线程占用，一般该方法表示是否被当前线程所独占
protected boolean isHeldExclusively()同步器提供的模板方法
/*Acquires in exclusive mode, ignoring interrupts.*/
//独占式获取同步状态，如果当前线程获取同步状态成功，立即返回。否则，将会进入同步队列等待，
//该方法将会重复调用重写的tryAcquire(int arg)方法
public final void acquire(int arg)
/*Acquires in exclusive mode, aborting if interrupted.*/
//与acquire(int arg)基本相同，但是该方法响应中断。
public final void acquireInterruptibly(int arg)
/* Releases in exclusive mode. Implemented by unblocking one or more threads if {@link #tryRelease} returns true.
This method can be used to implement method {@link Lock#unlock}.*/
//独占式释放同步状态，该方法会在释放同步状态后，将同步队列中第一个节点包含的线程唤醒
public final boolean release(int arg) public final void acquire(int arg) {//**该方法是模板方法**
if (!tryAcquire(arg) &&//先通过tryAcquire获取同步状态
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))//获取同步状态失败则生成节点并加入同步队列
selfInterrupt();
}独占式同步状态获取流程
主要逻辑：首先调用自定义同步器实现的tryAcquire(int arg)方法，该方法保证线程安全的获取同步状态，如果同步状态获取失败，则构造同步节点（独占式Node.EXCLUSIVE，同一时刻只能有一个线程成功获取同步状态）并通过addWaiter(Node node)方法将该节点加入到同步队列的尾部，最后调用acquireQueued(Node node,int arg)方法，使得该节点以“死循环”的方式获取同步状态。
将节点加入同步队列: 当前线程获取同步状态失败时，同步器会将当前线程、等待状态等信息构造成为一个节点（Node）并将其加入同步队列，同时会阻塞当前线程。
试想一下，当一个线程成功地获取了同步状态（或者锁），其他线程将无法获取到同步状态，转而被构造成为节点并加入到同步队列中，而这个加入队列的过程必须要保证线程安全。
因此，同步器提供了一个基于CAS的设置尾节点的方法：compareAndSetTail(Nodeexpect,Nodeupdate)，它需要传递当前线程“认为”的尾节点和当前节点，只有设置成功后，当前节点才正式与之前的尾节点建立关联。
//将节点加入到同步队列的尾部
private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode);//生成节点（Node）
// Try the fast path of enq; backup to full enq on failure
//快速尝试在尾部添加
Node pred = tail;
if (pred != null) {
node.prev = pred;//先将当前节点node的前驱指向当前tail
if (compareAndSetTail(pred, node)) {//CAS尝试将tail设置为node
//如果CAS尝试成功，就说明"设置当前节点node的前驱"与"CAS设置tail"之间没有别的线程设置tail成功
//只需要将"之前的tail"的后继节点指向node即可
pred.next = node;
return node;
}
}
enq(node);//否则，通过死循环来保证节点的正确添加
return node;
} 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)) {//直到CAS成功为止
t.next = node;
return t;//结束循环
}
}
}
}在enq(final Node node)方法中，同步器通过“死循环”来保证节点的正确添加，在“死循环”中只有通过CAS将节点设置成为尾节点之后，当前线程才能从该方法返回，否则，当前线程不断地尝试设置。可以看出，enq(final Node node)方法将并发添加节点的请求通过CAS变得“串行化”了。
串行化的优点:如果通过加锁同步的方式添加节点，线程必须获取锁后才能添加尾节点，那么必然会导致其他线程等待加锁而阻塞，获取锁的线程释放锁后阻塞的线程又会被唤醒，而线程的阻塞和唤醒需要依赖于系统内核完成，因此程序的执行需要从用户态切换到核心态，而这样的切换是非常耗时的操作。如果我们通过”循环CAS“来添加节点的话，所有线程都不会被阻塞，而是不断失败重试，线程不需要进行锁同步，不仅消除了线程阻塞唤醒的开销而且消除了加锁解锁的时间开销。但是循环CAS也有其缺点，循环CAS通过不断尝试来添加节点，如果说CAS操作失败那么将会占用处理器资源。
节点的自旋: 节点进入同步队列之后，就进入了一个自旋的过程，每个节点（或者说是线程）都在自省地观察，当条件满足，获取到了同步状态，就可以从这个自旋过程中退出，否则依旧留在这个自旋过程中。
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {//无限循环
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {//前驱节点是首节点且获取到了同步状态
setHead(node); //设置首节点
p.next = null; // help GC 断开引用
failed = false;
return interrupted;//从自旋中退出
}
if (shouldParkAfterFailedAcquire(p, node) &&//获取同步状态失败后判断是否需要阻塞或中断
parkAndCheckInterrupt())//阻塞当前线程
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
} /**Checks and updates status for a node that failed to acquire.
* Returns true if thread should block. This is the main signal control in all acquire loops.*/
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;//获取前驱节点的等待状态
if (ws == Node.SIGNAL)
//SIGNAL状态：前驱节点释放同步状态或者被取消，将会通知后继节点。因此，可以放心的阻塞当前线程，返回true。
/* This node has already set status asking a release to signal it, so it can safely park.*/
return true;
if (ws > 0) {//前驱节点被取消了，跳过前驱节点并重试
/* Predecessor was cancelled. Skip over predecessors and indicate retry. */
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {//独占模式下，一般情况下这里指前驱节点等待状态为SIGNAL
/* waitStatus must be 0 or PROPAGATE. Indicate that we need a signal, but don't park yet. Caller will need to
* retry to make sure it cannot acquire before parking. */
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);//设置当前节点等待状态为SIGNAL
}
return false;
} /** Convenience method to park and then check if interrupted 。return {@code true} if interrupted */
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);//阻塞当前线程
return Thread.interrupted();
}
可以看到节点和节点之间在循环检查的过程中基本不相互通信，而是简单地判断自己的前驱是否为头节点，这样就使得节点的释
放规则符合FIFO。并且也便于对过早通知的处理（过早通知是指：前驱节点不是头节点的线程由于中断而被唤醒）。
当同步状态获取成功之后，当前线程从acquire(int arg)方法返回，如果对于锁这种并发组件而言，代表着当前线程获取了锁。
设置首节点: 同步队列遵循FIFO，首节点是获取同步状态成功的节点，首节点的线程在释放同步状态时，将会唤醒后续节点，而后续节点将会在获取同步状态成功时将自己设置为首节点。
设置首节点是由获取同步状态成功的线程来完成的，由于只有一个线程能够成功的获取到同步状态，因此设置头节点的方法并不需要使用CAS来保证，它只需要将首节点设置成为原首节点后继节点，并断开首节点的next引用即可。
释放同步状态
当前线程获取同步状态并执行了相应逻辑之后，就需要释放同步状态，使得后续节点能够继续获取同步状态。通过调用同步器的release(int arg)方法可以释放同步状态，该方法在释放了同步状态之后，会"唤醒"其后继节点（进而使后继节点重新尝试获取同步状态）。
public final boolean release(int arg) {
if (tryRelease(arg)) {//释放同步状态
Node h = head;
if (h != null && h.waitStatus != 0)//独占模式下这里表示SIGNAL
unparkSuccessor(h);//唤醒后继节点
return true;
}
return false;
} /** Wakes up node's successor, if one exists.*/
private void unparkSuccessor(Node node) {
int ws = node.waitStatus;//获取当前节点等待状态
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);//更新等待状态
/* Thread to unpark is held in successor, which is normally just the next node.
But if cancelled or apparently null,
* traverse backwards from tail to find the actual non-cancelled successor.*/
Node s = node.next;
if (s == null || s.waitStatus > 0) {//找到第一个没有被取消的后继节点（等待状态为SIGNAL）
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
if (s != null)
LockSupport.unpark(s.thread);//唤醒后继线程
}总结：在获取同步状态时，同步器维护一个同步队列，获取状态失败的线程都会被加入到队列中并在队列中进行自旋；移出队列
（或停止自旋）的条件是前驱节点为头节点且成功获取了同步状态。在释放同步状态时，同步器调用tryRelease(int arg)方法释放同步状态，然后唤醒头节点的后继节点。
独占锁 自定义
import java.util.Collection;
import java.util.concurrent.locks.AbstractQueuedSynchronizer;
public class Mutex {
// 静态内部类，自定义同步器
private static class Sync extends AbstractQueuedSynchronizer {
// 是否处于占用状态
protected boolean isHeldExclusively() {
return getState() == 1;
}
// 当状态为0的时候获取锁
public boolean tryAcquire(int acquires) {
if (compareAndSetState(0, 1)) {
setExclusiveOwnerThread(Thread.currentThread());
return true;
}
return false;
}
// 释放锁，将状态设置为0
protected boolean tryRelease(int releases) {
if (getState() == 0)
throw new IllegalMonitorStateException();
setExclusiveOwnerThread(null);
setState(0);
return true;
}
}
// 仅需要将操作代理到Sync上即可
private final Sync sync = new Sync();
//获取等待的线程
public Collection<Thread> getQueuedThreads(){
return sync.getQueuedThreads();
}
//独占锁的操作接口
public void lock() {//获取锁
sync.acquire(1);
}
public void unlock() {//释放锁
sync.release(1);
}
}import java.util.Collection;
import java.util.Random;
public class MutexTestSecond {
private static Random r=new Random(47);
private static int threadCount=10;
private static Mutex mut=new Mutex();
private static class Weight implements Runnable{//给苹果称重的任务
String name;
public Weight(String name){
this.name=name;
}
@Override
public void run() {
mut.lock();
System.out.println(name+"放苹果！");
System.out.println(name+"重量："+(r.nextInt(10)+3));
System.out.println(name+"取苹果！");
printQueuedThreads(mut.getQueuedThreads());
mut.unlock();
}
}
private static void printQueuedThreads(Collection<Thread> threads){
System.out.print("等待队列中的线程：");
for(Thread t:threads){
System.out.print(t.getName()+" ");
}
System.out.println();
}
public static void main(String[] args) {
Thread[] threads=new Thread[threadCount];
for(int i=0;i<threadCount;i++){
threads[i]=new Thread(new Weight("Weight-"+i),"Thread-"+i);
}
for(int i=0;i<threadCount;i++){
threads[i].start();
}
}
}输出：
Weight-0放苹果！
Weight-0重量：11
Weight-0取苹果！
等待队列中的线程：Thread-3 Thread-2 Thread-1
Weight-6放苹果！
Weight-6重量：8
Weight-6取苹果！
等待队列中的线程：Thread-8 Thread-7 Thread-5 Thread-4 Thread-3 Thread-2 Thread-1
Weight-1放苹果！
Weight-1重量：6
Weight-1取苹果！
等待队列中的线程：Thread-9 Thread-8 Thread-7 Thread-5 Thread-4 Thread-3 Thread-2
Weight-2放苹果！
Weight-2重量：4
Weight-2取苹果！
等待队列中的线程：Thread-9 Thread-8 Thread-7 Thread-5 Thread-4 Thread-3
Weight-3放苹果！
Weight-3重量：4
Weight-3取苹果！
等待队列中的线程：Thread-9 Thread-8 Thread-7 Thread-5 Thread-4
Weight-4放苹果！
Weight-4重量：12
Weight-4取苹果！
等待队列中的线程：Thread-9 Thread-8 Thread-7 Thread-5
Weight-5放苹果！
Weight-5重量：11
Weight-5取苹果！
等待队列中的线程：Thread-9 Thread-8 Thread-7
Weight-7放苹果！
Weight-7重量：3
Weight-7取苹果！
等待队列中的线程：Thread-9 Thread-8
Weight-8放苹果！
Weight-8重量：5
Weight-8取苹果！
等待队列中的线程：Thread-9
Weight-9放苹果！
Weight-9重量：10
Weight-9取苹果！
等待队列中的线程：
从输出中可以看出，我们的独占锁Mutex，保证了秤的独占使用。
共享式同步组件设计
可重写的方法
/**Attempts to acquire in shared mode. This method should query if the state of the object
permits it to be acquired in the shared mode, and if so to acquire it.*/
//共享式获取同步状态，返回大于等于0的值，表示获取成功，反之获取失败
protected int tryAcquireShared(int arg)
/**Attempts to set the state to reflect a release in shared mode.*/
//共享式释放同步状态
protected boolean tryReleaseShared(int arg)同步器提供的模板方法
/**Acquires in shared mode, ignoring interrupts.*/
//共享式获取同步状态，如果当前线程未获取到同步状态，将会进入同步队列等待
//与独占式获取的主要区别是在同一时刻可以有多个线程获取到同步状态
public final void acquireShared(int arg)
/**Acquires in exclusive mode, aborting if interrupted.*/
//该方法可以响应中断
public final void acquireInterruptibly(int arg)共享式获取与独占式获取最主要的区别在于同一时刻能否有多个线程同时获取到同步状态。以文件的读写为例，如果一个程序在对文件进行读操作，那么这一时刻对于该文件的写操作均被阻塞，而读操作能够同时进行。写操作要求对资源的独占式访问，而读操作可以是共享式访问。
获取同步状态
调用同步器的acquireShared(int arg)方法可以共享式地获取同步状态。
public final void acquireShared(int arg) {
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}在acquireShared(int arg)方法中，同步器调用tryAcquireShared(int arg)方法尝试获取同步状态，tryAcquireShared(int arg)方法返回值为int类型，当返回值大于等于0时，表示能够获取到同步状态。因此，在共享式获取的自旋过程中，成功获取到同步状态并退出自旋的条件就是tryAcquireShared(int arg)方法返回值大于等于0。
在doAcquireShared(int arg)方法的自旋过程中，如果当前节点的前驱为头节点时，尝试获取同步状态，如果返回值大于等于0，表示该次获取同步状态成功并从自旋过程中退出。
释放同步状态
与独占式一样，共享式获取也需要释放同步状态，通过调用releaseShared(int arg)方法可以释放同步状态。
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}该方法在释放同步状态之后，将会唤醒后续处于等待状态的节点。对于能够支持多个线程同时访问的并发组件（比Semaphore），它和独占式主要区别在于tryReleaseShared(int arg)方法必须确保同步状态（或者资源数）线程安全释放，一般是通过循环和CAS来保证的，因为释放同步状态的操作会同时来自多个线程。
独占式超时获取同步状态
共享锁 自定义
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.AbstractQueuedSynchronizer;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
public class TwinsLock implements Lock {
private final Sync sync = new Sync(2);
private static final class Sync extends AbstractQueuedSynchronizer {
Sync(int count) {
if(count < 0) {
throw new IllegalArgumentException("count must large than zero");
}
setState(count);
}
@Override
public int tryAcquireShared(int reducecount) {
for (;;) {
int current = getState();
int newCount = current - reducecount;
if (newCount < 0 || compareAndSetState(current,newCount)) {
return newCount;
}
}
}
@Override
protected boolean tryReleaseShared(int returnCount) {
for(;;) {
int current = getState();
int newCount = current + returnCount;
if (compareAndSetState(current,newCount)) {
return true;
}
}
}
}
@Override
public void lock() {
sync.acquireShared(1);
}
@Override
public void unlock() {
sync.releaseShared(1);
}
@Override
public void lockInterruptibly() throws InterruptedException {
}
@Override
public boolean tryLock() {
return false;
}
@Override
public boolean tryLock(long time, TimeUnit unit) throws InterruptedException {
return false;
}
@Override
public Condition newCondition() {
return null;
}
}import org.junit.jupiter.api.Test;
import java.util.concurrent.locks.Lock;
public class TwinsLockTest {
@Test
void test() {
final Lock lock = new TwinsLock();
class Worker extends Thread
{
public void run()
{
while (true)
{
lock.lock();
try {
Thread.currentThread().sleep(1000);
System.out.println(Thread.currentThread().getName());
Thread.currentThread().sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
}
}
//启动10个线程
for(int i =0; i < 10; i++)
{
Worker w = new Worker();
w.setDaemon(true);
w.start();
}
//每隔1秒换行
for(int i =0; i < 10; i++)
{
try {
Thread.currentThread().sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println();
}
}
}
可以看到输出的线程都是成对的，也就是同一时刻只有两个线程能够获得锁
锁的公平性和非公平性
公平性与否是针对获取锁而言的，如果一个锁是公平的，那么锁的获取顺序就应该符合请求的绝对时间顺序，也就是FIFO。
非公平性的实现
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
/**Performs lock. Try immediate barge, backing up to normal acquire on failure.*/
final void lock() {
if (compareAndSetState(0, 1))//只要CAS更新同步状态成功就获取到锁。
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
}非公平性实例，如果Thread-1拥有锁，Thread-2和Thread-3在同步队列中，当Thread-1释放锁后会唤醒Thread-2，但是如果此时Thread-1重新申请锁，可能依然是Thread-1获取到锁。甚至这时候Thread-4也申请锁，Thread-4也可能比Thread-2先获取锁。
非公平锁可能使得线程“饥饿”。当一个线程请求锁时，只要获取了同步状态即成功获取锁。在这个前提下，刚释放锁的线程再次获取同步状态的几率会非常大，使得其他线程只能在同步队列中等待。
公平性的实现
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
acquire(1);
}
/** Fair version of tryAcquire. Don't grant access unless recursive call or no waiters or is first.*/
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
//这里没有一进来就直接进行CAS操作
if (c == 0) {
//增加是否有前驱线程的判断 从而保证公平性
if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
}公平锁与非公平锁的比较
公平性与否是针对获取锁而言的，如果一个锁是公平的，那么锁的获取顺序就应该符合请求的绝对时间顺序，也就是FIFO。
公平性锁每次都是从同步队列中的第一个节点获取到锁，而非公平性锁出现了一个线程连续获取锁的情况。
非公平性锁可能使线程“饥饿”，当一个线程请求锁时，只要获取了同步状态即成功获取锁。在这个前提下，刚释放锁的线程再次获取同步状态的几率会非常大，使得其他线程只能在同步队列中等待。
非公平锁可能使线程“饥饿”，为什么它又被设定成默认的实现呢？非公平性锁模式下线程上下文切换的次数少，因此其性能开销更小。公平性锁保证了锁的获取按照FIFO原则，而代价是进行大量的线程切换。非公平性锁虽然可能造成线程“饥饿”，但极少的线程切换，保证了其更大的吞吐量。
348
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
