1.诞生背景

在 Java5.0 之前，协调对共享对象的访问可以使用的机制只有 synchronized 和 volatile。我们知道 synchronized 关键字实现了内置锁，而 volatile 关键字保证了多线程的内存可见性。
在大多数情况下，这些机制都能很好地完成工作，但却无法实现一些更高级的功能，例如，无法中断一个正在等待获取锁的线程，无法实现限定时间的获取锁机制，无法实现非阻塞结构的加锁规则等。而这些更灵活的加锁机制通常都能够提供更好的活跃性或性能。
因此，在 Java5.0 中增加了一种新的机制：ReentrantLock。它实现了 Lock 接口，并提供了与 synchronized 相同的互斥性和内存可见性，它的底层是通过 AQS 来实现多线程同步的。与内置锁相比 ReentrantLock 不仅提供了更丰富的加锁机制，而且在性能上也不逊色于内置锁 (在以前的版本中甚至优于内置锁)。
说了 ReentrantLock 这么多的优点，那么下面我们就来揭开它的源码看看它的具体实现。

2.ReentrantLock和Synchronized比较

synchronized 关键字是 Java 提供的内置锁机制，其同步操作由底层 JVM 实现，而 ReentrantLock 是 java.util.concurrent 包提供的显式锁，其同步操作由 AQS 同步器提供支持。ReentrantLock 在加锁和内存上提供的语义与内置锁相同，此外它还提供了一些其他功能，包括定时的锁等待，可中断的锁等待，公平锁，以及实现非块结构的加锁。另外，在早期的 JDK 版本中 ReentrantLock 在性能上还占有一定的优势，既然 ReentrantLock 拥有这么多优势，为什么还要使用 synchronized 关键字呢？

事实上确实有许多人使用 ReentrantLock 来替代 synchronized 关键字的加锁操作。但是内置锁仍然有它特有的优势，内置锁为许多开发人员所熟悉，使用方式也更加的简洁紧凑，因为显式锁必须手动在 finally 块中调用 unlock，所以使用内置锁相对来说会更加安全些。同时未来更加可能会去提升 synchronized 而不是 ReentrantLock 的性能。

因为 synchronized 是 JVM 的内置属性，它能执行一些优化，例如对线程封闭的锁对象的锁消除优化，通过增加锁的粒度来消除内置锁的同步，而如果通过基于类库的锁来实现这些功能，则可能性不大。所以当需要一些高级功能时才应该使用 ReentrantLock，这些功能包括：可定时的，可轮询的与可中断的锁获取操作，公平队列，以及非块结构的锁。否则，还是应该优先使用 synchronized。

3.获取锁和释放锁的操作

首先使用ReentrantLook 加锁示例代码

  1. public void doSomething() {
  2.    //默认是获取一个非公平锁
  3.    ReentrantLock lock = new ReentrantLock();
  4.    try{
  5.        //执行前先加锁
  6.        lock.lock();
  7.        //业务操作...
  8.    }finally{
  9.        //最后释放锁
  10.        lock.unlock();
  11.    }
  12. }

打开ReentrantLock源代码，摘取加锁和释放锁的部分代码

  1. private final ReentrantLock.Sync sync;
  2. //获取锁的操作
  3. public void lock() {
  4.    sync.lock();
  5. }
  6. //释放锁的操作
  7. public void unlock() {
  8.    sync.release(1);
  9. }

在ReentrantLock中的加锁和释放锁的方法中将加锁和释放锁的操作委托给了Sync对的的lock()和release()

  1. publicclass ReentrantLock implements Lock, java.io.Serializable {
  3.    privatefinal Sync sync;
  5.    abstractstaticclass Sync extends AbstractQueuedSynchronizer {
  6.        abstract void lock();
  7.    }
  9.    //实现非公平锁的同步器
  10.    staticfinalclass NonfairSync extends Sync {
  11.        final void lock() {
  12.            ...
  13.        }
  14.    }
  16.    //实现公平锁的同步器
  17.    staticfinalclass FairSync extends Sync {
  18.        final void lock() {
  19.            ...
  20.        }
  21.    }
  22. }

每个 ReentrantLock 对象都持有一个 Sync 类型的引用，这个 Sync 类是一个抽象内部类它继承自 AbstractQueuedSynchronizer，它里面的 lock 方法是一个抽象方法。ReentrantLock 的成员变量 sync 是在构造时赋值的，下面我们看看 ReentrantLock 的两个构造方法都做了些什么操作

  1. //默认无参构造器
  2. public ReentrantLock() {
  3.    sync = new NonfairSync();
  4. }
  6. //有参构造器
  7. public ReentrantLock(boolean fair) {
  8.    sync = fair ? new FairSync() : new NonfairSync();
  9. }

