Java AQS 原理解析

AQS全称AbstractQueuedSynchronizer（同步器），Lock接口的实现基本都是通过聚合一个同步器的字类来完成线程访问控制。队列同步器AbstractQueuedSynchronizer（以下简称同步器），是用来构建锁或者其他同步组件的基础框架，它使用了一个int成员变量表示同步状态，通过内置的FIFO队列来完成资源获 取线程的排队工作，并发包的作者（Doug Lea）期望它能够成为实现大部分同步需求的基础。
接下来基于ReentrantLock类来解析AQS的实现原理

Lock lock = new ReentrantLock();
lock.lock();
try {

 } finally {
  lock.unlock();
}

对于lock对象调用lock可以进入源码一探究竟：

public void lock() {
    sync.lock();
}

而sync是一个接口，对于这个接口本类中有两个实现类NonfairSync，FairSync，由于使用无参构造函数默认实例化的是NonfairSync。这两个类就是非公平锁和公平锁的实现。
公平锁：多个线程按照申请锁的顺序去获得锁，线程会直接进入队列去排队，永远都是队列的第一位才能得到锁。
非公平锁：多个线程去获取锁的时候，会直接去尝试获取，获取不到，再去进入等待队列，如果能获取到，就直接获取到锁。
简单的来说就是公平锁好比大家买东西依次排队结账，没有人插队，对于每个人都很公平，而非公平锁就是结账排了好长的队，有的人直接插队，付钱走人，但是有时候遇到有脾气的人就会插队失败，乖乖排队（只是打个比喻）。对于公平锁来说每个人都可以依次获取到锁，不会饿死在队列中。缺点就是吞吐量会下降很多，队列里面除了第一个线程，其他的线程都会阻塞，cpu唤醒阻塞线程的开销会很大。而非公平锁来说可以减少CPU唤醒线程的开销，整体的吞吐效率会高点，CPU也不必取唤醒所有线程，会减少唤起线程的数量。缺点就是这样可能导致队列中间的线程一直获取不到锁或者长时间获取不到锁，导致饿死。
ok回到正题，ReentrantLock中公平锁和非公平锁在底层是相同的，这里以非公平锁为例进行分析。

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() {
        	// 使用CAS设置state的值，设置成功说明获取到了锁
            if (compareAndSetState(0, 1))
                setExclusiveOwnerThread(Thread.currentThread());
            else
            	//  获取失败调用AbstractQueuedSynchronizer.acquire()
                acquire(1);
        }

        protected final boolean tryAcquire(int acquires) {
            return nonfairTryAcquire(acquires);
        }
    }

lock方法中使用cas方式设置state的值，如果成功则获取到锁，将变量exclusiveOwnerThread设置为当前线程。如果设置失败则调用AbstractQueuedSynchronizer的acquire方法。

public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
}

这里只是AQS的简单实现，具体获取锁的实现方法是由各自的公平锁和非公平锁单独实现的（以ReentrantLock为例）。如果该方法返回了True，则说明当前线程获取锁成功，就不用往后执行了；如果获取失败，就需要加入到等待队列中。那么先到非公平锁中开一下具体的实现：

protected final boolean tryAcquire(int acquires) {
     return nonfairTryAcquire(acquires);
}

final boolean nonfairTryAcquire(int acquires) {
	// 获取当前线程
      final Thread current = Thread.currentThread();
      // 获取当前state状态，为0则说明当前没有线程获取到锁
      int c = getState();
      if (c == 0) {
      		// 尝试获取锁
           if (compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
        }
        // 可重入设计，无论是公平锁还是非公平的锁都有这一段
      else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
      }
     return false;
 }

对于非公平锁tryAcquire的实现，每个线程在之前获取锁失败之后都可以重新再获取一次，就好比排队，有很对人在前面排队，但是还尝试插到第一位获取锁资格，如果插队失败了才会乖乖去排队。
接下来看一下公平锁的实现：

protected final boolean tryAcquire(int acquires) {
      final Thread current = Thread.currentThread();
      int c = getState();
      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;
}

hasQueuedPredecessors是公平锁加锁时判断等待队列中是否存在有效节点的方法。如果返回False，说明当前线程可以争取共享资源；如果返回True，说明队列中存在有效节点，当前线程必须加入到等待队列中。

