ReentrantLock的具体实现细节是什么
在 JDK 1.5 之前共享对象的协调机制只有 synchronized 和 volatile，在 JDK 1.5 中增加了新的机制 ReentrantLock，该机制的诞生并不是为了替代 synchronized，而是在 synchronized 不适用的情况下，提供一种可以选择的高级功能。
在 Java 中每个对象都隐式包含一个 monitor（监视器）对象，加锁的过程其实就是竞争 monitor 的过程，当线程进入字节码 monitorenter 指令之后，线程将持有 monitor 对象，执行 monitorexit 时释放 monitor 对象，当其他线程没有拿到 monitor 对象时，则需要阻塞等待获取该对象。
ReentrantLock 是 Lock 的默认实现方式之一，它是基于 AQS（Abstract Queued Synchronizer，队列同步器）实现的，它默认是通过非公平锁实现的，在它的内部有一个 state 的状态字段用于表示锁是否被占用，如果是 0 则表示锁未被占用，此时线程就可以把 state 改为 1，并成功获得锁，而其他未获得锁的线程只能去排队等待获取锁资源。
synchronized 和 ReentrantLock 都提供了锁的功能，具备互斥性和不可见性。在 JDK 1.5 中 synchronized 的性能远远低于 ReentrantLock，但在 JDK 1.6 之后 synchronized 的性能略低于 ReentrantLock。
1、Synchronized和ReentrantLock的区别
- synchronized 是 JVM 隐式实现的，而 ReentrantLock 是 Java 语言提供的 API；
- ReentrantLock 可设置为公平锁，而 synchronized 却不行；
- ReentrantLock 只能修饰代码块，而 synchronized 可以用于修饰方法、修饰代码块等；
- ReentrantLock 需要手动加锁和释放锁，如果忘记释放锁，则会造成资源被永久占用，而 synchronized 无需手动释放锁；
- ReentrantLock 可以知道是否成功获得了锁，而 synchronized 却不行
2、ReentrantLock 的具体实现细节
从源码出发来解密 ReentrantLock 的具体实现细节，首先来看 ReentrantLock 的两个构造函数：
public ReentrantLock() {
sync = new NonfairSync(); // 非公平锁
}
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
无参的构造函数创建了一个非公平锁，用户也可以根据第二个构造函数，设置一个 boolean 类型的值，来决定是否使用公平锁来实现线程的调度。
- 公平锁 VS 非公平锁
公平锁的含义是线程需要按照请求的顺序来获得锁；而非公平锁则允许“插队”的情况存在，所谓的“插队”指的是，线程在发送请求的同时该锁的状态恰好变成了可用，那么此线程就可以跳过队列中所有排队的