带着疑问去分析
- ReentrantLock是如何实现锁管理的。
- ReentrantLock是如何实现重入的。
- ReentrantLock是如何实现公平锁与非公平锁。
- ReentantLock的公平锁为什么一般情况下性能都比公平锁查。
ReentrantLock数据结构
ReentrantLock的底层是借助于AbstractQueuedSynchronizer实现的，所以其数据结构依赖于AbstractQueuedSynchronizer的数据结构。
AQS的数据结构 如下图：
ReentrantLock源码分析
类的继承关系
public class ReentrantLock implements Lock, java.io.Serializable
说明：ReentrantLock实现了Lock接口，Lock接口中定义了lock与unlock操作，并且还存在newCondition方法，表示生成一个条件。
类的内部类
ReentrantLock总共有三个内部类，并且三个内部类是紧密相关的，下面先看三个类的关系：
说明：
- ReentrantLock类内部总共存在Sync、NonfairSync、FairSync三个类，NonfairSync与FairSync类继承Sync类，Sync类继承自AQS抽象类。
- ReentrantLock是通过构造方法实现公平锁与非公平锁定义的。
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
Sync类
Sync类源码如下：（只列出主要方法）
/**
* 获取锁 由于公平锁和非公平锁 获取锁的动作 不一样，所以留着让子类实现更好。
*/
abstract void lock();
/**
* 非公平模式下尝试获取锁。两种情况：
* 1. 锁没被占用：
* (1). CAS将当前锁状态加1
* (2). 将当前线程设置为锁的独享者。
* 2. 锁被占用
* (1). 如果锁占用者是当前线程 ，则将线程状态加+1 ，通过这个线程状态 就可以知道重入次数
*/
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;
}
/***
* 第一步：依次减去释放量(releases变量 这里都是1)，
* 第二步：如果全部释放(state)，则将锁占用者置为null，表示释放锁。
* @param releases
* @return
*/
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;
}
/**
* 判断当前线程是否是锁的拥有者
* @return
*/
protected final boolean isHeldExclusively() {
return getExclusiveOwnerThread() == Thread.currentThread();
}
/**
* 查看当前线程重入次数
* @return
*/
final int getHoldCount() {
return isHeldExclusively() ? getState() : 0;
}
/**
* 当前锁是否被占用
* @return
*/
final boolean isLocked() {
return getState() != 0;
}
说明：Sync类存在如下方法和作用如下。
NonfairSync类
NonfairSync类继承了Sync类，表示采用非公平策略获取锁，其实现了Sync类中抽象的lock方法，源码如下：
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
/**
* 1. 英文版 注释：
* Performs lock. Try immediate barge, backing up to normal
* acquire on failure.
*
* 我的谬论:
* barge 在英文中是: 蛮不讲理地闯入或打扰某事物 、闯入之意。( 用在此场景，个人感觉很好呀 ^_^ )
* 加锁过程：当一个线程调用lock方法时，直接尝试加锁，如果加锁失败，再进行正常的获取。
* 从这里可以看出 作者认为 ReentrantLock更多的时候，锁的争抢并不激烈，大多时候第一次的barge就能获取锁，所以作者才会首先进行barge，失败再尝试正常获取。
*/
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
/**
* lock 中的 acquire(1) 代码段可能会调用此方法 , 此方法的作用主要是为了 获取独占锁 , 获取失败的线程将会进入等待队列
* @param acquires
* @return
*/
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
}
说明: 从lock方法的源码可知，每一次都尝试获取锁，而并不会按照公平等待的原则进行等待，让等待时间最久的线程获得锁。
FairSync类
FairSync类也继承了Sync类，表示采用公平策略获取锁，其 实现了Sync类中的抽象lock方法，源码如下：
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
acquire(1);
}
/**
* 尝试获取独占锁. 两种情况:
* 1. 锁未被占用(state = 0 )
* 如果等待队列为空 或当前线程时等待队列首个出队线程 则尝试获取锁.
* 2. 锁被占用(state != 0)
* 校验当前线程是否已经拥有独占锁，如果是，则记录重入次数。
* @param acquires
* @return
*/
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
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;
}
}
说明：跟踪lock的源码可知，当一个线程尝试获取锁时，总是会首先判断sync队列（AbstractQueuedSynchronizer中的数据结构）是否有等待时间更长的线程。如果存在，则将线程加入到等待队列的尾部，实现了公平获取原则。这是和Nonfair最大的区别，Nonfair每一次都会尝试去获取资源，如果此时该资源恰好被释放，这就造成了不公平的现象，当获取不成功，再加入到队列尾部。
最后
我们可以通过下图来深刻的认识公平性和AQS的获取过程。
非公平的，或者说默认的获取方式如下图所示：
对于状态的获取，可以快速的通过tryAcquire的成功，也就是黄色的Fast路线，也可以由于tryAcquire的失败，构造节点，进入sync队列中排序后再次获取。因此可以理解为Fast就是一个快速通道，当例子中的线程释放锁之后，快速的通过Fast通道再次获取锁，就算当前sync队列中有排队等待的线程也会被忽略。这种模式，可以保证进入和退出锁的吞吐量，但是sync队列中过早排队的线程会一直处于阻塞状态，造成“饥饿”场景。
而公平锁，就是在tryAcquire的调用中顾及当前sync队列中的等待节点（废弃fast通道），也就是任意请求都需要按照sync队列中既有的顺序进行，先到先得。这样很好的确保了公平性。
回答之前的疑惑
- ReentrantLock是如何实现锁管理的。
加锁：
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
释放锁:
int c = getState() - releases;
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
state状态量的值如果大于0，则表示锁被占用，否则以CAS 乐观锁的形式将state赋值，从而表示锁被占用。释放锁的过程其实就是state递减为0的过程，此时不需要同步任何同步手段，是因为只有之前lock成功的线程才能调用unlock方法，所以无需任何同步手段。
2.ReentrantLock是如何实现重入的。
通过state的值记录重入次数，释放的时候也是通过state值递减来记录是否退出所有的重入。
3.ReentrantLock是如何实现公平锁与非公平锁？
是通过“barge”的形式，快速抢占，抢不到再遵守秩序排队。
4.ReentantLock的公平锁为什么一般情况下性能都比公平锁查。
在恢复一个被挂起的线程与该线程真正运行之间存在着严重的延迟。
假设线程A持有一个锁，并且线程B请求这个锁。由于所被A持有，因此B将被挂起。当A释放锁时，B将被唤醒，因此B会再次尝试获取这个锁。与此同时，如果线程C也请求这个锁，那么C很可能会在B被完全唤醒之前获得、使用以及释放这个锁。这样就是一个双赢的局面：B获得锁的时刻并没有推迟，C更早的获得了锁，做完了自己要做的事，并且吞吐量也提高了。
频繁的线程切换和线程唤醒睡眠动作将会消耗系统资源：
当一个线程尝试加锁的时候，如果发现锁被抢占，会睡眠等待唤醒再次尝试加锁。如果锁竞争比较激烈，会造成频繁的线程切换 线程睡眠与唤醒动作。
5.我们是否应该抛弃synchronized ？
虽然 ReentrantLock 是个非常动人的实现，相对 synchronized 来说，它有一些重要的优势，但是我认为急于把 synchronized 视若敝屣，绝对是个严重的错误。 java.util.concurrent.lock 中的锁定类是用于高级用户和高级情况的工具 。一般来说，除非您对 Lock 的某个高级特性有明确的需要，或者有明确的证据（而不是仅仅是怀疑）表明在特定情况下，同步已经成为可伸缩性的瓶颈，否则还是应当继续使用 synchronized。
为什么我在一个显然“更好的”实现的使用上主张保守呢？因为对于 java.util.concurrent.lock 中的锁定类来说，synchronized 仍然有一些优势。比如，在使用 synchronized 的时候，不能忘记释放锁；在退出 synchronized 块时，JVM 会为您做这件事。您很容易忘记用 finally 块释放锁，这对程序非常有害。您的程序能够通过测试，但会在实际工作中出现死锁，那时会很难指出原因（这也是为什么根本不让初级开发人员使用 Lock 的一个好理由。）
另一个原因是因为，当 JVM 用 synchronized 管理锁定请求和释放时，JVM 在生成线程转储时能够包括锁定信息。这些对调试非常有价值，因为它们能标识死锁或者其他异常行为的来源。 Lock 类只是普通的类，JVM 不知道具体哪个线程拥有 Lock 对象。而且，几乎每个开发人员都熟悉 synchronized，它可以在 JVM 的所有版本中工作。在 JDK 5.0 成为标准（从现在开始可能需要两年）之前，使用 Lock 类将意味着要利用的特性不是每个 JVM 都有的，而且不是每个开发人员都熟悉的。
6.什么时候选择用 ReentrantLock 代替 synchronized？
结构锁、多个条件变量或者锁投票。 ReentrantLock 还具有可伸缩性的好处，应当在高度争用的情况下使用它，但是请记住，大多数 synchronized 块几乎从来没有出现过争用，所以可以把高度争用放在一边。我建议用 synchronized 开发，直到确实证明 synchronized 不合适，而不要仅仅是假设如果使用 ReentrantLock “性能会更好”。请记住，这些是供高级用户使用的高级工具。（而且，真正的高级用户喜欢选择能够找到的最简单工具，直到他们认为简单的工具不适用为止。）。一如既往，首先要把事情做好，然后再考虑是不是有必要做得更快。
Lock 框架是同步的兼容替代品，它提供了 synchronized 没有提供的许多特性，它的实现在争用下提供了更好的性能。但是，这些明显存在的好处，还不足以成为用 ReentrantLock 代替 synchronized 的理由。相反，应当根据您是否 需要 ReentrantLock 的能力来作出选择。大多数情况下，您不应当选择它 —— synchronized 工作得很好，可以在所有 JVM 上工作，更多的开发人员了解它，而且不太容易出错。只有在真正需要 Lock 的时候才用它。在这些情况下，您会很高兴拥有这款工具。