ReentrantLock
1.是什么
Reetrantlock是一个可以重复获得锁的一个互斥锁，它的加锁与解锁都是需要手动执行，也可以多次加锁，同时它还可以指定是由公平锁还是非公平锁实现。
2.内部实现
构造方法：
public ReentrantLock() {
sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
由构造方法可知，reentrantlock是由公平锁和非公平锁实现的，而公平锁和非公平锁都是继承实现AQS（AbstractQueuedSynchronizer）的模板方法和底层原理得以实现
AbstractQueuedSynchronizer(AQS)
//节点元素node的构成：
volatile Node prev; //指向前一个结点的指针
volatile Node next; //指向后一个结点的指针
volatile Thread thread; //当前结点代表的线程
volatile int waitStatus; //等待状态
//AQS其他的数据结构
private volatile int state;//Reentratlock中表示锁被同一个线程重入的次数
private transient Thread exclusiveOwnerThread;//标识锁是由哪个线程拥有
这里的头指针的头结点表示当前获得这个锁的线程，后面的节点表示想要获得这个锁的线程。这是一个先进先出的同步队列，获取锁失败的线程将构造自己的节点并追加到队列的尾部，并且阻塞自己，而当线程释放锁之后，也将尝试唤醒后续节点中处于阻塞状态的线程。
AQS的底层结构式lock实现的重要基础，对于公平锁和非公平锁来说，只是方法执行逻辑不同。
非公平锁NonfairSync
继承Sync，实现了lock和tryAcquire方法
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
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;
}
lock方法是默认去用cas的方式去更新state和当前持有线程，如果AQS中state为0，也就是队列为空，那么设置state和当前线程就可以，如果不成功，就加入队列。
Reentratlock非公平锁的加锁流程
1.1，尝试获取锁首先获取AQS中state的值，如果为0，表示当前锁没有被任何线程持有，以cas的方式设置state的值，以获取锁，并设置exclusiveOwnerThread标识这个锁由哪个线程拥有
1.2 如果state值不为0，则看当前锁的持有线程是否是自己，如果是，就可以重入了，对state加1 就可以了，获取锁也成功，如果持有线程不是自己，返回失败，
2，线程获取锁失败以后，就会为当前线程创建一个新的节点，判断tail尾指针是否为空，如果为空，构建新的节点同时设置为首尾指针，如果不是也就是队列不为空，那么就要以尾插方式放入队列尾部。
//先将新建节点前置节点置为尾节点，然后以cas的方式更新tail指针，最后新建节点入队
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
3，将新建的节点入队后，进入一个死循环，只有新建节点的前节点是头节点并且自己获取锁成功以后，将头结点设置为自己以后才能跳出循环，否者的话就要，并将前置节点置为SIGNAL阻塞（调用LockSupport方法）当前线程。
4，随着队列不断的出队，后面的节点的前节点总会是头结点，而自己也会获得锁，那么他也会被唤醒。
ReentratLock的解锁过程
public void unlock() {
sync.release(1);
}
public final boolean release(int arg) {
if (tryRelease(arg)) {//将state减1，如果减1后为0，返回true
Node h = head;
//防止队列为空，唤醒前节点必须是阻塞的，而节点阻塞前要设置前节点为SIGNAL
if (h != null && h.waitStatus != 0)
//唤醒线程
unparkSuccessor(h);
return true;
}
return false;
}
private void unparkSuccessor(Node node) {
/*
* If status is negative (i.e., possibly needing signal) try
* to clear in anticipation of signalling. It is OK if this
* fails or if status is changed by waiting thread.
*/
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
/*
* Thread to unpark is held in successor, which is normally
* just the next node. But if cancelled or apparently null,
* traverse backwards from tail to find the actual
* non-cancelled successor.
*/
Node s = node.next;
if (s == null || s.waitStatus > 0) {
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
//从为节点开始遍历，找到离头节点最近且节点状态为SIGNAL的节点
}
if (s != null)
//使用LockSupport唤醒线程
LockSupport.unpark(s.thread);
}
当前线程将state值减1，减少为0后，就表示线程释放了锁，就要唤醒后继节点，使得他可以获得锁，而这个后继节点的状态waitStatus小于0时才可以被唤醒
公平锁FairSync
Reentratlock公平锁的加锁流程
final void lock() {
acquire(1);
}
/**
* Fair version of tryAcquire. Don't grant access unless
* recursive call or no waiters or is first.
*/
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
//相比较而言，公平锁的流程在cas更新state前多了一个判断队列中是否有更高优先级的节点
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;
}
相比较非公平锁来说首先
1，在lock方法中少了一步直接cas更新state的方法
2，在tryAcquire方法中加入了hasQueuedPredecessor判断
hasQueuedPredecessor判断如下
public final boolean hasQueuedPredecessors() {
// The correctness of this depends on head being initialized
// before tail and on head.next being accurate if the current
// thread is first in queue.
Node t = tail; // Read fields in reverse initialization order
Node h = head;
Node s;
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
这里的判断判断了两种情况
1，头节点的后续节点为空
2，AQS的持有锁线程不是当前线程
为第一种要判断呢？？因为当一个节点要加入队列时有三步：
- 待插入节点pre指针指向尾节点
- cas方式更新AQS尾指针
- 原尾节点的next指向新插入节点
第一个判断是为了排除前两步执行完成，但是第三步没完成的情况，也就是队列中除了头节点外，还有后续的第二个节点，它应该第二个获得锁，这种情况下，当前线程应该入队，等待锁。
第二个判断就是队列中有第二个节点且AQS持有锁的线程为其他线程
所以这个判断就是为了判断队列中是否有第二个节点，这个节点获取锁的优先级最高，应该让他先获得锁。
为什么要对第二节点做判断
由于底层实现为同步队列，队列也就是先进先出，越早进入队列的线程应该越先获得锁，这样才是公平合理的，但是在非公平模式下，我们知道它有两次cas方式去更新state值和更新AQS持有线程
- 在lock方法中首先就尝试去cas更新state值，更新成功的话，那么就获得锁成功
- 在nonfairTryAcquire方法中也有对state值cas方式去更新值的判断
那么这两次判断真的能获得锁吗？
在释放锁的流程中，线程将state更新为0，然后去唤醒后续节点，就是（LockSupport.unpark(s.thread)）找到符合条件的节点解锁。
这就是两步，那么在多线程条件下，第一步执行完之后，此时恰好另外一个线程进入，看到state值为0，那么就可直接获得锁，更新完state和AQS持有线程后，就获得了锁。而这时刚刚解锁完的节点去唤醒的节点获取state值时发现不为0，继续阻塞等待，这也就造成了不公平。等的时间长不如进来的时间巧。从流程来说就是如下
那么在公平锁模式下，只要有第二节点的存在，后面进行的线程就必须要加入队列，而不能直接去cas的方式更新state值，对于多线程来说就是按加入时间长短来获取锁，也就实现了公平。