Java中的鎖 · java學習摘記

http://ifeve.com/locks/ [原文鏈接](http://tutorials.jenkov.com/java-concurrency/locks.html "原文鏈接")?**作者：**Jakob Jenkov?**譯者：**[申章](http://weibo.com/u/3051817564)?**校對：**丁一鎖像synchronized同步塊一樣，是一種線程同步機制，但比Java中的synchronized同步塊更復雜。因為鎖（以及其它更高級的線程同步機制）是由synchronized同步塊的方式實現的，所以我們還不能完全擺脫synchronized關鍵字（*譯者注：這說的是Java 5之前的情況*）。自Java 5開始，java.util.concurrent.locks包中包含了一些鎖的實現，因此你不用去實現自己的鎖了。但是你仍然需要去了解怎樣使用這些鎖，且了解這些實現背后的理論也是很有用處的。可以參考我對[java.util.concurrent.locks.Lock](http://tutorials.jenkov.com/java-util-concurrent/lock.html "Lock")的介紹，以了解更多關于鎖的信息。以下是本文所涵蓋的主題： 1. [一個簡單的鎖](http://ifeve.com/locks/#simpleLock) 2. [鎖的可重入性](http://ifeve.com/locks/#lockReentrance) 3. [鎖的公平性](http://ifeve.com/locks/#lockFairness) 4. [在finally語句中調用unlock()](http://ifeve.com/locks/#finallyUnlock) **一個簡單的鎖** 讓我們從java中的一個同步塊開始： ~~~ public class Counter{ private int count = 0; public int inc(){ synchronized(this){ return ++count; } } } ~~~ 可以看到在inc()方法中有一個synchronized(this)代碼塊。該代碼塊可以保證在同一時間只有一個線程可以執行return ++count。雖然在synchronized的同步塊中的代碼可以更加復雜，但是++count這種簡單的操作已經足以表達出線程同步的意思。以下的Counter類用Lock代替synchronized達到了同樣的目的： ~~~ public class Counter{ private Lock lock = new Lock(); private int count = 0; public int inc(){ lock.lock(); int newCount = ++count; lock.unlock(); return newCount; } } ~~~ lock()方法會對Lock實例對象進行加鎖，因此所有對該對象調用lock()方法的線程都會被阻塞，直到該Lock對象的unlock()方法被調用。這里有一個Lock類的簡單實現： | `01` | `public`?`class`?`Counter{` | | `02` | `public`?`class`?`Lock{` | | `03` | `private`?`boolean`?`isLocked =?``false``;` | | `04` | ? | | `05` | `public`?`synchronized`?`void`?`lock()` | | `06` | `throws`?`InterruptedException{` | | `07` | `while``(isLocked){` | | `08` | `wait();` | | `09` | `}` | | `10` | `isLocked =?``true``;` | | `11` | `}` | | `12` | ? | | `13` | `public`?`synchronized`?`void`?`unlock(){` | | `14` | `isLocked =?``false``;` | | `15` | `notify();` | | `16` | `}` | | `17` | `}` | 注意其中的while(isLocked)循環，它又被叫做“自旋鎖”。自旋鎖以及wait()和notify()方法在[線程通信](http://ifeve.com/thread-signaling/ "Thread Signaling")這篇文章中有更加詳細的介紹。當isLocked為true時，調用lock()的線程在wait()調用上阻塞等待。為防止該線程沒有收到notify()調用也從wait()中返回（也稱作[虛假喚醒](http://ifeve.com/thread-signaling/#spurious_wakeups "Spurious Wakeup")），這個線程會重新去檢查isLocked條件以決定當前是否可以安全地繼續執行還是需要重新保持等待，而不是認為線程被喚醒了就可以安全地繼續執行了。如果isLocked為false，當前線程會退出while(isLocked)循環，并將isLocked設回true，讓其它正在調用lock()方法的線程能夠在Lock實例上加鎖。當線程完成了[臨界區](http://ifeve.com/race-conditions-and-critical-sections/ "critical section")（位于lock()和unlock()之間）中的代碼，就會調用unlock()。執行unlock()會重新將isLocked設置為false，并且通知（喚醒）其中一個（若有的話）在lock()方法中調用了wait()函數而處于等待狀態的線程。 **鎖的可重入性** Java中的synchronized同步塊是可重入的。這意味著如果一個java線程進入了代碼中的synchronized同步塊，并因此獲得了該同步塊使用的同步對象對應的管程上的鎖，那么這個線程可以進入由同一個管程對象所同步的另一個java代碼塊。下面是一個例子： | `1` | `public`?`class`?`Reentrant{` | | `2` | `public`?`synchronized`?`outer(){` | | `3` | `inner();` | | `4` | `}` | | `5` | ? | | `6` | `public`?`synchronized`?`inner(){` | | `7` | `//do something` | | `8` | `}` | | `9` | `}` | 注意outer()和inner()都被聲明為synchronized，這在Java中和synchronized(this)塊等效。如果一個線程調用了outer()，在outer()里調用inner()就沒有什么問題，因為這兩個方法（代碼塊）都由同一個管程對象（”this”)所同步。如果一個線程已經擁有了一個管程對象上的鎖，那么它就有權訪問被這個管程對象同步的所有代碼塊。這就是可重入。線程可以進入任何一個它已經擁有的鎖所同步著的代碼塊。前面給出的鎖實現不是可重入的。如果我們像下面這樣重寫Reentrant類，當線程調用outer()時，會在inner()方法的lock.lock()處阻塞住。 | `01` | `public`?`class`?`Reentrant2{` | | `02` | `Lock lock =?``new`?`Lock();` | | `03` | ? | | `04` | `public`?`outer(){` | | `05` | `lock.lock();` | | `06` | `inner();` | | `07` | `lock.unlock();` | | `08` | `}` | | `09` | ? | | `10` | `public`?`synchronized`?`inner(){` | | `11` | `lock.lock();` | | `12` | `//do something` | | `13` | `lock.unlock();` | | `14` | `}` | | `15` | `}` | 調用outer()的線程首先會鎖住Lock實例，然后繼續調用inner()。inner()方法中該線程將再一次嘗試鎖住Lock實例，結果該動作會失敗（也就是說該線程會被阻塞），因為這個Lock實例已經在outer()方法中被鎖住了。兩次lock()之間沒有調用unlock()，第二次調用lock就會阻塞，看過lock()實現后，會發現原因很明顯： | `01` | `public`?`class`?`Lock{` | | `02` | `boolean`?`isLocked =?``false``;` | | `03` | ? | | `04` | `public`?`synchronized`?`void`?`lock()` | | `05` | `throws`?`InterruptedException{` | | `06` | `while``(isLocked){` | | `07` | `wait();` | | `08` | `}` | | `09` | `isLocked =?``true``;` | | `10` | `}` | | `11` | ? | | `12` | `...` | | `13` | `}` | 一個線程是否被允許退出lock()方法是由while循環（自旋鎖）中的條件決定的。當前的判斷條件是只有當isLocked為false時lock操作才被允許，而沒有考慮是哪個線程鎖住了它。為了讓這個Lock類具有可重入性，我們需要對它做一點小的改動： | `01` | `public`?`class`?`Lock{` | | `02` | `boolean`?`isLocked =?``false``;` | | `03` | `Thread? lockedBy =?``null``;` | | `04` | `int`?`lockedCount =?``0``;` | | `05` | ? | | `06` | `public`?`synchronized`?`void`?`lock()` | | `07` | `throws`?`InterruptedException{` | | `08` | `Thread callingThread =` | | `09` | `Thread.currentThread();` | | `10` | `while``(isLocked && lockedBy != callingThread){` | | `11` | `wait();` | | `12` | `}` | | `13` | `isLocked =?``true``;` | | `14` | `lockedCount++;` | | `15` | `lockedBy = callingThread;` | | `16` | `}` | | `17` | ? | | `18` | `public`?`synchronized`?`void`?`unlock(){` | | `19` | `if``(Thread.curentThread() ==` | | `20` | `this``.lockedBy){` | | `21` | `lockedCount--;` | | `22` | ? | | `23` | `if``(lockedCount ==?``0``){` | | `24` | `isLocked =?``false``;` | | `25` | `notify();` | | `26` | `}` | | `27` | `}` | | `28` | `}` | | `29` | ? | | `30` | `...` | | `31` | `}` | 注意到現在的while循環（自旋鎖）也考慮到了已鎖住該Lock實例的線程。如果當前的鎖對象沒有被加鎖(isLocked = false)，或者當前調用線程已經對該Lock實例加了鎖，那么while循環就不會被執行，調用lock()的線程就可以退出該方法（*譯者注：“被允許退出該方法”在當前語義下就是指不會調用wait()而導致阻塞）*。除此之外，我們需要記錄同一個線程重復對一個鎖對象加鎖的次數。否則，一次unblock()調用就會解除整個鎖，即使當前鎖已經被加鎖過多次。在unlock()調用沒有達到對應lock()調用的次數之前，我們不希望鎖被解除。現在這個Lock類就是可重入的了。 **鎖的公平性** Java的synchronized塊并不保證嘗試進入它們的線程的順序。因此，如果多個線程不斷競爭訪問相同的synchronized同步塊，就存在一種風險，其中一個或多個線程永遠也得不到訪問權 —— 也就是說訪問權總是分配給了其它線程。這種情況被稱作線程饑餓。為了避免這種問題，鎖需要實現公平性。本文所展現的鎖在內部是用synchronized同步塊實現的，因此它們也不保證公平性。[饑餓和公平](http://tutorials.jenkov.com/java-concurrency/starvation-and-fairness.html "Starvation and Fairness")中有更多關于該內容的討論。 **在finally語句中調用unlock()** 如果用Lock來保護臨界區，并且臨界區有可能會拋出異常，那么在finally語句中調用unlock()就顯得非常重要了。這樣可以保證這個鎖對象可以被解鎖以便其它線程能繼續對其加鎖。以下是一個示例： | `1` | `lock.lock();` | | `2` | `try``{` | | `3` | `//do critical section code,` | | `4` | `//which may throw exception` | | `5` | `}?``finally`?`{` | | `6` | `lock.unlock();` | | `7` | `}` | 這個簡單的結構可以保證當臨界區拋出異常時Lock對象可以被解鎖。如果不是在finally語句中調用的unlock()，當臨界區拋出異常時，Lock對象將永遠停留在被鎖住的狀態，這會導致其它所有在該Lock對象上調用lock()的線程一直阻塞。 **原創文章，轉載請注明：**?轉載自[并發編程網 – ifeve.com](http://ifeve.com/)**本文鏈接地址:**?[Java中的鎖](http://ifeve.com/locks/)