调用默认无参构造器会将 NonfairSync 实例赋值给 sync，此时锁是非公平锁。有参构造器允许通过参数来指定是将 FairSync 实例还是 NonfairSync 实例赋值给 sync。NonfairSync 和 FairSync 都是继承自 Sync 类并重写了 lock () 方法，所以公平锁和非公平锁在获取锁的方式上有些区别，这个我们下面会讲到。

再来看看释放锁的操作，每次调用 unlock () 方法都只是去执行 sync.release (1) 操作，这步操作会调用 AbstractQueuedSynchronizer 类的 release () 方法，我们再来回顾一下。

  1. //释放锁的操作(独占模式)
  2. public final boolean release(int arg) {
  3.    //拨动密码锁, 看看是否能够开锁
  4.    if (tryRelease(arg)) {
  5.        //获取head结点
  6.        Node h = head;
  7.        //如果head结点不为空并且等待状态不等于0就去唤醒后继结点
  8.        if (h != null && h.waitStatus != 0) {
  9.            //唤醒后继结点
  10.            unparkSuccessor(h);
  11.        }
  12.        returntrue;
  13.    }
  14.    returnfalse;
  15. }

这个 release 方法是 AQS 提供的释放锁操作的 API，它首先会去调用 tryRelease 方法去尝试获取锁，tryRelease 方法是抽象方法，它的实现逻辑在子类 Sync 里面。因为公平锁和非公平锁都继承至Sync抽象类，所以公平锁和非公平锁的释放逻辑是一样的。

  1. //尝试释放锁
  2. protected final boolean tryRelease(int releases) {
  3.    int c = getState() - releases;
  4.    //如果持有锁的线程不是当前线程就抛出异常
  5.    if (Thread.currentThread() != getExclusiveOwnerThread()) {
  6.        thrownew IllegalMonitorStateException();
  7.    }
  8.    boolean free = false;
  9.    //如果同步状态为0则表明锁被释放
  10.    if (c == 0) {
  11.        //设置锁被释放的标志为真
  12.        free = true;
  13.        //设置占用线程为空
  14.        setExclusiveOwnerThread(null);
  15.    }
  16.    // 如果同步状态不为0，表示当前线程还持有锁，重新复制同步状态的值
  17.    setState(c);
  18.    return free;
  19. }

这个 tryRelease 方法首先会获取当前同步状态，并将当前同步状态减去传入的参数值得到新的同步状态，然后判断新的同步状态是否等于 0，如果等于 0 则表明当前锁被释放，然后先将锁的释放状态置为真，再将当前占有锁的线程清空，最后调用 setState 方法设置新的同步状态并返回锁的释放状态

4. 源码分析

4.1. 公平锁和非公平锁

ReentrantLock 是公平锁还是非公平锁是基于 Sync 指向的是哪个具体实例 ，NonfairSync是非公平锁，FairSync是公平锁， 如果是公平锁，线程将按照它们发出请求的顺序来获得锁，但在非公平锁上，则允许插队行为 。当一个线程请求非公平的锁时，如果在发出请求的同时该锁的状态变为可用，那么这个线程将跳过队列中所有等待的线程直接获得这个锁

4.1.1. 非公平锁的获取方式

  1. //非公平同步器
  2. static final class NonfairSync extends Sync {
  3.    //实现父类的抽象获取锁的方法
  4.    final void lock() {
  5.        //使用CAS方式设置同步状态
  6.        if (compareAndSetState(0, 1)) {
  7.            //如果设置成功则表明锁没被占用，将当前线程设置为持有锁的线程
  8.            setExclusiveOwnerThread(Thread.currentThread());
  9.        } else {
  10.            //否则表明锁已经被占用, 调用acquire让线程去同步队列排队获取
  11.            acquire(1);
  12.        }
  13.    }
  14.    //尝试获取锁的方法
  15.    protected final boolean tryAcquire(int acquires) {
  16.        return nonfairTryAcquire(acquires);
  17.    }
  18. }
  20. //以不可中断模式获取锁(独占模式)
  21. public final void acquire(int arg) {
  22.    if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) {
  23.        selfInterrupt();
  24.    }
  25. }

可以看到在非公平锁的 lock 方法中，线程第一步就会以 CAS 方式将同步状态的值从 0 改为 1。其实这步操作就等于去尝试获取锁，如果更改成功则表明线程刚来就获取了锁，而不必再去同步队列里面排队了，成功获取锁后将当前线程设置为持有锁的线程。如果更改失败则表明线程刚来时锁还未被释放，所以接下来就调用 acquire 方法。

