ReentrantLock重入锁
一，重入锁定义
重入锁，顾名思义，就是支持重新进入的锁，表示这个锁能够支持一个线程对资源重复加锁。如果一个线程已经拿到了锁，那么他需要再次获取锁的时候不会被该锁阻塞。
举个例子，
public synchronized void test(){
do something...
test2();
}
public synchronized void test2(){
do something;
}
test和test2都是同步方法，在执行之前都需要上锁，执行test获取到了锁，test里面调用test2,如果是重入锁，锁识别到获取锁的线程就是当前线程，那么直接进入。如果锁不支持重入，那么显然执行会阻塞在test2()这个位置。
当然，synchronized和ReentrantLock都是重入锁，均支持重新进入。
二，重入锁和非重入锁实现上的区别
上面算是理论，那么具体实现上如何支撑锁的重入性呢?
在队列同步器章节给出了Mutex锁的实现，这个Mutex就是一个非重入锁。
下面是他的代码逻辑，
import java.util.concurrent.locks.AbstractQueuedSynchronizer;
class Mutex implements Lock {
// 静态内部类，自定义同步器
private static class Sync extends AbstractQueuedSynchronizer {
// 是否处于占用状态
protected boolean isHeldExclusively() {
return getState() == 1;
}
// 当状态为0的时候获取锁
public boolean tryAcquire(int acquires) {
if (compareAndSetState(0, 1)) {
setExclusiveOwnerThread(Thread.currentThread());
return true;
}
return false;
}
// 释放锁，将状态设置为0
protected boolean tryRelease(int releases) {
if (getState() == 0) throw new
IllegalMonitorStateException();
setExclusiveOwnerThread(null);
setState(0);
return true;
}
// 返回一个Condition，每个condition都包含了一个condition队列
Condition newCondition() {
return new ConditionObject();
}
}
// 仅需要将操作代理到Sync上即可
private final Sync sync = new Sync();
public void lock() {
sync.acquire(1);
}
public boolean tryLock() {
return sync.tryAcquire(1);
}
public void unlock() {
sync.release(1);
}
public Condition newCondition() {
return sync.newCondition();
}
public boolean isLocked() {
return sync.isHeldExclusively();
}
public boolean hasQueuedThreads() {
return sync.hasQueuedThreads();
}
public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}
public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException {
return sync.tryAcquireNanos(1, unit.toNanos(timeout));
}
}
lock方法实际上是去调用同步器的模板方法acquire(int args),而acquire方法又会调用重写的tryAcquire(int args)方法。在Mutex重写的tryAcquire逻辑中，直接尝试用CAS获取锁，成功返回true,失败返回false。
它并没有一个判断同步状态的逻辑，假设当前线程已经是持有锁的线程，重入的时候CAS失败线程就阻塞在了这里，所以Mutex不支持锁的重入。
对比ReentrantLock的逻辑，
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)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
而ReentrantLock的实现，是在上面基础上增加了再次获取同步状态的处理逻辑，即通过判断当前线程是否为持有锁的线程来决定获取操作是否成功，如果不是再去CAS,如果是直接将同步状态增加，相当于上锁次数+1。
既然多次上锁，那么在解锁的时候肯定也需要多次解锁，所以在tryRelease的实现上也会和Mutex不同，
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;
}
假设已经上了n次锁（也就是锁重入了n次），那么前（n-1）次tryRelease必须返回false,只有n次解锁，同步状态完全释放了，才能说我这个锁释放成功了。
而在Mutex的tryRelease逻辑里，只需要设置同步状态是0，直接释放锁即可。
三，synchronized和ReentrantLock
这两个都支持锁的重入，只不过synchronized是隐式的获取/释放锁，隐式地重进入。而ReentrantLock的lock()和unlock()都是我们手写的，在调用lock()方法时，已经获取到锁的线程，能够再次调用lock()方法获取锁而不被阻塞。
均参考整理自《Java 并发编程的艺术》
