前言
以前只知道ReentrantLock底层基于AQS实现，相对于（旧版本的）synchronized：
更轻量（基于CAS而不是管程），由JDK实现
可以实现公平/非公平
可中断等待
可绑定多个条件，以选择性地通知其他进程解除等待。
那在我们分析ReentrantLock源码之前，首先了解一下ReentrantLock的工作流程：
此图转载自https://blog.csdn.net/qq_27184497
然后看一下上述features是如何实现的。
类定义、构造
public class ReentrantLock implements Lock, java.io.Serializable {
private static final long serialVersionUID = 7373984872572414699L;
/** Synchronizer providing all implementation mechanics */
private final Sync sync;
abstract static class Sync extends AbstractQueuedSynchronizer {
主要实现了Lock接口，规范了一个lock应当具有的基本功能：上锁、解锁、tryLock等。
并且有一个内部抽象类和属性Sync继承自AQS。
构造函数：
public ReentrantLock() {sync = new NonfairSync();}
public ReentrantLock(boolean fair) {sync = fair ? new FairSync() : new NonfairSync();}
默认实现非公平锁，可指定实现公平锁。公平/非公平锁的大部分方法都相同，不同的方法在Sync类中定义为抽象方法，由公平/非公平两个子类实现，我们先以非公平锁的实现为例，一会再对比非公平锁。
去看看ReentrantLock主要使用流程的方法们是怎样的。
Lock方法：
public void lock() {sync.lock();}
调用了sync的方法，继续深入：
final void lock() {
if (!initialTryLock())
acquire(1);
}
看一下initialTryLock方法：
final boolean initialTryLock() {
Thread current = Thread.currentThread();
if (compareAndSetState(0, 1)) { // first attempt is unguarded
setExclusiveOwnerThread(current);
return true;
} else if (getExclusiveOwnerThread() == current) {
int c = getState() + 1;
if (c < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(c);
return true;
} else
return false;
}
首先创建一个线程Thread，然后尝试SetState，
如果成功，将该线程设为独占线程（此方法来自于AQS）
如果失败，那么获取当前独占线程是否为这个current，我理解这里是考虑到可重入场景。（这里state相关函数都是AQS的方法，改天再开一篇博客详解AQS）在这个可重入场景下，变量c的逻辑是为了保证重入多少次，就要unlock多少次。
如果当前独占线程不是这个current，说明上锁失败。
在lock方法中，若该方法return false，则进入acquire(1)，
public final void acquire(int arg) {
if (!tryAcquire(arg))
acquire(null, arg, false, false, false, 0L);
}
里面有很多很多参数的这个方法是AQS的方法，公平/非公平、等待时长、中断等最终都是这个方法实现，只不过他们的tryAcquire方法不一样，对于非公平锁而言大概就是自旋不断CAS尝试获取，这是公平/非公平的主要区别，公平锁会进入等待队列，而非公平直接自旋抢占。
lockInterruptibly()方法，可被中断地上锁，和Lock方法基本类似：
final void lockInterruptibly() throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
if (!initialTryLock())
acquireInterruptibly(1);
}
public final void acquireInterruptibly(int arg)
throws InterruptedException {
if (Thread.interrupted() ||
(!tryAcquire(arg) && acquire(null, arg, false, true, false, 0L) < 0))
throw new InterruptedException();
}
下面这个方法来自AQS。如果获取锁之前就中断，那么直接抛出InterruptedException异常。
如果获取锁失败，那么和Lock方法的区别就是自旋前会调用Thread.interrupted()方法，确认当前线程是否被调用了interrupt，如果中断，那么抛出InterruptedException。
基本逻辑就是若两个线程都使用lockInterruptibly获取锁，如果线程A获取到了锁，线程B只能等待，对线程B调用interrupt()方法能够中断线程B的等待过程
tryLock方法：
同样来自于内部的Sync类，tryLock方法有两个，第一个和Lock方法调用的initialTryLock方法基本一样，唯一的区别就是这个方法首先会获取状态，而不是一上来直接CAS尝试获取锁，这里不做分析了，第二个是带等待时长参数的，我们直接进去看：
final boolean tryLockNanos(long nanos) throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
return initialTryLock() || tryAcquireNanos(1, nanos);
}
return的左值很好理解，就是没有经过时长等待就获取到了锁，根据||的短路效应，就没有必要进入右边了。
而右边又是一个AQS方法：
public final boolean tryAcquireNanos(int arg, long nanosTimeout)
throws InterruptedException {
if (!Thread.interrupted()) {
if (tryAcquire(arg))
return true;
if (nanosTimeout <= 0L)
return false;
int stat = acquire(null, arg, false, true, true,
System.nanoTime() + nanosTimeout);
if (stat > 0)
return true;
if (stat == 0)
return false;
}
throw new InterruptedException();
}
大概就是如果在等待时长（nanos参数）内获取到了锁，那么就返回true，如果超时了，那么放弃，返回false。
Unlock方法：
直接调用了AQS的release方法，其中arg是1：
public final boolean release(int arg) {
if (tryRelease(arg)) {
signalNext(head);
return true;
}
return false;
}
signalNext方法是唤醒等待队列中的队头线程，当然了只有公平锁有等待队列。
这个tryRelease方法在AQS中是个钩子方法，也就是交由Sync类实现，我们看一下：
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (getExclusiveOwnerThread() != Thread.currentThread())
throw new IllegalMonitorStateException();
boolean free = (c == 0);
if (free)
setExclusiveOwnerThread(null);
setState(c);
return free;
}
首先计算释放后的重入值c，arg是1（所以releases就是1），因此c就是state-1，如果调用释放的线程不是当前工作线程，那么抛出异常。
如果可重入值在释放之后将要变为0，那么说明该锁不被任何线程持有，那么将该锁的独占线程设为null，然后更新可重入值。
Condition
Condition类似于Synchronized中notify，wait等等，只不过更加灵活，一个Lock可以有多个Condition来执行各不相同的条件。
具体用法可以参考这篇文章：
https://blog.csdn.net/wugemao/article/details/83900078
其底层原理不属于ReentrantLock范畴，待日后详解AQS时一并分析。
公平锁的区别：
这里以公平锁的Lock方法为例，其他方法实现公平的方式与之基本一致，公平/非公平锁的Lock方法用得是同一个，但实现不同：
public final void acquire(int arg) {
if (!tryAcquire(arg))
acquire(null, arg, false, false, false, 0L);
}
调用的initialTryLock方法一些区别：
final boolean initialTryLock() {
Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedThreads() && compareAndSetState(0, 1)) {
setExclusiveOwnerThread(current);
return true;
}
} else if (getExclusiveOwnerThread() == current) {
if (++c < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(c);
return true;
}
return false;
}
可以看到和非公平锁的initialTryLock方法主要区别就是条件里多加了一个“有排队中的线程”判断，这样只有在当前线程重入，或没有等待线程（等待队列为空）时，才会获取该锁。而公平锁等待队列的实现本就是AQS的核心，因此待日后详解AQS时一并分析。
彩蛋：UID的作用？
源码中有一个属性：
private static final long serialVersionUID = 7373984872572414699L;
这个东西好像也没见到哪个方法里使用了，那它是干什么的？
中文环境中没有查到。。知识盲区了，我理解，大概，类似一种摘要算法生成的code？请大佬解释。。