这个 acquire 方法是继承自 AbstractQueuedSynchronizer 的方法，现在再来回顾一下该方法，线程进入 acquire 方法后首先去调用 tryAcquire 方法尝试去获取锁，由于 NonfairSync 覆盖了 tryAcquire 方法，并在方法中调用了父类 Sync 的 nonfairTryAcquire 方法，所以这里会调用到 nonfairTryAcquire 方法去尝试获取锁。我们看看这个方法具体做了些什么。

  1. //非公平的获取锁
  2. final boolean nonfairTryAcquire(int acquires) {
  3.    //获取当前线程
  4.    final Thread current = Thread.currentThread();
  5.    //获取当前同步状态
  6.    int c = getState();
  7.    //如果同步状态为0则表明锁没有被占用
  8.    if (c == 0) {
  9.        //使用CAS更新同步状态
  10.        if (compareAndSetState(0, acquires)) {
  11.            //设置目前占用锁的线程
  12.            setExclusiveOwnerThread(current);
  13.            returntrue;
  14.        }
  15.    //否则的话就判断持有锁的是否是当前线程
  16.    } else if (current == getExclusiveOwnerThread()) {
  17.        //如果锁是被当前线程持有的, 就直接修改当前同步状态
  18.        int nextc = c + acquires;
  19.        if (nextc < 0) {
  20.            thrownew Error("Maximum lock count exceeded");
  21.        }
  22.        setState(nextc);
  23.        return true;
  24.    }
  25.    //如果持有锁的不是当前线程则返回失败标志
  26.    return false;
  27. }

nonfairTryAcquire 方法是 Sync 的方法，我们可以看到线程进入此方法后首先去获取同步状态，如果同步状态为 0 就使用 CAS 操作更改同步状态，其实这又是获取了一遍锁。如果同步状态不为 0 表明锁被占用，此时会先去判断持有锁的线程是否是当前线程，如果是的话就将同步状态加 acquires（acquires变量的值为1），否则的话这次尝试获取锁的操作宣告失败抛出异常。于是会调用 addWaiter 方法将线程添加到同步队列

从上面代码分析得出，在非公平锁的模式下一个线程在进入同步队列之前会尝试获取两遍锁，如果获取成功则不进入同步队列排队，否则才进入同步队列排队。接下来我们看看公平锁的获取方式。

4.1.2. 公平锁的获取方式

  1. //实现公平锁的同步器
  2. static finalclass FairSync extends Sync {
  3.    //实现父类的抽象获取锁的方法
  4.    final void lock() {
  5.        //调用acquire让线程去同步队列排队获取，这里会调用tryAcquire()方法
  6.        acquire(1);
  7.    }
  8.    //尝试获取锁的方法
  9.    protected final boolean tryAcquire(int acquires) {
  10.        //获取当前线程
  11.        final Thread current = Thread.currentThread();
  12.        //获取当前同步状态
  13.        int c = getState();
  14.        //如果同步状态0则表示锁没被占用
  15.        if (c == 0) {
  16.            //判断同步队列是否有前继结点
  17.            //这里是公平锁的关键
  18.            //校验队列中是否有等待线程去上锁，没有时才会让当前线程上锁
  19.            if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) {
  20.                //如果没有前继结点且设置同步状态成功就表示获取锁成功
  21.                setExclusiveOwnerThread(current);
  22.                returntrue;
  23.            }
  24.        //否则判断是否是当前线程持有锁
  25.        }else if (current == getExclusiveOwnerThread()) {
  26.            //如果是当前线程持有锁就直接修改同步状态
  27.            int nextc = c + acquires;
  28.            if (nextc < 0) {
  29.                thrownew Error("Maximum lock count exceeded");
  30.            }
  31.            setState(nextc);
  32.            return true;
  33.        }
  34.        //如果不是当前线程持有锁则获取失败
  35.        return false;
  36.    }
  37. }

调用公平锁的 lock 方法时会直接调用 acquire 方法。同样的，acquire 方法首先会调用 FairSync 重写的 tryAcquire 方法来尝试获取锁。在该方法中也是首先获取同步状态的值，如果同步状态为 0 则表明此时锁刚好被释放，这时和非公平锁不同的是它会先去调用 hasQueuedPredecessors 方法查询同步队列中是否有人在排队，如果没人在排队才会去修改同步状态的值，可以看到公平锁在这里采取礼让的方式而不是自己马上去获取锁