public final boolean hasQueuedPredecessors() {
        // The correctness of this depends on head being initialized
        // before tail and on head.next being accurate if the current
        // thread is first in queue.
        Node t = tail; // Read fields in reverse initialization order
        Node h = head;
        Node s;
        return h != t &&
            ((s = h.next) == null || s.thread != Thread.currentThread());
    }

为什么要判断next？

双向链表中，第一个节点为虚节点，其实并不存储任何信息，只是占位。真正的第一个有数据的节点，是在第二个节点开始的。当h != t时： 如果(s = h.next) == null，等待队列正在有线程进行初始化，但只是进行到了Tail指向Head，没有将Head指向Tail，此时队列中有元素，需要返回True（这块具体见下边代码分析）。 如果(s = h.next) != null，说明此时队列中至少有一个有效节点。如果此时s.thread == Thread.currentThread()，说明等待队列的第一个有效节点中的线程与当前线程相同，那么当前线程是可以获取资源的；如果s.thread != Thread.currentThread()，说明等待队列的第一个有效节点线程与当前线程不同，当前线程必须加入进等待队列。

再回到acquire，当tryAcquire失败时，则会调用addWaiter将线程节点加入到等待队列中。

public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
}

private Node addWaiter(Node mode) {
		// 构建当前线程node节点
        Node node = new Node(Thread.currentThread(), mode);
        // Try the fast path of enq; backup to full enq on failure
        // 将尾节点设置给pred
        Node pred = tail;
        if (pred != null) {
        	// 将构建的节点加到尾部，也就是将New中Node的Prev指针指向pred
            node.prev = pred;
            // 通过compareAndSetTail方法，完成尾节点的设置。这个方法主要是对tailOffset和Expect进行比较，如果tailOffset的Node和Expect的Node地址是相同的，那么设置Tail的值为Update的值
            if (compareAndSetTail(pred, node)) {
            	// 因为是双向列表所以需要将next节点设置给node
                pred.next = node;
                return node;
            }
        }
        // 如果Pred指针是Null（说明等待队列中没有元素），或者当前Pred指针和Tail指向的位置不同（说明被别的线程已经修改），就需要看一下Enq的方法。
        enq(node);
        return node;
 }

接着看一下：

private Node enq(final Node node) {
        for (;;) {
            Node t = tail;
            // 如果没有初始化，先初始化一个头节点出来，前面提到过头节点是一个虚拟的节点，不包含任何信息，所以调用了一下无参构造函数
            if (t == null) { // Must initialize
            	// 使用CAS的方式设置一下头节点
                if (compareAndSetHead(new Node()))
                    tail = head;
            } else {
            	// 初始化完结点之后才会设置node节点到尾部
                node.prev = t;
                if (compareAndSetTail(t, node)) {
                    t.next = node;
                    return t;
                }
            }
     }
}

添加完线程节点到队列之后，acquireQueued会把放入队列中的线程不断去获取锁，直到获取成功或者不再需要获取（中断）。那么队列中的线程又是怎么获取锁的继续往下面看：

