[[396491]]

并發編程的關鍵是什么，知道嗎?

我淡淡一笑，還好平時就玩的高并發架構設計，不然真被你唬住了!

• 互斥

同一時刻，只允許一個線程訪問共享資源

• 同步

線程之間通信、協作

這倆問題，管程都能一把梭。JUC是通過Lock、Condition接口實現的管程：

• Lock

解決互斥

• Condition

解決同步

只見 P8 不慌不忙，又開始問道：

提起這個管程啊，synchronized也是管程的實現呀，既然 JDK 已經實現了管程，為什么還要提供另一個實現?

這絕非重復造輪子，它們有很大區別。最簡單的，在JDK 1.5，synchronized性能差于Lock，但1.6后，synchronized被優化，將性能提高，所以1.6后又推薦使用synchronized。但性能問題只要優化一下就行了，根本無需“重復造輪子”。

問題的關鍵在于，死鎖問題的破壞“不可搶占”條件，synchronized無法達到該目的。因為synchronized申請資源時，若申請不到，線程直接就被阻塞了，而阻塞態的線程是無所作為，自然也釋放不了線程已經占有的資源。

但我們希望：對于“不可搶占”條件，占用部分資源的線程進一步申請其他資源時，若申請不到，可以主動釋放它已占有的資源，這樣“不可搶占”條件就被破壞掉了。

若重新設計一把互斥鎖去解決這個問題，咋搞呢?如下設計都能破壞“不可搶占”條件：

[[396492]]

能響應中斷

使用synchronized持有 鎖X 后，若嘗試獲取 鎖Y 失敗，則線程進入阻塞，一旦死鎖，就再無機會喚醒阻塞線程。但若阻塞態的線程能夠響應中斷信號，即當給阻塞線程發送中斷信號時，能喚醒它，那它就有機會釋放曾經持有的 鎖X。

支持超時

若線程在一段時間內，都沒有獲取到鎖，不是進入阻塞態，而是返回一個錯誤，則該線程也有機會釋放曾經持有的鎖

非阻塞地獲取鎖

如果嘗試獲取鎖失敗，并不進入阻塞狀態，而是直接返回，那這個線程也有機會釋放曾經持有的鎖

其實就是Lock接口的如下方法：

lockInterruptibly() 支持中斷

tryLock(long time, TimeUnit unit) 支持超時

tryLock() 支持非阻塞獲取鎖

那你知道它是如何保證可見性的嗎?

Lock經典案例就是try/finally，必須在finally塊里釋放鎖。Java多線程的可見性是通過Happens-Before規則保證的，而Happens-Before 并沒有提到 Lock 鎖。那Lock靠什么保證可見性呢?

[[396494]]

肯定的，它是利用了volatile的Happens-Before規則。因為 ReentrantLock 的內部類繼承了 AQS，其內部維護了一個volatile 變量state

• 獲取鎖時，會讀寫state
• 解鎖時，也會讀寫state

所以，執行value+=1前，程序先讀寫一次volatile state，在執行value+=1后，又讀寫一次volatile state。根據Happens-Before的如下規則判定：

順序性規則

• 線程t1的value+=1 Happens-Before 線程t1的unlock()

volatile變量規則

• 由于此時 state為1，會先讀取state，所以線程t1的unlock() Happens-Before 線程t2的lock()

傳遞性規則

• 線程t的value+=1 Happens-Before 線程t2的lock()

說說什么是可重入鎖?

可重入鎖，就是線程可以重復獲取同一把鎖，示例如下：

聽說過可重入方法嗎?orz，這是什么鬼?P8 看我一時靚仔語塞，就懂了，說到：沒關系，就隨便問問，看看你的知識面。

其實就是多線程可以同時調用該方法，每個線程都能得到正確結果;同時在一個線程內支持線程切換，無論被切換多少次，結果都是正確的。多線程可以同時執行，還支持線程切換。所以，可重入方法是線程安全的。

那你來簡單說說公平鎖與非公平鎖吧?

比如ReentrantLock有兩個構造器，一個是無參構造器，一個是傳入fair參數的。fair參數代表鎖的公平策略，true：需要構造一個公平鎖，false：構造一個非公平鎖(默認)。

知道鎖的入口等待隊列嗎?

鎖都對應一個等待隊列，如果一個線程沒有獲得鎖，就會進入等待隊列，當有線程釋放鎖的時候，就需要從等待隊列中喚醒一個等待的線程。若是公平鎖，喚醒策略就是誰等待的時間長，就喚醒誰，這很公平 若是非公平鎖，則不提供這個公平保證，所以可能等待時間短的線程被先喚醒。非公平鎖的場景應該是線程釋放鎖之后，如果來了一個線程獲取鎖，他不必去排隊直接獲取到，不會入隊。獲取不到才入隊。

說說你對鎖的一些最佳實踐

鎖并非解決并發問題的銀彈，風險很高，比如各種隨處可見的死鎖，還影響性能。并發大師Doug Lea的最佳實踐：

• 永遠只在更新對象的成員變量時加鎖
• 永遠只在訪問可變的成員變量時加鎖
• 永遠不在調用其他對象的方法時加鎖 因為調用其他對象的方法，實在是太不安全了，也許“其他”方法里面有線程sleep()的調用，也可能會有奇慢無比的I/O操作，這些都會嚴重影響性能。更可怕的是，“其他”類的方法可能也會加鎖，然后雙重加鎖就可能導致死鎖。

還有一些常見的比如只在該加鎖的地方加鎖。

最后拓展一些小知識點：

• notifyAll() 在面對公平鎖和非公平鎖的時候，效果一樣。所有等待隊列中的線程全部被喚醒，統統到入口等待隊列中排隊?這些被喚醒的線程不用根據等待時間排隊再放入入口等待隊列中了吧?都被喚醒。理論上是同時進入入口等待隊列，等待時間是相同的。
• CPU層面的原子性是單條cpu指令。Java層面的互斥(管程)保證了原子性。這兩個原子性意義不一樣。cpu的原子性是不受線程調度影響，指令要不執行了，要么沒執行。而Java層面的原子性是在鎖的機制下保證只有一個線程執行，其余等待，此時cpu還是可以進行線程調度，使運行中的那個線程讓出cpu時間，當然了該線程還是掌握鎖。