ReentrantLock详解
本文导航：
- 获取锁
- 释放锁
- 公平锁与非公平锁
- ReentrantLock 与 synchronized 的区别
- 参考资料
ReentrantLock，JUC提供的可重入锁，是一种递归无阻塞的同步机制。
它可以等同于 synchronized 的使用，但是提供了比 synchronized 更强大、更灵活的锁机制。可以减少死锁发生的概率。
API介绍如下（ReentrantLock类注释）：
一个可重入的互斥锁，具有与使用 synchronized 方法和语句所访问的隐式监视器锁定相同的基本行为和语义，但是拥有更多的扩展功能。
ReentrantLock 将由最近成功获得锁的，并且还诶有释放该锁的线程所拥有。当该锁没有被另一个线程拥有时，调用lock的线程将成功获取该锁定并返回。当前线程有用该锁时，调用lock方法将会立即返回。
可以使用 isHeloByCurrentThread() 和 getHoldCount() 来进行线程检查
Reentrant还提供了 公平锁 与 非公平锁。
构造方法支持一个可选参数，表示创建的锁是否是公平锁。（默认的无参构造器是非公平锁）
这两者的区别在于，公平锁的的获取是有序的。但是公平锁的效率往往要比非公平锁低。在多线程的情况下，公平锁的吞吐量较低。
类的结构关系：
锁的初始化
ReentrantLock的大部分逻辑是靠内部类Sync来实现的。
在初始化时，会设置当前锁的类型。
源码如下：
/** Synchronizer providing all implementation mechanics */
private final Sync sync;
public ReentrantLock() {
sync = new NonfairSync(); // 默认是非公平锁
}
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
获取锁
我们一般使用ReentrantLock时，是这这样获取锁的：
// 非公平锁
ReentrantLock myLock = new ReentrantLock();
myLock.lock();
在源码层面，其实还是调用了内部类Sync 或者 AQS的方法，这个在下面会讲到。
ReentrantLock获取锁的几种方式：
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));
}
获取锁的方法介绍
lock()
最简单的获取锁方式，尝试获取锁。
1）如果当前锁没有被其他线程持有，则当前线程会立即获取锁并返回，并且设置lock count 为1。
2）如果当前线程已经持有该锁，那么会激励返回，并且 lock count +1。
3）如果锁被其他线程持有，则当前线程在线程调度的状态会变成不可用，然后会被设置为休眠状态，直到线程获取到锁，在获取锁的同时 lock count 置为1。
lockInterruptibly() throws InterruptedException
整体逻辑和lock() 一样，但是该锁是可以被打断的，被打断后，会抛出 InterruptedException。
tryLock()
非阻塞的获取锁。
只有在当前锁没有被其他线程持有的时候，才会获取锁并且马上返回true。
否则会返回false。
源码可以看到，该方法的底层是直接调用的nonfairTryAcquire(1)。
所以说，不管当前重入锁声明的是什么策略，都不会影响该方法的行为。
PS：如果想使用公平锁的策略，并且使用非阻塞的tryLock()，那么可以使用下面的带有过期时间的 tryLock();
tryLock(long timeout, TimeUnit unit) throws InterruptedException
有过期时间的 tryLock()。
在指定时间之内没有获取到锁的话，就会返回false。
在这个时间内获取锁的策略，是支持公平和非公平的。
【需要注意的是】：如果使用的是公平锁的策略，那么即使该锁当前是可用的，也会在队列后面排队。（也就是公平锁策略，排队等待，而不是抢占式）
释放锁只有一个方法：unlock()，方法实现也是调用了Sync内部类提供的方法。
每次调用该方法 lock count 都会减1，如果count减到0，则锁会释放。
源码如下：
public void unlock() {
sync.release(1);
}
内部类Sync
这是ReentrantLock 实现锁的关键，所有锁的原理基本都在这个内部类以及AQS中。
Sync是ReentrantLock的一个内部类，它继承AQS（AbstractQueuedSynchronizer），它有两个子类，分别实现了公平锁和费公平锁：FairSync 和 NonfairSync。
以下是源码：
静态内部类Sync
abstract static class Sync extends AbstractQueuedSynchronizer {
/**
* Performs {@link Lock#lock}. The main reason for subclassing
* is to allow fast path for nonfair version.
*/
abstract void lock();
/**
* Performs non-fair tryLock. tryAcquire is implemented in
* subclasses, but both need nonfair try for trylock method.
*/
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread(); // 获取当前线程
int c = getState(); // 获取当前AQS的线程状态
if (c == 0) { // 如果状态为0，即当前没有线程拿到锁。
// 那么就尝试使用CAS来抢占锁。
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;
}
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;
}
protected final boolean isHeldExclusively() {
// While we must in general read state before owner,
// we don't need to do so to check if current thread is owner
return getExclusiveOwnerThread() == Thread.currentThread();
}
final ConditionObject newCondition() {
return new ConditionObject();
}
// Methods relayed from outer class
final Thread getOwner() {
return getState() == 0 ? null : getExclusiveOwnerThread();
}
final int getHoldCount() {
return isHeldExclusively() ? getState() : 0;
}
final boolean isLocked() {