前言：由於最近準備買面試，我看了很多多線程併發相關的面試題，我把我覺得最可能被問到的一些知識點記錄下來，希望能夠幫助到大家
1.Synchronized 和 ReenTrantLock 的對比
①兩者都是可重入鎖。“可重入鎖”概念是：自己可以再次獲取自己的內部鎖。比如一個線程獲得了某個對象的鎖，此時這個對象鎖還沒有釋放，當其再次想要獲取這個對象的鎖的時候還是可以獲取的，如果不可鎖重入的話，就會造成死鎖。同一個線程每次獲取鎖，鎖的計數器都自增1，所以要等到鎖的計數器下降爲0時才能釋放鎖。
② synchronized 依賴於 JVM 而 ReenTrantLock 依賴於 API
synchronized 是依賴於 JVM 實現的，前面我們也講到了 虛擬機團隊在 JDK1.6 爲 synchronized 關鍵字進行了很多優化，但是這些優化都是在虛擬機層面實現的，並沒有直接暴露給我們。ReenTrantLock 是 JDK 層面實現的（也就是 API 層面，需要 lock() 和 unlock 方法配合 try/finally 語句塊來完成），所以我們可以通過查看它的源代碼，來看它是如何實現的。
③ ReenTrantLock 比 synchronized 增加了一些高級功能
相比synchronized，ReenTrantLock增加了一些高級功能。主要來說主要有三點：①等待可中斷；②可實現公平鎖；③可實現選擇性通知（鎖可以綁定多個條件）
- 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實例中的所有等待線程。
如果你想使用上述功能，那麼選擇ReenTrantLock是一個不錯的選擇。
④ 性能已不是選擇標準
在JDK1.6之前，synchronized 的性能是比 ReenTrantLock 差很多。具體表示爲：synchronized 關鍵字吞吐量隨線程數的增加，下降得非常嚴重。而ReenTrantLock 基本保持一個比較穩定的水平。我覺得這也側面反映了， synchronized 關鍵字還有非常大的優化餘地。後續的技術發展也證明了這一點，我們上面也講了在 JDK1.6 之後 JVM 團隊對 synchronized 關鍵字做了很多優化。JDK1.6 之後，synchronized 和 ReenTrantLock 的性能基本是持平了。所以網上那些說因爲性能才選擇 ReenTrantLock 的文章都是錯的！JDK1.6之後，性能已經不是選擇synchronized和ReenTrantLock的影響因素了！而且虛擬機在未來的性能改進中會更偏向於原生的synchronized，所以還是提倡在synchronized能滿足你的需求的情況下，優先考慮使用synchronized關鍵字來進行同步！優化後的synchronized和ReenTrantLock一樣，在很多地方都是用到了CAS操作。
2.synchronized詳解
2juc原子類的總結
思維導圖：