除了这一步和非公平锁不一样之外，其他的操作都是一样的。综上所述，可以看到公平锁在进入同步队列之前只检查了一遍锁的状态，即使是发现了锁是开的也不会自己马上去获取，而是先让同步队列中的线程先获取，所以可以保证在公平锁下所有线程获取锁的顺序都是先来后到的，这也保证了获取锁的公平性

那么我们为什么不希望所有锁都是公平的呢？毕竟公平是一种好的行为，而不公平是一种不好的行为。由于线程的挂起和唤醒操作存在较大的开销而影响系统性能，特别是在竞争激烈的情况下公平锁将导致线程频繁的挂起和唤醒操作，而非公平锁可以减少这样的操作，所以在性能上将会优于公平锁

另外，由于大部分线程使用锁的时间都是非常短暂的，而线程的唤醒操作会存在延时情况，有可能在 A 线程被唤醒期间 B 线程马上获取了锁并使用完释放了锁，这就导致了双赢的局面，A 线程获取锁的时刻并没有推迟，但 B 线程提前使用了锁，并且吞吐量也获得了提高

4.2. 条件队列的实现机制

内置条件队列存在一些缺陷，每个内置锁都只能有一个相关联的条件队列，这导致多个线程可能在同一个条件队列上等待不同的条件谓词，那么每次调用 notifyAll 时都会将所有等待的线程唤醒，当线程醒来后发现并不是自己等待的条件谓词，转而又会被挂起。这导致做了很多无用的线程唤醒和挂起操作，而这些操作将会大量浪费系统资源，降低系统的性能。如果想编写一个带有多个条件谓词的并发对象，或者想获得除了条件队列可见性之外的更多控制权，就需要使用显式的 Lock 和 Condition 而不是内置锁和条件队列。一个 Condition 和一个 Lock 关联在一起，就像一个条件队列和一个内置锁相关联一样。要创建一个 Condition，可以在相关联的 Lock 上调用 Lock.newCondition 方法。

4.2.1. 条件队列的使用

使用条件队列的示例

  1. publicclass BoundedBuffer {
  3.    final Lock lock = new ReentrantLock();
  4.    final Condition notFull = lock.newCondition();   //条件谓词：notFull
  5.    final Condition notEmpty = lock.newCondition();  //条件谓词：notEmpty
  6.    final Object[] items = new Object[100];
  7.    int putptr, takeptr, count;
  9.    //生产方法
  10.    public void put(Object x) throws InterruptedException {
  11.        lock.lock();
  12.        try {
  13.            while (count == items.length)
  14.                notFull.await();  //队列已满, 线程在notFull队列上等待
  15.            items[putptr] = x;
  16.            if (++putptr == items.length) putptr = 0;
  17.            ++count;
  18.            notEmpty.signal(); //生产成功, 唤醒notEmpty队列的结点
  19.        } finally {
  20.            lock.unlock();
  21.        }
  22.    }
  24.    //消费方法
  25.    public Object take() throws InterruptedException {
  26.        lock.lock();
  27.        try {
  28.            while (count == 0)
  29.                notEmpty.await(); //队列为空, 线程在notEmpty队列上等待
  30.            Object x = items[takeptr];
  31.            if (++takeptr == items.length) takeptr = 0;
  32.            --count;
  33.            notFull.signal();  //消费成功, 唤醒notFull队列的结点
  34.            return x;
  35.        } finally {
  36.            lock.unlock();
  37.        }
  38.    }
  40. }

一个 lock 对象可以产生多个条件队列，这里产生了两个条件队列 notFull 和 notEmpty。当容器已满时再调用 put 方法的线程需要进行阻塞，等待条件谓词为真 (容器不满) 才醒来继续执行；当容器为空时再调用 take 方法的线程也需要阻塞，等待条件谓词为真 (容器不空) 才醒来继续执行

这两类线程是根据不同的条件谓词进行等待的，所以它们会进入两个不同的条件队列中阻塞，等到合适时机再通过调用 Condition 对象上的 API 进行唤醒。

4.2.2. 条件队列源码

  1. //创建条件队列
  2. public Condition newCondition() {
  3.    return sync.newCondition();
  4. }
  6. abstractstaticclass Sync extends AbstractQueuedSynchronizer {
  7.    //新建Condition对象
  8.    final ConditionObject newCondition() {
  9.        return new ConditionObject();
  10.    }
  11. }

ReentrantLock 上的条件队列的实现都是基于 AbstractQueuedSynchronizer 的，我们在调用 newCondition 方法时所获得的 Condition 对象就是 AQS 的内部类 ConditionObject 的实例。所有对条件队列的操作都是通过调用 ConditionObject 对外提供的 API 来完成的