本文首发于微信公众号【WriteOnRead】，欢送关注。
1. 概述
在 JDK 1.5 以前，锁的实现只能用 synchronized 关键字；1.5 开始提供了 ReentrantLock，它是 API 层面的锁。先看下 ReentrantLock 的类签名以及如何应用：
public class ReentrantLock implements Lock, java.io.Serializable {}典型用法：
public void m() { lock.lock(); // block until condition holds try { // ... method body } finally { lock.unlock() }}该用法和应用 synchronized 关键字成果是一样的。既然有了 synchronized，为什么又会有 Lock 呢？相比于 synchronized，其实 ReentrantLock 的呈现并不反复，它减少了不少性能，上面先简略介绍几个概念：
- 偏心锁&非偏心锁
所谓锁是否偏心，简略了解就是一系列线程获取到锁的程序是否遵循「先来后到」。即，如果先申请锁的线程先获取到锁，就是偏心锁；否则就是非偏心锁。ReentrantLock 的默认实现和 synchronized 都是非偏心锁。
- 可重入锁
锁是否可重入，就是一个线程是否能够屡次获取同一个锁，若是，就是可重入锁。ReentrantLock 和 synchronized 都是可重入锁。
2. 代码剖析
2.1 结构器
ReentrantLock 有两个结构器，别离如下：
private final Sync sync;// 结构一个 ReentrantLock 实例（非偏心锁）public ReentrantLock() { sync = new NonfairSync();}// 结构一个 ReentrantLock 实例（指定是否偏心）public ReentrantLock(boolean fair) { sync = fair ? new FairSync() : new NonfairSync();}能够看到，两个结构器都是初始化一个 Sync 类型的成员变量。而且，当 boolean 值 fair 为 true 时，初始化的 sync 为 FairSync，为 false 时初始化为 NonFairSync，二者别离示意「偏心锁」和「非偏心锁」。能够看到无参结构默认是非偏心锁。
2.2 罕用办法
ReentrantLock 罕用的办法就是 Lock 接口定义的几个办法，如下：
// 获取锁（阻塞式）public void lock() { sync.lock();}// 获取锁（响应中断）public void lockInterruptibly() throws InterruptedException { sync.acquireInterruptibly(1);}// 尝试获取锁public boolean tryLock() { return sync.nonfairTryAcquire(1);}// 尝试获取锁（有超时期待）public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException { return sync.tryAcquireNanos(1, unit.toNanos(timeout));}// 开释锁public void unlock() { sync.release(1);}能够看到，这几个办法外部都是通过调用 Sync 类（或其子类）的办法来实现，因而先从 Sync 类动手剖析，代码如下（局部省略）：
// 抽象类，继承了 AQSabstract static class Sync extends AbstractQueuedSynchronizer { // 获取锁的办法，由子类实现 abstract void lock(); // 非偏心锁的 tryLock 办法实现 final boolean nonfairTryAcquire(int acquires) { final Thread current = Thread.currentThread(); // 获取 AQS 的 state 变量 int c = getState(); // 若为 0，示意以后没有被其余线程占用 if (c == 0) { // CAS 批改 state，若批改胜利，示意胜利获取资源 if (compareAndSetState(0, acquires)) { // 将以后线程设置为 owner，到这里示意以后线程胜利获取资源 setExclusiveOwnerThread(current); return true; } } // state 不为 0，且 owner 为以后线程 // 示意以后线程曾经获取到了资源，这里示意“重入” else if (current == getExclusiveOwnerThread()) { int nextc = c + acquires; if (nextc < 0) // overflow throw new Error("Maximum lock count exceeded"); // 批改 state 值（因为以后线程曾经获取资源，不存在竞争，因而无需 CAS 操作） setState(nextc); return true; } return false; } // 开释锁操作（对 state 做减法） 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; // 胜利开释后将 owner 设为空 setExclusiveOwnerThread(null); } // 批改 state 的值 // PS: 因为可能存在“重入”，因而一次开释操作后以后线程仍有可能占用资源， // 所以不会间接把 state 设为 0 setState(c); return free; } // 其余办法... final boolean isLocked() { return getState() != 0; }}Sync 类继承自 AQS，其中 nonfairTryAcquire 办法是非偏心锁 tryAcquire 办法的实现。
从下面代码能够看出，锁的获取和开释是通过批改 AQS 的 state 变量来实现的。lock 办法能够看做对 state 执行“加法”操作，而 unlock 能够看做对 state 执行“减法”操作，当 state 为 0 时，示意以后没有线程占用资源。
2.3 偏心锁&非偏心锁
2.3.1 非偏心锁 NonFairSync
static final class NonfairSync extends Sync { final void lock() { // CAS 尝试将 state 值批改为 1 if (compareAndSetState(0, 1)) // 若批改胜利，则将以后线程设为 owner，示意胜利获取锁 setExclusiveOwnerThread(Thread.currentThread()); // 若获取失败，则执行 AQS 的 acquire 办法（独占模式获取资源） else acquire(1); } protected final boolean tryAcquire(int acquires) { return nonfairTryAcquire(acquires); }}能够看到，非偏心锁的 lock 操作为：先尝试以 CAS 形式批改 state 的值，若批改胜利，则示意胜利获取到锁，将 owner 设为以后线程；否则就执行 AQS 中的 acquire 办法，具体可参考前文「JDK源码剖析-AbstractQueuedSynchronizer(2)」，这里不再赘述。
2.3.2 偏心锁 FairSync
static final class FairSync extends Sync { final void lock() { acquire(1); } // 偏心锁的 tryAcquire 实现 protected final boolean tryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); // state 为 0，示意资源未被占用 if (c == 0) { // 若队列中有其余线程在排队期待，则返回 false，示意获取失败； // 否则，再尝试去批改 state 的值 // PS: 这里是偏心锁与非偏心锁的区别所在 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，即首先判断主队列中是否有其余线程在期待，当没有其余线程在排队时再去获取，否则获取失败。
hasQueuedPredecessors 在 AQS 中实现如下：
/** * Queries whether any threads have been waiting to acquire longer * than the current thread. */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());}3. 小结
synchronized 与 ReentrantLock 比拟：
- 相同点：二者都是互斥锁，可重入，默认都是非偏心锁。
- 不同点：synchronized 是语法层面实现，主动获取锁和开释锁；ReentrantLock 是 API 层面实现，手动获取锁和开释锁。
ReentrantLock 相比 synchronized 的劣势：
- 可响应中断；
- 获取锁可设置超时；
- 可实现偏心锁；
- 可绑定多个条件（Condition）。
PS: JDK 1.6 当前，synchronized 与 ReentrantLock 性能根本持平，JVM 将来的性能优化也会更偏差于原生的 synchronized。因而，如何抉择还要依据理论需要，性能不再是不抉择 synchronized 的起因了。
相干浏览：
JDK源码剖析-Lock&Condition
JDK源码剖析-AbstractQueuedSynchronizer(2)