原創聲明：本文來源于公衆号【胖滾豬學程式設計】 轉載請注明出處
在
JAVA并發程式設計 如何解決原子性問題的最後，我們賣了個關子，互斥鎖不僅僅隻有synchronized關鍵字，還可以用J.U.C中的Locks的包來實作，并且它非常強大！今天就來一探究竟吧！
ReentrantLock
顧名思義，ReentrantLock叫做可重入鎖，所謂可重入鎖，顧名思義，指的是線程可以重複擷取同一把鎖。
ReentrantLock也是互斥鎖，是以也可以保證原子性。
先寫一個簡單的demo上手吧，就拿原子性問題中兩個線程分别做累加的demo為例，現在使用ReentrantLock來改寫：
private void add10K() {
// 擷取鎖
reentrantLock.lock();
try {
int idx = 0;
while (idx++ < 10000) {
count++;
}
} finally {
// 保證鎖能釋放
reentrantLock.unlock();
}
} ReentrantLock在這裡可以達到和synchronized一樣的效果，為了友善你回憶，我再次把synchronized實作互斥的代碼貼上來：
private synchronized void add10K(){
int start = 0;
while (start ++ < 10000){
this.count ++;
}
} ReentrantLock與synchronized的差別
1、重入
synchronized可重入，因為加鎖和解鎖自動進行，不必擔心最後是否釋放鎖；ReentrantLock也可重入，但加鎖和解鎖需要手動進行，且次數需一樣，否則其他線程無法獲得鎖。
2、實作
synchronized是JVM實作的、而ReentrantLock是JDK實作的。說白了就是，是作業系統來實作，還是使用者自己敲代碼實作。
3、性能
在 Java 的 1.5 版本中，synchronized 性能不如 SDK 裡面的 Lock，但 1.6 版本之後，synchronized 做了很多優化，将性能追了上來。
4、功能
ReentrantLock鎖的細粒度和靈活度，都明顯優于synchronized ，畢竟越麻煩使用的東西肯定功能越多啦！
特有功能一：可指定是公平鎖還是非公平鎖，而synchronized隻能是非公平鎖。
公平的意思是先等待的線程先擷取鎖。可以在構造函數中指定公平政策。
// 分别測試為true 和 為false的輸出。為true則輸出順序一定是A B C 但是為false的話有可能輸出A C B
private static final ReentrantLock reentrantLock = new ReentrantLock(true);
public static void main(String[] args) throws InterruptedException {
ReentrantLockDemo2 demo2 = new ReentrantLockDemo2();
Thread a = new Thread(() -> { test(); }, "A");
Thread b = new Thread(() -> { test(); }, "B");
Thread c = new Thread(() -> { test(); }, "C");
a.start();b.start();c.start();
}
public static void test() {
reentrantLock.lock();
try {
System.out.println("線程" + Thread.currentThread().getName());
} finally {
reentrantLock.unlock();//一定要釋放鎖
}
} 在原子性文章的最後，我們還賣了個關子，以轉賬為例，說明synchronized會導緻死鎖的問題，即兩個線程你等我的鎖，我等你的鎖，兩方都阻塞，不會釋放！為了友善，我再次把代碼貼上來：
static void transfer(Account source,Account target, int amt) throws InterruptedException {
// 鎖定轉出賬戶 Thread1鎖定了A Thread2鎖定了B
synchronized (source) {
Thread.sleep(1000);
log.info("持有鎖{} 等待鎖{}",source,target);
// 鎖定轉入賬戶 Thread1需要擷取到B,可是被Thread2鎖定了。Thread2需要擷取到A，可是被Thread1鎖定了。是以互相等待、死鎖
synchronized (target) {
if (source.getBalance() > amt) {
source.setBalance(source.getBalance() - amt);
target.setBalance(target.getBalance() + amt);
}
}
}
} 而ReentrantLock可以完美避免死鎖問題，因為它可以破壞死鎖四大必要條件之一的：不可搶占條件。這得益于它這麼幾個功能：
特有功能二：非阻塞地擷取鎖。如果嘗試擷取鎖失敗，并不進入阻塞狀态，而是直接傳回false，這時候線程不用阻塞等待，可以先去做其他事情。是以不會造成死鎖。
// 支援非阻塞擷取鎖的 API
boolean tryLock(); 現在我們用ReentrantLock來改造一下死鎖代碼
static void transfer(Account source, Account target, int amt) throws InterruptedException {
Boolean isContinue = true;
while (isContinue) {
if (source.getLock().tryLock()) {
log.info("{}已擷取鎖 time{}", source.getLock(),System.currentTimeMillis());
try {
if (target.getLock().tryLock()) {
log.info("{}已擷取鎖 time{}", target.getLock(),System.currentTimeMillis());
try {
log.info("開始轉賬操作");
source.setBalance(source.getBalance() - amt);
target.setBalance(target.getBalance() + amt);
log.info("結束轉賬操作 source{} target{}", source.getBalance(), target.getBalance());
isContinue=false;
} finally {
log.info("{}釋放鎖 time{}", target.getLock(),System.currentTimeMillis());
target.getLock().unlock();
}
}
} finally {
log.info("{}釋放鎖 time{}", source.getLock(),System.currentTimeMillis());
source.getLock().unlock();
}
}
}
} tryLock還支援逾時。調用tryLock時沒有擷取到鎖，會等待一段時間，如果線程在一段時間之内還是沒有擷取到鎖，不是進入阻塞狀态，而是throws InterruptedException，那這個線程也有機會釋放曾經持有的鎖，這樣也能破壞死鎖不可搶占條件。
boolean tryLock(long time, TimeUnit unit)
特有功能三：提供能夠中斷等待鎖的線程的機制
synchronized 的問題是，持有鎖 A 後，如果嘗試擷取鎖 B 失敗，那麼線程就進入阻塞狀态，一旦發生死鎖，就沒有任何機會來喚醒阻塞的線程。
但如果阻塞狀态的線程能夠響應中斷信号，也就是說當我們給阻塞的線程發送中斷信号的時候，能夠喚醒它，那它就有機會釋放曾經持有的鎖 A。這樣就破壞了不可搶占條件了。ReentrantLock可以用lockInterruptibly方法來實作。
public static void main(String[] args) throws InterruptedException {
ReentrantLockDemo5 demo2 = new ReentrantLockDemo5();
Thread th1 = new Thread(() -> {
try {
deadLock(reentrantLock1, reentrantLock2);
} catch (InterruptedException e) {
System.out.println("線程A被中斷");
}
}, "A");
Thread th2 = new Thread(() -> {
try {
deadLock(reentrantLock2, reentrantLock1);
} catch (InterruptedException e) {
System.out.println("線程B被中斷");
}
}, "B");
th1.start();
th2.start();
th1.interrupt();
}
public static void deadLock(Lock lock1, Lock lock2) throws InterruptedException {
lock1.lockInterruptibly(); //如果改成用lock那麼是會一直死鎖的
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
lock2.lockInterruptibly();
try {
System.out.println("執行完成");
} finally {
lock1.unlock();
lock2.unlock();
}
} 特有功能四、可以用J.U.C包中的Condition實作分組喚醒需要等待的線程。而synchronized隻能notify或者notifyAll。這裡涉及到線程之間的協作，在後續章節會詳細講解，敬請關注公衆号【胖滾豬學程式設計】。
ReentrantLock如何保證可見性
剛剛我們證明了ReentrantLock能保證原子性，那可以保證可見性嗎？答案是必須的。
回憶下
JAVA并發程式設計 如何解決可見性和有序性問題。我們說 Java 裡多線程的可見性是通過 Happens-Before 規則保證的，比如 synchronized 之是以能夠保證可見性，也是因為有一條 synchronized 相關的規則：synchronized 的解鎖 Happens-Before 于後續對這個鎖的加鎖。
那 Java SDK 裡面 Lock 靠什麼保證可見性呢？Java SDK 裡面鎖的實作非常複雜，但是原理還是需要簡單介紹一下：它是利用了 volatile 相關的 Happens-Before 規則。
ReentrantLock的同步其實是委托給AbstractQueuedSynchronizer的。加鎖和解鎖是通過改變AbstractQueuedSynchronizer的state屬性，這個屬性是volatile的。
擷取鎖的時候，會讀寫 state 的值；解鎖的時候，也會讀寫 state 的值。類比volatile是如何保證可見性的就可以解決這個問題了！如果不清楚可以回顧一下【漫畫】JAVA并發程式設計 如何解決可見性和有序性問題
總結
synchronized 在JVM層面實作了對臨界資源的同步互斥通路，但 synchronized 粒度有些大，在處理實際問題時存在諸多局限性，比如響應中斷等。
Lock 提供了比 synchronized更廣泛的鎖操作，它能以更優雅更靈活的方式處理線程同步問題。
我們以ReentrantLock為例子進入了Lock的世界，最重要的是記住ReentrantLock的特有功能，比如中斷、逾時、非阻塞鎖等。當你的需求符合這些特有功能的時候，那你隻能選擇Lock而不是synchronized
附文中代碼github位址：
https://github.com/LYL41011/java-concurrency-learning