Java并发编程 - 深入剖析ReentrantLock之非公平锁加锁流程（第1篇）
2. 解锁流程解析
在上一篇中，我们分析完A-B-C-D的加锁流程，四个线程执行加锁请求后，ReentrantLock对象的内部数据如下：
现在来解析释放锁流程。
第一步：线程A释放锁
放开线程A，让线程A执行unlock操作，
ReentrantLock.java
public void unlock() {
sync.release(1);
}
release在AbstractQueuedSynchronzier类中定义：
AbstractQueuedSynchronzier.java
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
tryRelease在AbstractQueuedSynchronizer类中定义，但是没有提供任何的实现，实现交由子类。我们这里就是ReentrantLock的内部类Sync，实现代码如下：
ReentrantLock->Sync
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
当前state=1，所以这里c=0；当前线程是拥有锁的线程。
线程A执行tryRelease操作后，state被重新设置为0，exclusiveOwnerThread为空，锁可用（free=true）。
回到release方法，执行下面的逻辑：
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
当前head的waitStatus状态为-1，执行unparkSuccessor，也就是唤醒它的后继者。
unparkSuccessor方法在AbstractQueuedSynchronizer中定义：
AbstractQueuedSynchronizer.java
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;
if (s == null || s.waitStatus > 0) {
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);
}
node为head节点，因为当前状态为-1，所以做如下操作：
compareAndSetWaitStatus(node, ws, 0);
这个操作会把头结点的waitStatus重新设置回0。
Node s = node.next;
获取下一个节点，也就是B节点，s=B。B的waitStatus为-1，执行：
if (s != null)
LockSupport.unpark(s.thread);
执行完后线程B被唤醒。A执行完毕。
总结：线程A执行解锁做了下面几件事：
- 将state设置为0
- 将自己设置成非拥有锁
- 将head节点的waitStatus设置为0
- 唤醒head节点的下一个节点
线程A执行解锁完毕后，ReentrantLock内部数据如下：
第二步：线程B继续请求锁和释放锁
前一篇文章中，线程B请求锁，由于线程A未释放，所以线程B在请求加锁的过程中被挂起了，挂起处是下面的LockSupport.park(this)处：
AbstractQueuedSynchronizer.java
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
线程B被唤醒，代码继续执行，返回线程B的中断状态。
返回到parkAndCheckInterrupt() 调用处继续执行：
AbstractQueuedSynchronizer.java
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);
}
}
若线程B是中断状态，那么，if条件成立interrupted设置为true，表示线程B被中断了，反正，不执行if条件块内代码。
我们这里不考虑线程B的中断状态，之后会有专门分析如何处理已被中断的线程。
注意：这里是个无限循环，线程B在第一次循环的时候被挂起了，那么被唤醒后会继续执行这个循环。
继续执行：B的前置节点是head节点，所以p=head，第一个if的第一个条件满足，那么就会继续执行tryAcquire方法，也就是说线程B被唤醒之后，会重新申请获得锁。
调用tryAcquire，最终会调用ReentrantLock的内部类Sync的nonfairTryAcquire方法：
ReentrantLock.Sync
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
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;
}
当前state=0, 执行if逻辑，通过CAS将state设置为1，将当前持有锁的线程设置为线程B。
tryAcquire执行完毕后，线程B获得了锁，继续执行如下代码：
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
这里首先将B设置为头结点，然后为了垃圾清理将之前head节点的next设置为null，也就是说让之前的head节点不再在和B关联。线程B的acquireQueued执行完毕，返回false（不考虑被线程的线程是中断的这个状态）。直此被唤醒的线程B获得了锁。
总结：线程B被唤醒之后做了几件事：
- 将head设置成自己
- 将state改为1
- 将exclusiveOwnerThread设置成自己
注意：线程B被唤醒后，代表它的B节点会被设置成head节点，设置head节点的代码如下：
AbstractQueuedSynchronizer.java
private void setHead(Node node) {
head = node;
node.thread = null;
node.prev = null;
}
从这里看到只要是被设置head节点的节点，thread和prev都会设置为null。
线程B再次请求成功获得锁后，ReentrantLock内部数据如下：
线程B解锁分析
线程B解锁的流程和线程A解锁的流程原理一致：
- 将state设置为0
- 将自己设置非拥有锁（exclusiveOwnerThread = null）
- 将head节点waitStatus节点设置为0
- 唤醒head的下一个节点（也就是C）
线程B解锁后，ReentrantLock内部数据如下：
第三步：线程C继续请求锁和释放锁
线程C继续请求锁和释放锁的流程和第二步一致，这里就不再说明。
线程C释放锁后，ReentrantLock内部数据如下：
第四步：线程D继续请求锁和释放锁
线程D释放锁后，ReentrantLock内部数据如下：
总结
ReentrantLock加锁解锁流程：
加锁 ：当一个线程请求锁时，发现锁已经被其他线程占用，那么就会创建一个代表自己的Node节点，然后加入到同步队列的尾部（这2个动作通过AbstractQueuedSynchronizer的addWaiter方法执行），这时候这个Node节点就变成了同步队列中的一个新尾节点，同时会将它的前置节点也就是之前的尾节点的waitStatus设置为-1（Node.SIGNAL：这个状态表示拥有这个状态的节点再释放锁后要唤醒它的后继节点），然后这个线程被挂起。
解锁：线程调用unlock方法进行解锁，首先会将state重设为0，然后设置非拥有锁（exclusiveOwnerThread = null）,执行操作成功后，每次都会从同步队列的头部开始检查head节点的waitStatus是否为-1，如果为-1，则表示后续有需要唤醒的线程，当前线程会把head节点的waitStatus重设回0，然后唤醒head的后继节点所代表的线程，执行完毕，解锁成功
被唤醒的线程重新加锁：解锁成功后head节点的后继节点锁代表的线程被唤醒， 它会重新申请获取锁，此时因为上一个加锁的线程已经释放锁，所以当前state为0，被唤醒的线程会尝试将state为1，重设成功之后（因为此时可能有其他新来的线程与它争抢），当前线程会把代表自己的Node节点设置为新head节点，同时解除与原head节点的关系（设置原head节点的next属性值为null），重新获取锁成功。