??眾所周知，ReentrantLock和synchronized是可重入鎖。下面分析什么是可重入性，以及它們?nèi)绾螌?shí)現(xiàn)可重入性
1 什么是可重入？
??先看定義，定義來(lái)自維基百科
??若一個(gè)程序或子程序可以“在任意時(shí)刻被中斷然后操作系統(tǒng)調(diào)度執(zhí)行另外一段代碼，這段代碼又調(diào)用了該子程序不會(huì)出錯(cuò)”，則稱(chēng)其為可重入（reentrant或re-entrant）的。即當(dāng)該子程序正在運(yùn)行時(shí)，執(zhí)行線(xiàn)程可以再次進(jìn)入并執(zhí)行它，仍然獲得符合設(shè)計(jì)時(shí)預(yù)期的結(jié)果。與多線(xiàn)程并發(fā)執(zhí)行的線(xiàn)程安全不同，可重入強(qiáng)調(diào)對(duì)單個(gè)線(xiàn)程執(zhí)行時(shí)重新進(jìn)入同一個(gè)子程序仍然是安全的。
??代碼測(cè)試，兩個(gè)方法的鎖都是MyReent對(duì)象，在run()內(nèi)部調(diào)用了function()方法，在執(zhí)行run()方法時(shí)，已經(jīng)拿到了鎖對(duì)象reent，假設(shè)synchronized是不可重入的，那么在run()內(nèi)部調(diào)用function() 時(shí)會(huì)被阻塞，但是事實(shí)卻沒(méi)有，所以可以看出synchronized是可重入的。即使是兩個(gè)方法相互調(diào)用也不會(huì)發(fā)生死鎖，只會(huì)拋出棧溢出異常。
??簡(jiǎn)言之，一個(gè)線(xiàn)程持有鎖時(shí)，當(dāng)其他線(xiàn)程嘗試獲取該鎖時(shí)，會(huì)被阻塞；而這個(gè)線(xiàn)程嘗試獲取自己持有鎖時(shí)，如果成功說(shuō)明該鎖是可重入的，反之則不可重入。
public class ReentrantTest {
public static void main(String[] args) {
MyReent reent = new MyReent();
new Thread(reent).start();
}
}
class MyReent implements Runnable{
@Override
public synchronized void run() {
System.out.println(Thread.currentThread().getName() + " run");
function();
}
public synchronized void function(){
System.out.println(Thread.currentThread().getName()+ " function");
}
}
Thread-0 run
Thread-0 function
2 synchronized如何實(shí)現(xiàn)可重入性
??synchronized關(guān)鍵字經(jīng)過(guò)編譯之后，會(huì)在同步塊的前后分別形成monitorenter和monitorexit這兩個(gè)字節(jié)碼指令。每個(gè)鎖對(duì)象內(nèi)部維護(hù)一個(gè)計(jì)數(shù)器，該計(jì)數(shù)器初始值為0，表示任何線(xiàn)程都可以獲取該鎖并執(zhí)行相應(yīng)的方法。根據(jù)虛擬機(jī)規(guī)范的要求，在執(zhí)行monitorenter指令時(shí)，首先要嘗試獲取對(duì)象的鎖。如果這個(gè)對(duì)象沒(méi)被鎖定，或者當(dāng)前線(xiàn)程已經(jīng)擁有了那個(gè)對(duì)象的鎖，把鎖的計(jì)數(shù)器加1，相應(yīng)的，在執(zhí)行monitorexit指令時(shí)會(huì)將鎖計(jì)數(shù)器減1，當(dāng)計(jì)數(shù)器為0時(shí)，鎖就被釋放。如果獲取對(duì)象鎖失敗，那當(dāng)前線(xiàn)程就要阻塞等待，直到對(duì)象鎖被另外一個(gè)線(xiàn)程釋放為止。
3 ReentrantLock如何實(shí)現(xiàn)可重入性
??ReentrantLock在內(nèi)部使用了內(nèi)部類(lèi)Sync來(lái)管理鎖，所以真正的獲取鎖是由Sync的實(shí)現(xiàn)類(lèi)控制的。Sync有兩個(gè)實(shí)現(xiàn)，分別為NonfairSync（非公平鎖）和FairSync（公平鎖）。Sync通過(guò)繼承AQS實(shí)現(xiàn)，在AQS中維護(hù)了一個(gè)private volatile int state來(lái)計(jì)數(shù)重入次數(shù)，避免了頻繁的持有釋放操作帶來(lái)效率問(wèn)題。
??下面是部分ReentrantLock源碼
// Sync繼承于AQS
abstract static class Sync extends AbstractQueuedSynchronizer {
...
}
// ReentrantLock默認(rèn)是非公平鎖
public ReentrantLock() {
sync = new NonfairSync();
}
// 可以通過(guò)向構(gòu)造方法中傳true來(lái)實(shí)現(xiàn)公平鎖
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
??線(xiàn)程搶鎖過(guò)程（公平鎖實(shí)現(xiàn)）：
protected final boolean tryAcquire(int acquires) {
// 當(dāng)前想要獲取鎖的線(xiàn)程
final Thread current = Thread.currentThread();
// 當(dāng)前鎖的狀態(tài)
int c = getState();
// state == 0 此時(shí)此刻沒(méi)有線(xiàn)程持有鎖
if (c == 0) {
// 雖然此時(shí)此刻鎖是可以用的，但是這是公平鎖，既然是公平，就得講究先來(lái)后到，
// 看看有沒(méi)有別人在隊(duì)列中等了半天了
if (!hasQueuedPredecessors() &&
// 如果沒(méi)有線(xiàn)程在等待，那就用CAS嘗試一下，成功了就獲取到鎖了，
// 不成功的話(huà)，只能說(shuō)明一個(gè)問(wèn)題，就在剛剛幾乎同一時(shí)刻有個(gè)線(xiàn)程搶先了 =_=
// 因?yàn)閯倓傔€沒(méi)人的，我判斷過(guò)了
compareAndSetState(0, acquires)) {
// 到這里就是獲取到鎖了，標(biāo)記一下，告訴大家，現(xiàn)在是我占用了鎖
setExclusiveOwnerThread(current);
return true;
}
}
// 會(huì)進(jìn)入這個(gè)else if分支，說(shuō)明是重入了，需要操作：state=state+1
// 這里不存在并發(fā)問(wèn)題
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
// 如果到這里，說(shuō)明前面的if和else if都沒(méi)有返回true，說(shuō)明沒(méi)有獲取到鎖
return false;
}
??從上面可以看出：
(1) 當(dāng)一個(gè)線(xiàn)程在獲取鎖過(guò)程中，先判斷state的值是否為0，如果是表示沒(méi)有線(xiàn)程持有鎖，就可以嘗試獲取鎖（不一定獲取成功）。
(2) 當(dāng)state的值不為0時(shí)，表示鎖已經(jīng)被一個(gè)線(xiàn)程占用了，這時(shí)會(huì)做一個(gè)判斷current == getExclusiveOwnerThread()（這個(gè)方法返回的是當(dāng)前持有鎖的線(xiàn)程），這個(gè)判斷是看當(dāng)前持有鎖的線(xiàn)程是不是自己，如果是自己，那么將state的值加1就可以了，表示重入返回即可。
本文完
??本文參考：《深入理解Java虛擬機(jī)第二版》
??源碼分析參考：一行一行源碼分析清楚AbstractQueuedSynchronizer，寫(xiě)的非常好！??！
