ReentrantLock 重入锁实现了 Lock和 java.io.Serializable接口，并提供了与synchronized相同的互斥性和内存可见性，ReentrantLock 提供了可重入的加锁语义，能够对共享资源能够重复加锁，即当前线程获取该锁再次获取不会被阻塞。
可重入性：重入性是指任意线程在获取到锁之后能够再次获取该锁而不会被锁阻塞。所需要去识别获取锁的线程是否为当前占据锁的线程，如果是，则再次获取成功。锁的最终释放：线程重复n次获取了锁，随后在第n次释放该锁后，其它线程能够获取到该锁。锁的最终释放要求锁对于获取进行计数自增，计数表示当前线程被重复获取的次数，而被释放时，计数自减，当计数为0时表示锁已经成功释放。
ReentrantLock实现了 Lock和 Serializable接口，内部有三个内部类，Sync、NonfairSync、FairSync。
Sync 是一个抽象类型，它继承 AbstractQueuedSynchronizer，这个AbstractQueuedSynchronizer是一个模板类，它实现了许多和锁相关的功能，并提供了钩子方法供用户实现，比如 tryAcquire、tryRelease 等。Sync实现了AbstractQueuedSynchronizer的tryRelease方法。
NonfairSync和FairSync两个类继承自Sync，实现了lock方法，然后分别公平抢占和非公平抢占针对tryAcquire有不同的实现。
ReentrantLock的底层原理主要基于CAS（Compare and Swap，比较并交换）和AQS（AbstractQueuedSynchronizer，抽象队列同步器）实现。支持公平锁和非公平锁两种模式，默认采用非公平锁。
公平锁：公平锁确保线程按照请求锁的顺序来获取锁，先到达的线程将先获得锁，这有助于避免线程饥饿，即一个线程可能因为等待其他线程释放锁而长时间无法获得锁。
非公平锁：非公平锁允许新线程插队抢占锁，这可能导致某些线程等待较长时间才能获得锁，非公平锁的主要优势在于减少了线程上下文切换的开销，从而提高了整体的吞吐效率，但缺点是可能导致某些线程等待时间较长。
线程A、B、C在竞争锁的流程图-非公平锁
创建锁
// 默认是非公平锁
ReentrantLock lock = new ReentrantLock();
线程A执行业务加锁调用lock.lock()，state为0，CAS修改state=1，获取到了锁；
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
线程B调用lock.lock()，返回false，进入else方法acquire(1)，执行tryAcquire，最终执行nonfairTryAcquire，也返回false
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
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;
}
线程B加入队列等待
addWaiter(Node.EXCLUSIVE), arg)
线程A解锁
public void unlock() {
sync.release(1);
}
如果tryRelease方法返回true，等待队列中的头结点被唤醒
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head
// h.waitStatus!=0 说明前驱结点处于SIGNAL状态，表示下一个线程在等待其唤醒
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
设置 state = 0
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
// 通过判断当前线程是否为获得到锁的线程，保证该方法线程安全
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
// 只有当同步状态彻底释放后，该方法才会返回 true 。当 state == 0 时，则将锁持有线程设置为 null ，free= true，表示释放成功。
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
唤醒等待的头节点线程B
private void unparkSuccessor(Node node) {
// 前驱结点 waitStatus = -1
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
Node s = node.next;
if (s == null || s.waitStatus > 0) {
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
// 从后往前找到离head最近，而且waitStatus <= 0 的节点
if (t.waitStatus <= 0)
s = t;
}
// 唤醒线程
if (s != null)
LockSupport.unpark(s.thread);
}
线程B被唤醒后tryAcquire方法竞争锁
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor(); // 获得 node 前驱节点
if (p == head && tryAcquire(arg)) { // 如果 node 前驱节点是 head，再次尝试拿锁，调用 tryAcquire；
// 如果拿到锁，这里就是双向链表中的操作，head 节点出队
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) && // 获取锁失败，考虑是否要阻塞该线程
parkAndCheckInterrupt()) // 阻塞线程
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
同时线程C调用lock. lock()方法，最终，C线程CAS操作抢先拿到了锁，B线程获取锁失败，继续被阻塞等待锁；
线程A、B、C在竞争锁的流程图-公平锁
代码不同点，lock()方法，没有CAS插队获取锁
final void lock() {
acquire(1);
}
多了一个hasQueuedPredecessors()，该方法名称是：是否拥有前一个队列元素，换言之：用不用排队。返回false:不用排队，返回true:需要排队。
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;
}
public final boolean hasQueuedPredecessors() {
Node t = tail; //尾节点
Node h = head; //头节点
Node s;
// 1.头节点 != 尾节点 &&
// 2.同步队列第一个节点不为null || 3.当前线程是同步队列第一个节点
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
如果和上面流程一样情况下，线程C尝试获取锁，返回true，需要排队，而线程B在队首，会先试用锁。
公平锁和非公平锁的区别
锁的公平性是相对于获取锁的顺序而言的。
如果是一个公平锁，那么锁的获取顺序就应该符合请求的绝对时间顺序，也就是FIFO，线程获取锁的顺序和调用lock的顺序一样，能够保证老的线程排队使用锁，新线程仍然排队使用锁。
非公平锁只要CAS设置同步状态成功，则表示当前线程获取了锁，线程获取锁的顺序和调用lock的顺序无关，全凭运气，也就是老的线程排队使用锁，但是无法保证新线程抢占已经在排队的线程的锁。
ReentrantLock默认使用非公平锁是基于性能考虑，公平锁为了保证线程规规矩矩地排队，需要增加阻塞和唤醒的时间开销。如果直接插队获取非公平锁，跳过了对队列的处理，速度会更快。
