[TOC] # 可重入鎖 　如果鎖具備可重入性，則稱作為可重入鎖。像synchronized和ReentrantLock都是可重入鎖，可重入性在我看來實際上表明了鎖的分配機制：基于線程的分配，而不是基于方法調用的分配。舉個簡單的例子，當一個線程執行到某個synchronized方法時，比如說method1，而在method1中會調用另外一個synchronized方法method2，此時線程不必重新去申請鎖，而是可以直接執行方法method2。 看下面這段代碼就明白了： ~~~ class MyClass { public synchronized void method1() { method2(); } public synchronized void method2() { } } ~~~ 上述代碼中的兩個方法method1和method2都用synchronized修飾了，假如某一時刻，線程A執行到了method1，此時線程A獲取了這個對象的鎖，而由于method2也是synchronized方法(同一個對象)，假如synchronized不具備可重入性，此時線程A需要重新申請鎖。但是這就會造成一個問題，因為線程A已經持有了該對象的鎖，而又在申請獲取該對象的鎖，這樣就會線程A一直等待永遠不會獲取到的鎖。 而由于synchronized和Lock都具備可重入性，所以不會發生上述現象。 # 可中斷鎖 可中斷鎖：顧名思義，就是可以相應中斷的鎖。 在Java中，synchronized就不是可中斷鎖，而Lock是可中斷鎖。 如果某一線程A正在執行鎖中的代碼，另一線程B正在等待獲取該鎖，可能由于等待時間過長，線程B不想等待了，想先處理其他事情，我們可以讓它中斷自己或者在別的線程中中斷它，這種就是可中斷鎖。 在前面演示lockInterruptibly()的用法時已經體現了Lock的可中斷性。 # 公平鎖 公平鎖即盡量以請求鎖的順序來獲取鎖。比如同是有多個線程在等待一個鎖，當這個鎖被釋放時，等待時間最久的線程（最先請求的線程）會獲得該所，這種就是公平鎖。 非公平鎖即無法保證鎖的獲取是按照請求鎖的順序進行的。這樣就可能導致某個或者一些線程永遠獲取不到鎖。 在Java中，synchronized就是非公平鎖，它無法保證等待的線程獲取鎖的順序。 而對于ReentrantLock和ReentrantReadWriteLock，它默認情況下是非公平鎖，但是可以設置為公平鎖。 看一下這2個類的源代碼就清楚了：  在ReentrantLock中定義了2個靜態內部類，一個是NotFairSync，一個是FairSync，分別用來實現非公平鎖和公平鎖。 我們可以在創建ReentrantLock對象時，通過以下方式來設置鎖的公平性： ~~~ ReentrantLock lock = new ReentrantLock(true); ~~~ 如果參數為true表示為公平鎖，為fasle為非公平鎖。默認情況下，如果使用無參構造器，則是非公平鎖。 ! 另外在ReentrantLock類中定義了很多方法，比如： ~~~ isFair() //判斷鎖是否是公平鎖 isLocked() //判斷鎖是否被任何線程獲取了 isHeldByCurrentThread() //判斷鎖是否被當前線程獲取了 hasQueuedThreads() //判斷是否有線程在等待該鎖 ~~~ 在ReentrantReadWriteLock中也有類似的方法，同樣也可以設置為公平鎖和非公平鎖。不過要記住，ReentrantReadWriteLock并未實現Lock接口，它實現的是ReadWriteLock接口。 # 讀寫鎖 讀寫鎖將對一個資源（比如文件）的訪問分成了2個鎖，一個讀鎖和一個寫鎖。 正因為有了讀寫鎖，才使得多個線程之間的讀操作不會發生沖突。 ReadWriteLock就是讀寫鎖，它是一個接口，ReentrantReadWriteLock實現了這個接口。 可以通過readLock()獲取讀鎖，通過writeLock()獲取寫鎖。