談談 synchronized和ReenTrantLock 的區別

1.二者都是可重入鎖

    「可重入鎖」概念是：本身能夠再次得到本身的內部鎖。好比一個線程得到了某個對象的鎖，此時這個對象鎖尚未釋放，當其再次想要得到這個對象的鎖的時候仍是能夠獲取的，若是鎖不可重入的話，就會形成死鎖。同一個線程每次獲取鎖，鎖的計數器都增1，因此要等到鎖的計數器降低爲0時才能釋放鎖。

2.synchronized依賴於JVM而ReenTrantLock 依賴於API

   synchronized是依賴於JVM實現的，虛擬機團隊在JDK1.6爲synchronized關鍵字進行了不少優化，可是這些優化都是在虛擬機層面實現的，並無直接暴露給咱們。ReenTrantLock 是JDK層面實現的（也就是API層面，須要lock()和unlock()方法配合try/finally語句塊來完成），因此咱們能夠經過查看它的源代碼，來看它是如何實現的。

3.ReenTrantLock 比synchronized增長了一些高級的功能

   相比synchronized，ReenTrantLock 增長了一些高級功能。主要來講有三點：1.等待可中斷  2.可實現公平鎖  3.可實現選擇性通知（鎖能夠綁定多個條件）具體以下：

        ReenTrantLock 提供了一種可以中斷等待鎖的線程的機制，經過lock.lockInterruptibly()來實現這個機制。也就是說正在等待的線程能夠選擇放棄等待，改成處理其餘事情。                                                                                                                                                                                                               ReenTrantLock 能夠指定是公平鎖仍是非公平鎖。而synchronized只能是非公平鎖。所謂的公平鎖就是先等待的線程先得到鎖。ReenTrantLock 默認是非公平鎖，也能夠經過ReenTrantLock 類的ReentrantLock （boolean fair）構造方法來指定是不是公平的。                                                                             synchronized關鍵字與wait()和notify/notifyAll()方法結合能夠實現等待/通知 機制，ReenTrantLock 類固然能夠實現，可是須要藉助Condition接口和newCondition()方法。Condition是JDK1.5以後纔有的，它具備很好的靈活性，好比能夠實現多路通知功能也就是在一個Lock對象中能夠建立多個Condition實例（即對象監視器），線程對象能夠註冊在指定Condition中，從而能夠有選擇性的進行線程通知，在調度線程上更加靈活。在使用notify/notifyAll()方法進行通知時，被通知的線程是由JVM選擇的，用 ReenTrantLock 類結合Condition實例能夠實現「選擇性通知」，這個功能很是重要，並且是Condition接口默認提供的。而synchronized關鍵字就至關於整個Lock對象中只有一個Condition實例，全部的線程註冊都在它一個身上。若是執行notifyAll方法的話就會通知全部處於等待狀態的線程，這樣會形成很大的效率問題，而Condition實例的signalAll()方法只會喚醒註冊在該Condition實例中的全部等待線程。

4.性能已不是選擇標準