JDK源码走读之ReentrantLock

ReentrantLock的功能几乎等同于Synchronized，在分析源码之前，我们首先来明确一下ReentrantLock要实现的功能，这样才能做到有的放矢。

1. 控制线程执行顺序。当线程获取锁进入Synchronized代码块（获取监视器），其余线程必须等待该线程执行完毕，才能继续执行该代码块。
2. 提供线程通信功能。Synchronized关键字支持在其代码块中使用await、notify、notifyAll来进行线通信。执行await会使当前线程释放掉锁进入阻塞状态，直到被其他线程执行notify、notifyAll唤醒。

ReentrantLock通过lock()、unlock()方法控制线程执行顺序，Condition.await()和Condition.signal()实现线程通信。

类图

ReentrantLock主要依赖AbstractQueuedSynchronized(以下简称AQS)实现。AQS继承父类AbstractOwnableSychronized特性能够持有一个线程，它自身还维护Node和ConditionObject两个队列。

1. ReentrantLock使用AQS能够持有一个线程的特性来标识当前正在执行的线程。
2. ReentrantLock把Node队列用作同步队列，用来存放获取锁失败的线程；把ConditionObject用作阻塞队列，用来存放阻塞线程(执行await方法)。

定义

public class ReentrantLock {
    private final Sync sync;
    public void lock() {
        sync.lock();
    }
    public void unlock() {
        sync.release(1);
    }
    public Condition newCondition() {
        return sync.newCondition();
    }
    abstract static class Sync extends AbstractQueuedSynchronizer {...}
    static final class FairSync extends Sync{...}
    static final class NonfairSync extends Sync{...}
}

ReentrantLock使用策略模式提供公平锁和非公平锁两种实现。使用无参构造方法默认使用非公平策略，也可以使用带参构造方法来显示指定使用策略。
公平策略类似FIFO，能保证等待时间最长的线程先执行。非公平策略不能保证这一点。

加锁(lock、tryLock)

执行lock方法调用链如下，根据初始化时指定的策略调用FairSync.lock或NoneFairSync.lock

公平锁

lock()方法调用acquire(int arg)方法实现加锁，在其爷爷类AQS中实现如下：

首先调用tryAcquire(int arg)方法尝试获取锁，如果获取锁失败把当前线程加入同步队列，最后执行selfInterrupt()中断当前线程执行。

1. 使用AQS的tryAcquire(int arg)尝试获取锁，该方法由子类重写覆盖，实际执行的是上图公平锁的tryAcquire(int acquires)方法。如下
   

A. getState()方法获取线程状态(是否持有锁)，如果没有获取锁（c==0），执行b，否则执行c。(AQS用state变量标识线程的状态，每次获取锁会对state加1，0表示没有线程持有锁。)
B. 如果没有比当前线程等待更长时间的线程，尝试使用CAS操作修改state状态用来标识当前线程已经获取锁，如果前两步都成功，则修改AQS持有线程为当前线程。
C. state不为零，说明当前线程已经持有锁，则利用CAS操作对state加acquires。这里体现了锁的可重入性。即：如果当前线程已经持有锁，再次请求锁会对state进行加1，state的值就代表线程获取锁的次数。每次释放对其进行减1，直到state为0锁才真正被释放掉。

1. 如果获取锁失败则执行acquireQueued(addWaiter(Node.EXCLUSIVE), arg)把线程加入同步队列，并不断轮询队列，直到队列头结点获取锁成功。
   

2. 如果线程获取锁失败(第1步)，并且当前线程应该被阻断，则执行selfInterrupt()阻断线程执行。

   非公平锁
   

非公平锁与公平锁类似，实现相对简单。它不用关心是否有线程比当前线程等待时间更长，采用抢占式的方式执行，因此执行效率会更高一些。

1. 直接用CAS操作对state变量进行修改，如果修改成功则设置持有锁的线程为当前线程。这里设计的很巧妙，假设当前线程没有获取锁直接用compareAndSetState(0, 1)进行修改state值，而不是先获取state值，再进行一系列的操作进行修改state。由于锁重入的情况相对较少，这么设计有效的提高执行效率。
2. 如果获取锁失败，则执行acquire(int arg)进行加锁，调用过程类似公平锁，tryAcquire(int arg)方法实际调用的是此处的tryAcquire(int acquires)方法，nofairTryAcquire方法在父类Sync中实现，相比公平锁的tryAcquire方法，少了hasQueuedPredecessors()方法判断是否有线程比当前线程等待时间更长。
   

释放锁(unlock)
解锁调用过程如下

1. 调用tryRelease(int relaese)方法释放锁，修改锁信息。从图中可以看到只有state的值为0时，才真正执行setExclusiveOwnerThread(null)释放锁。
2. 如果释放锁成功，执行unparkSuccessor(Node node)唤醒下一个节点。代码如下：
   

等待(await)
上文提到，ReentrantLock是借助AQS的ConditionObject队列实现的线程通信。

• 执行await()方法，线程阻塞并加入ConditionObject队列

• 执行signal()方法，唤醒线程阻塞线程出队列。

  下面是ConditionObject.await()方法的实现
  

  1. 把当前线程加入阻塞队列
  2. 如果当前线程不在同步队列中(说明该线程已经从同步队列出队，正在CPU上执行)，则不断尝试执行LockSupport.park(this)挂起该线程。

唤醒(signal)

1. singal()和signalAll()方法类似notify和notifyAll方法。singal()方法只是使阻塞队列的第一个节点出队，而singalAll()则是所有节点都出队。
2. 出队的节点执行transferForSingal(Node node)方法进行唤醒，并加入同步队列。
   

总结

1. ReentrantLock提供公平锁和非公平锁两种加锁策略，非公平锁的执行效率比公平锁高。
2. 线程获取锁(lock)成功会继续执行，失败则被加入同步队列。
3. 线程间的通信是通过ConditionObject实现的，执行await线程入队，singal、singalAll线程出队。