final boolean acquireQueued(final Node node, int arg) {
		// 标记是否成功拿到资源
        boolean failed = true;
        try {
        	// 标记等待过程是否中断过
            boolean interrupted = false;
            // 开始自旋，要么获取锁，要么中断
            for (;;) {
            	// 获取排在前面的节点
                final Node p = node.predecessor();
                // 如果p是头节点，说明node节点是队列中的第一个有数据的真实节点（头节点为虚拟节点），尝试获取锁
                if (p == head && tryAcquire(arg)) {
                	// 获取锁成功，头指针移动到当前node，会把线程信息和prev置为null作为虚拟节点使用
                    setHead(node);
                    p.next = null; // help GC
                    failed = false;
                    return interrupted;
                }
                // 说明p为头节点且当前没有获取到锁（可能是非公平锁被抢占了）或者是p不为头结点，这个时候就要判断当前node是否要被阻塞（被阻塞条件：前驱节点的waitStatus为-1），防止无限循环浪费资源。具体两个方法下面细细分析
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    interrupted = true;
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
}

具体怎么判断当前node是否需要阻塞，还要进到shouldParkAfterFailedAcquire中查看：

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
		// 获取前一个节点的状态
        int ws = pred.waitStatus;
        if (ws == Node.SIGNAL)
            /*
             * This node has already set status asking a release
             * to signal it, so it can safely park.
             */
            return true;
         // 从上面的属性可以看到static final int CANCELLED =  1;大于0的时候节点是取消状态
        if (ws > 0) {
            /*
             * Predecessor was cancelled. Skip over predecessors and
             * indicate retry. 循环向前剔除状态为cancel的节点
             */
            do {
                node.prev = pred = pred.prev;
            } while (pred.waitStatus > 0);
            pred.next = node;
        } else {
            /*
             * 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);
        }
        return false;
    }

这个方法里面判断了一下pred的节点状态，如果当前状态为SIGNAL表示前驱释放会通知唤醒你，节点可以放心parking，如果状态大于0说明前置节点为取消状态，需要移除该节点，如果前置节点既不等于-1并且还小于0则将前置节点的状态设置为-1。对于节点状态：

CANCELED表示线程等待已经取消，是唯一一个大于0的状态。
SINALG表示需要唤醒next节点
CONDITION表明线程正在等待一个条件
PROPAGATE用于acquireShared中向后传播

如果需要阻塞则使用LockSupport.park去阻塞线程：

private final boolean parkAndCheckInterrupt() {
        LockSupport.park(this);
        return Thread.interrupted();
}

对于LockSupport不再扩展，最后会返回一下线程的中断状态，如果中断了将标志位设置为true。在acquireQueued方法的最后有一个if (failed) cancelAcquire(node); 看名字是取消节点获取，具体看下代码：

private void cancelAcquire(Node node) {
        // Ignore if node doesn't exist
        // 忽略不存在的节点
        if (node == null)
            return;
		// 将该节点关联的线程置为null，设置为虚拟节点
        node.thread = null;

        // Skip cancelled predecessors
        // 获取没有被取消的前置节点
        Node pred = node.prev;
        while (pred.waitStatus > 0)
            node.prev = pred = pred.prev;

        // predNext is the apparent node to unsplice. CASes below will
        // fail if not, in which case, we lost race vs another cancel
        // or signal, so no further action is necessary.
        // 获取过滤后的前驱节点的后继节点
        Node predNext = pred.next;

        // Can use unconditional write instead of CAS here.
        // After this atomic step, other Nodes can skip past us.
        // Before, we are free of interference from other threads.
        // 将node节点的状态改为取消
        node.waitStatus = Node.CANCELLED;

        // If we are the tail, remove ourselves.
        // 如果当前节点是尾节点，将从后往前的第一个非取消状态的节点设置为尾节点
 	 	// 更新失败的话，则进入else，如果更新成功，将tail的后继节点设置为null
        if (node == tail && compareAndSetTail(node, pred)) {
            compareAndSetNext(pred, predNext, null);
        } else {
            // If successor needs signal, try to set pred's next-link
            // so it will get one. Otherwise wake it up to propagate.
            int ws;
            // 如果当前节点不是head的后继节点，1:判断当前节点前驱节点的是否为SIGNAL，2:如果不是，则把前驱节点设置为SINGAL看是否成功
    		// 如果1和2中有一个为true，再判断当前节点的线程是否为null
    		// 如果上述条件都满足，把当前节点的前驱节点的后继指针指向当前节点的后继节点
            if (pred != head &&
                ((ws = pred.waitStatus) == Node.SIGNAL ||
                 (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
                pred.thread != null) {
                Node next = node.next;
                if (next != null && next.waitStatus <= 0)
                    compareAndSetNext(pred, predNext, next);
            } else {
            	// 如果当前节点是head的后继节点，或者上述条件不满足，那就唤醒当前节点的后继节点
                unparkSuccessor(node);
            }

            node.next = node; // help GC
        }
    }

对Next指针进行了操作，而没有对Prev指针进行操作呢？什么情况下会对Prev指针进行操作？

执行cancelAcquire的时候，当前节点的前置节点可能已经从队列中出去了（已经执行过Try代码块中的shouldParkAfterFailedAcquire方法了），如果此时修改Prev指针，有可能会导致Prev指向另一个已经移除队列的Node，因此这块变化Prev指针不安全。 shouldParkAfterFailedAcquire方法中，会执行下面的代码，其实就是在处理Prev指针。shouldParkAfterFailedAcquire是获取锁失败的情况下才会执行，进入该方法后，说明共享资源已被获取，当前节点之前的节点都不会出现变化，因此这个时候变更Prev指针比较安全。
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);

加锁的代码看完了再来看一下解锁的过程，相比加锁而言解锁并不取分公平锁和非公平锁：

public void unlock() {
        sync.release(1);
}

在ReentrantLock里面的公平锁和非公平锁的父类Sync定义了可重入锁的释放锁机制。

// 方法返回当前锁是不是没有被线程持有
public final boolean release(int arg) {
        if (tryRelease(arg)) {
        	// 获取头节点
            Node h = head;
            // 头节点不为null并且节点状态不是初始化状态，解除线程挂起状态
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
}

h == null Head还没初始化。初始情况下，head == null，第一个节点入队，Head会被初始化一个虚拟节点。所以说，这里如果还没来得及入队，就会出现head == null 的情况。
h != null && waitStatus == 0 表明后继节点对应的线程仍在运行中，不需要唤醒。
h != null && waitStatus < 0 表明后继节点可能被阻塞了，需要唤醒。

Sync类中
protected final boolean tryRelease(int releases) {
			// 减少冲入次数
            int c = getState() - releases;
            // 如果当前本线程不是持有线程
            if (Thread.currentThread() != getExclusiveOwnerThread())
                throw new IllegalMonitorStateException();
            boolean free = false;
            // // 如果持有线程全部释放，将当前独占锁所有线程设置为null，并更新state
            if (c == 0) {
                free = true;
                setExclusiveOwnerThread(null);
            }
            setState(c);
            return free;
        }

解除挂起代码：

private void unparkSuccessor(Node node) {
        /*
         * If status is negative (i.e., possibly needing signal) try
         * to clear in anticipation of signalling.  It is OK if this
         * fails or if status is changed by waiting thread.
         */
        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;
        // 如果下个节点是null或者下个节点被cancelled，就找到队列最开始的非cancelled的节点
        if (s == null || s.waitStatus > 0) {
            s = null;
            //  就从尾部节点开始找，到队首，找到队列第一个waitStatus<0的节点。
            for (Node t = tail; t != null && t != node; t = t.prev)
                if (t.waitStatus <= 0)
                    s = t;
        }
        // 如果当前节点的下个节点不为空，而且状态<=0，就把当前节点unpark
        if (s != null)
            LockSupport.unpark(s.thread);
}

上面代码有个疑问，为什么是从后往前查找非canceled节点？首先是之前的入队操作：

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

节点入队并不是原子操作，也就是说，node.prev = pred; compareAndSetTail(pred, node) 这两个地方可以看作Tail入队的原子操作，但是此时pred.next = node;还没执行，如果这个时候执行了unparkSuccessor方法，就没办法从前往后找了，所以需要从后往前找。还有一点原因，在产生CANCELLED状态节点的时候，先断开的是Next指针，Prev指针并未断开，因此也是必须要从后往前遍历才能够遍历完全部的Node。综上所述，如果是从前往后找，由于极端情况下入队的非原子操作和CANCELLED节点产生过程中断开Next指针的操作，可能会导致无法遍历所有的节点。

解除挂起最后唤醒了阻塞中的线程，解除唤醒线程接下来怎么做呢？当然是回到之前阻塞的地方：

private final boolean parkAndCheckInterrupt() {
	LockSupport.park(this);
	return Thread.interrupted();
}

唤醒之后会返回线程中断状态，并清除（whether the current thread has been interrupted. The interrupted status of the thread is cleared by this method）,方法返回回到acquireQueued

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);
        }
 }

parkAndCheckInterrupt返回True或者False的时候，interrupted的值不同，但都会执行下次循环。如果这个时候获取锁成功，就会把当前interrupted返回。如果acquireQueued返回的是true，说明interrupted为true，执行selfInterrupt()方法，：

static void selfInterrupt() {
   Thread.currentThread().interrupt();
}

为什么抢到锁之后还要再中断线程：

1.当中断线程被唤醒时，并不知道被唤醒的原因，可能是当前线程在等待中被中断，也可能是释放了锁以后被唤醒。因此我们通过Thread.interrupted()方法检查中断标记（该方法返回了当前线程的中断状态，并将当前线程的中断标识设置为False），并记录下来，如果发现该线程被中断过，就再中断一次。
2.线程在等待资源的过程中被唤醒，唤醒后还是会不断地去尝试获取锁，直到抢到锁为止。也就是说，在整个流程中，并不响应中断，只是记录中断记录。最后抢到锁返回了，那么如果被中断过的话，就需要补充一次中断。

参考文章地址：从ReentrantLock的实现看AQS的原理及应用