每個時代，都不會虧待會學習的人
大家好，我是yes。
本來打算繼續寫訊息佇列的東西的，但是最近在帶新同事，發現新同事對於鎖這方面有一些誤解，所以今天就來談談“鎖”事和 Java 中的併發安全容器使用有哪些注意點。
不過在這之前還是得先來盤一盤為什麼需要鎖這玩意，這得從併發 BUG 的源頭說起。
併發 BUG 的源頭
這個問題我 19 年的時候寫過一篇文章， 現在回頭看那篇文章真的是羞澀啊。
讓我們來看下這個源頭是什麼，我們知道電腦有CPU、記憶體、硬碟，硬碟的讀取速度最慢，其次是記憶體的讀取，記憶體的讀取相對於 CPU 的執行又太慢了，因此又搞了個CPU快取，L1、L2、L3。
正是這個
CPU快取再加上現在多核CPU的情況產生了併發BUG
。
這就一個很簡單的程式碼，如果此時有執行緒 A 和執行緒 B 分別在 CPU - A 和 CPU - B 中執行這個方法，它們的操作是先將 a 從主存取到 CPU 各自的快取中，此時它們快取中 a 的值都是 0。
然後它們分別執行 a++，此時它們各自眼中 a 的值都是 1，之後把 a 刷到主存的時候 a 的值還是1，這就出現問題了，明明執行了兩次加一最終的結果卻是 1，而不是 2。
這個問題就叫可見性問題
。
在看我們 a++ 這條語句，我們現在的語言都是高階語言，這其實和語法糖很類似，用起來好像很方便實際上那只是表面，真正需要執行的指令一條都少不了。
高階語言的一條語句翻譯成 CPU 指令的時候可不止一條， 就例如 a++ 轉換成 CPU 指令至少就有三條。
把 a 從記憶體拿到暫存器中；
在暫存器中 +1；
將結果寫入快取或記憶體中；
所以我們以為 a++ 這條語句是不可能中斷的是具備原子性的，而實際上 CPU 可以能執行一條指令時間片就到了，此時上下文切換到另一個執行緒，它也執行 a++。再次切回來的時候 a 的值其實就已經不對了。
這個問題叫做原子性問題
。
並且編譯器或直譯器為了最佳化效能，可能會改變語句的執行順序，這叫指令重排，最經典的例子莫過於單例模式的雙重檢查了。而 CPU 為了提高執行效率，還會亂序執行，例如 CPU 在等待記憶體資料載入的時候發現後面的加法指令不依賴前面指令的計算結果，因此它就先執行了這條加法指令。
這個問題就叫有序性問題
。
至此已經分析完了併發 BUG 的源頭，即這三大問題。可以看到不管是 CPU 快取、多核 CPU 、高階語言還是亂序重排其實都是必要的存在，所以我們只能直面這些問題。
而解決這些問題就是透過禁用快取、禁止編譯器指令重排、互斥等手段，今天我們的主題和互斥相關。
互斥就是保證對共享變數的修改是互斥的，即同一時刻只有一個執行緒在執行。而說到互斥相信大家腦海中浮現的就是
鎖
。沒錯，我們今天的主題就是鎖！鎖就是為了解決原子性問題。
鎖
說到鎖可能 Java 的同學第一反應就是 synchronized 關鍵字，畢竟是語言層面支援的。我們就先來看看 synchronized，有些同學對 synchronized 理解不到位所以用起來會有很多坑。
synchronized 注意點
我們先來看一份程式碼，這段程式碼就是咱們的漲工資之路，最終百萬是灑灑水的。而一個執行緒時刻的對比著我們工資是不是相等的。我簡單說一下IntStream。rangeClosed（1，1000000）。forEach，可能有些人對這個不太熟悉，這個程式碼的就等於 for 迴圈了100W次。
你先自己理解下，看看覺得有沒有什麼問題？第一反應好像沒問題，你看著漲工資就一個執行緒執行著，這比工資也沒有修改值，看起來好像沒啥毛病？沒有啥併發資源的競爭，也用 volatile 修飾了保證了可見性。
讓我們來看一下結果，我截取了一部分。
可以看到首先有 log 打出來就已經不對了，
其次打出來的值竟然還相等
！有沒有出乎你的意料之外？有同學可能下意識就想到這就raiseSalary在修改，所以肯定是執行緒安全問題來給raiseSalary 加個鎖！
請注意只有一個執行緒在呼叫raiseSalary方法，所以單給raiseSalary方法加鎖並沒啥用。
這其實就是我上面提到的原子性問題，想象一下漲工資執行緒在執行完yesSalary++還未執行yourSalary++時，比工資執行緒剛好執行到yesSalary ！= yourSalary 是不是肯定是 true ？所以才會打印出 log。
再者由於用 volatile 修飾保證了可見性，所以當打 log 的時候，可能yourSalary++已經執行完了，這時候打出來的 log 才會是yesSalary == yourSalary。
所以最簡單的解決辦法就是把raiseSalary（） 和 compareSalary（） 都用 synchronized 修飾，這樣漲工資和比工資兩個執行緒就不會在同一時刻執行，因此肯定就安全了！
看起來鎖好像也挺簡單，不過這個 synchronized 的使用還是對於新手來說還是有坑的，就是你要關注 synchronized 鎖的究竟是什麼。
比如我改成多執行緒來漲工資。這裡再提一下parallel，這個其實就是利用了 ForkJoinPool 執行緒池操作，預設執行緒數是 CPU 核心數。
由於 raiseSalary（） 加了鎖，所以最終的結果是對的。這是因為 synchronized 修飾的是yesLockDemo例項，我們的 main 中只有一個例項，所以等於多執行緒競爭的是一把鎖，所以最終計算出來的資料正確。
那我再修改下程式碼，讓每個執行緒自己有一個 yesLockDemo 例項來漲工資。
你會發現這鎖怎麼沒用了？這說好的百萬年薪我就變 10w 了？？這你還好還有 70w。
這是因為此時我們的
鎖修飾的是非靜態方法，是例項級別的鎖
，而我們為每個執行緒都建立了一個例項，因此這幾個執行緒競爭的就根本
不是一把鎖
，而上面多執行緒計算正確程式碼是因為每個執行緒用的是同一個例項，所以競爭的是一把鎖。如果想要此時的程式碼正確，只需要把
例項級別的鎖變成類級別的鎖
。
很簡單隻需要把這個方法變成靜態方法，
synchronized 修飾靜態方法就是類級別的鎖
。
還有一種就是宣告一個靜態變數，比較推薦這種，因為把非靜態方法變成靜態方法其實就等於改了程式碼結構了。
我們來小結一下，使用 synchronized 的時候需要注意鎖的到底是什麼，
如果修飾靜態欄位和靜態方法那就是類級別的鎖，如果修飾非靜態欄位和非靜態方法就是例項級別的鎖
。
鎖的粒度
相信大家知道 Hashtable 不被推薦使用，要用就用 ConcurrentHashMap，是因為 Hashtable 雖然是執行緒安全的，但是它太粗暴了，它為所有的方法都上了同一把鎖！我們來看下原始碼。
你說這 contains 和 size 方法有啥關係？ 我在呼叫 contains 的時候憑啥不讓我調 size ？ 這就是鎖的粒度太粗了我們得評估一下，不同的方法用不同的鎖，這樣才能線上程安全的情況下再提高併發度。
但是不同方法不同鎖還不夠的，因為有時候一個方法裡面有些操作其實是執行緒安全的，
只有涉及競爭競態資源的那一段程式碼才需要加鎖
。特別是不需要鎖的程式碼很耗時的情況，就會長時間佔著這把鎖，而且其他執行緒只能排隊等著，比如下面這段程式碼。
很明顯第二段程式碼才是正常的使用鎖的姿勢，不過在平時的業務程式碼中可不是像我程式碼裡貼的 sleep 這麼容易一眼就看出的，
有時候還需要修改程式碼執行的順序等等來保證鎖的粒度足夠細
。
而有時候又需要保證鎖足夠的粗，不過這部分JVM會檢測到，它會幫我們做最佳化，比如下面的程式碼。
可以看到明明是一個方法裡面呼叫的邏輯卻經歷了加鎖-執行A-解鎖-加鎖-執行B-解鎖，很明顯的可以看出其實只需要經歷加鎖-執行A-執行B-解鎖。
所以 JVM 會在即時編譯的時候做鎖的粗化，將鎖的範圍擴大，類似變成下面的情況。
而且 JVM 還會有
鎖消除
的動作，
透過逃逸分析判斷例項物件是執行緒私有的
，那麼肯定是執行緒安全的，於是就會忽略物件裡面的加鎖動作，直接呼叫。
讀寫鎖
讀寫鎖就是我們上面提交的根據場景減小鎖的粒度了，
把一個鎖拆成了讀鎖和寫鎖，特別適合在讀多寫少的情況下使用
，例如自己實現的一個快取。
ReentrantReadWriteLock
讀寫鎖
允許多個執行緒同時讀共享變數
，但是寫操作是互斥的，即寫寫互斥、讀寫互斥。講白了就是寫的時候就只能一個執行緒寫，其他執行緒也讀不了也寫不了。
我們來看個小例子，裡面也有個小細節。這段程式碼就是模擬快取的讀取，先上讀鎖去快取拿資料，如果快取沒資料則釋放讀鎖，再上寫鎖去資料庫取資料，然後塞入快取中返回。
這裡面的小細節就是再次判斷 data = getFromCache（） 是否有值，因為同一時刻可能會有多個執行緒呼叫getData（），然後快取都為空因此都去競爭寫鎖，最終只有一個執行緒會先拿到寫鎖，然後將資料又塞入快取中。
此時等待的執行緒最終一個個的都會拿到寫鎖，獲取寫鎖的時候其實快取裡面已經有值了所以沒必要再去資料庫查詢。
當然 Lock 的使用正規化大家都知道，需要用 try- finally，來保證一定會解鎖。而讀寫鎖還有一個要點需要注意，也就是說
鎖不能升級
。什麼意思呢？我改一下上面的程式碼。
但是寫鎖內可以再用讀鎖，來實現
鎖的降級
，有些人可能會問了這寫鎖都加了還要什麼讀鎖。
還是有點用處的，比如某個執行緒搶到了寫鎖，在寫的動作要完畢的時候加上讀鎖，接著釋放了寫鎖，
此時它還持有讀鎖可以保證能馬上使用寫鎖操作完的資料，而別的執行緒也因為此時寫鎖已經沒了也能讀資料
。
其實就是當前已經不需要寫鎖這種比較霸道的鎖，所以來降個級讓大家都能讀。
小結一下，
讀寫鎖適用於讀多寫少的情況，無法升級，但是可以降級
。Lock 的鎖需要配合 try- finally，來保證一定會解鎖。
對了，我再稍稍提一下
讀寫鎖的實現
，熟悉 AQS 的同學可能都知道里面的 state ，讀寫鎖就是將這個 int 型別的 state 分成了兩半，高 16 位與低 16 位分別記錄讀鎖和寫鎖的狀態。
它和普通的互斥鎖的區別就在於要維護這兩個狀態和在等待佇列處區別處理這兩種鎖
。
所以
在不適用於讀寫鎖的場景還不如直接用互斥鎖
，因為讀寫鎖還需要對state進行位移判斷等等操作。
StampedLock
這玩意我也稍微提一下，是 1。8 提出來的出鏡率似乎沒有 ReentrantReadWriteLock 高。它支援寫鎖、悲觀讀鎖和樂觀讀。寫鎖和悲觀讀鎖其實和 ReentrantReadWriteLock 裡面的讀寫鎖是一致的，它就多了個樂觀讀。
從上面的分析我們知道讀寫鎖在讀的時候其實是無法寫的，
而 StampedLock 的樂觀
讀
則允許一個執行緒寫
。樂觀讀其實就是和我們知道的資料庫樂觀鎖一樣，資料庫的樂觀鎖例如透過一個version欄位來判斷，例如下面這條 sql。
StampedLock 樂觀讀就是與其類似，我們來看一下簡單的用法。
它與 ReentrantReadWriteLock 對比也就強在這裡，其他的不行，比如 StampedLock 不支援重入，不支援條件變數。
還有一點使用 StampedLock 一定不要呼叫中斷操作，因為會導致CPU 100%
，我跑了下併發程式設計網上面提供的例子，復現了。
具體的原因這裡不再贅述，文末會貼上鍊接，上面說的很詳細了。
所以出來一個看似好像很厲害的東西，你需要真正的去理解它，熟悉它才能做到有的放矢。
CopyOnWrite
寫時複製的在很多地方也會用到，比如程序 fork（） 操作。對於我們業務程式碼層面而言也是很有幫助的，在於它的讀操作不會阻塞寫，寫操作也不會阻塞讀。適用於讀多寫少的場景。
例如 Java 中的實現 CopyOnWriteArrayList，有人可能一聽，這玩意執行緒安全讀的時候還不會阻塞寫，好傢伙就用它了！
你得先搞清楚，
寫時複製是會複製一份資料
，你的任何一個修改動作在CopyOnWriteArrayList 中都會觸發一次Arrays。copyOf，然後在副本上修改。假如修改的動作很多，並且複製的資料也很大，這將是災難！
併發安全容器
最後再來談一下併發安全容器的使用，我就拿相對而言大家比較熟悉的 ConcurrentHashMap 來作為例子。我看新來的同事好像認為只要是使用併發安全容器一定就是執行緒安全了。其實不盡然，還得看怎麼用。
我們先來看下以下的程式碼，簡單的說就是利用 ConcurrentHashMap 來記錄每個人的工資，最多就記錄 100 個。
最終的結果都會超標，即 map 裡面不僅僅只記錄了100個人。那怎麼樣結果才會是對的？很簡單就是加個鎖。
看到這有人說，你這都加鎖了我還用啥 ConcurrentHashMap ，我 HashMap 加個鎖也能完事！是的你說的沒錯！因為當前我們的使用場景是複合型操作，也就是我們先拿 map 的 size 做了判斷，然後再執行了 put 方法，ConcurrentHashMap
無法保證複合型的操作是執行緒安全的
！
而 ConcurrentHashMap 合適只是用其暴露出來的執行緒安全的方法，而不是複合操作的情況下。比如以下程式碼
當然，我這個例子不夠恰當其實，因為 ConcurrentHashMap 效能比 HashMap + 鎖高的原因在於分段鎖，需要多個 key 操作才能體現出來，不過我想突出的重點是使用的時候不能大意，不能純粹的認為用了就執行緒安全了。
總結一下
今天談了談併發 BUG 的源頭，即三大問題：可見性問題、原子性問題和有序性問題。然後簡單的說了下 synchronized 關鍵字的注意點，即修飾靜態欄位或者靜態方法是類層面的鎖，而修飾非靜態欄位和非靜態方法是例項層面的類。
再說了下鎖的粒度，在不同場景定義不同的鎖不能粗暴的一把鎖搞定，並且方法內部鎖的粒度要細。例如在讀多寫少的場景可以使用讀寫鎖、寫時複製等。
最終要正確的使用併發安全容器，不能一味的認為使用併發安全容器就一定執行緒安全了，要注意複合操作的場景。
當然我今天只是淺淺的談了一下，關於併發程式設計其實還有很多點，要寫出執行緒安全的程式碼不是一件容易的事情，就像我之前分析的 Kafka 事件處理全流程一樣，原先的版本就是各種鎖控制併發安全，到後來bug根本修不動，多執行緒程式設計難，除錯也難，修bug也難。
因此 Kafka 事件處理模組最終改成了
單執行緒事件佇列模式
，
將涉及到共享資料競爭相關方面的訪問抽象成事件，將事件塞入阻塞佇列中，然後單執行緒處理
。
所以在用鎖之前我們要先想想，有必要麼？能簡化麼？不然之後維護起來有多痛苦到時候你就知道了。
最後
之後繼續開始寫訊息佇列相關的包括 RocketMQ 和 Kafka，有不少同學在後臺留言想和我深入的交流一下，發生點關係，我把公眾號選單加了個聯絡我，有需求的小夥伴可以加我。
StampedLock bug 的那個連結：http：//ifeve。com/stampedlock-bug-cpu/
我是 yes，從一點點到
億點點
，我們下篇見
。
