此部落格為轉載,原地址:https://blog.csdn.net/zqz_zqz/article/details/70233767

最近在看Java基礎知識時，看到了這片文章，相見恨晚，轉載下來以後慢慢消化

理解鎖的基礎知識

如果想要透徹的理解java鎖的來龍去脈，需要先了解以下基礎知識。

基礎知識之一：鎖的型別

鎖從巨集觀上分類，分為悲觀鎖與樂觀鎖。

樂觀鎖

樂觀鎖是一種樂觀思想，即認為讀多寫少，遇到併發寫的可能性低，每次去拿資料的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個資料，採取在寫時先讀出當前版本號，然後加鎖操作（比較跟上一次的版本號，如果一樣則更新），如果失敗則要重複讀-比較-寫的操作。

java中的樂觀鎖基本都是通過CAS操作實現的，CAS是一種更新的原子操作，比較當前值跟傳入值是否一樣，一樣則更新，否則失敗。

悲觀鎖

悲觀鎖是就是悲觀思想，即認為寫多，遇到併發寫的可能性高，每次去拿資料的時候都認為別人會修改，所以每次在讀寫資料的時候都會上鎖，這樣別人想讀寫這個資料就會block直到拿到鎖。java中的悲觀鎖就是Synchronized,AQS框架下的鎖則是先嚐試cas樂觀鎖去獲取鎖，獲取不到，才會轉換為悲觀鎖，如RetreenLock。

基礎知識之二：java執行緒阻塞的代價

java的執行緒是對映到作業系統原生執行緒之上的，如果要阻塞或喚醒一個執行緒就需要作業系統介入，需要在戶態與核心態之間切換，這種切換會消耗大量的系統資源，因為使用者態與核心態都有各自專用的記憶體空間，專用的暫存器等，使用者態切換至核心態需要傳遞給許多變數、引數給核心，核心也需要保護好使用者態在切換時的一些暫存器值、變數等，以便核心態呼叫結束後切換回使用者態繼續工作。

如果執行緒狀態切換是一個高頻操作時，這將會消耗很多CPU處理時間；
如果對於那些需要同步的簡單的程式碼塊，獲取鎖掛起操作消耗的時間比使用者程式碼執行的時間還要長，這種同步策略顯然非常糟糕的。

synchronized會導致爭用不到鎖的執行緒進入阻塞狀態，所以說它是java語言中一個重量級的同步操縱，被稱為重量級鎖，為了緩解上述效能問題，JVM從1.5開始，引入了輕量鎖與偏向鎖，預設啟用了自旋鎖，他們都屬於樂觀鎖。

明確java執行緒切換的代價，是理解java中各種鎖的優缺點的基礎之一。

基礎知識之三：markword

在介紹java鎖之前，先說下什麼是markword，markword是java物件資料結構中的一部分，要詳細瞭解java物件的結構可以點選這裡,這裡只做markword的詳細介紹，因為物件的markword和java各種型別的鎖密切相關；

markword資料的長度在32位和64位的虛擬機器（未開啟壓縮指標）中分別為32bit和64bit，它的最後2bit是鎖狀態標誌位，用來標記當前物件的狀態，物件的所處的狀態，決定了markword儲存的內容，如下表所示:

狀態	標誌位	儲存內容
未鎖定	01	物件雜湊碼、物件分代年齡
輕量級鎖定	00	指向鎖記錄的指標
膨脹(重量級鎖定)	10	執行重量級鎖定的指標
GC標記	11	空(不需要記錄資訊)
可偏向	01	偏向執行緒ID、偏向時間戳、物件分代年齡

32位虛擬機器在不同狀態下markword結構如下圖所示：

è¿éåå¾çæè¿°

瞭解了markword結構，有助於後面瞭解java鎖的加鎖解鎖過程；

小結

前面提到了java的4種鎖，他們分別是重量級鎖、自旋鎖、輕量級鎖和偏向鎖，
不同的鎖有不同特點，每種鎖只有在其特定的場景下，才會有出色的表現，java中沒有哪種鎖能夠在所有情況下都能有出色的效率，引入這麼多鎖的原因就是為了應對不同的情況；

前面講到了重量級鎖是悲觀鎖的一種，自旋鎖、輕量級鎖與偏向鎖屬於樂觀鎖，所以現在你就能夠大致理解了他們的適用範圍，但是具體如何使用這幾種鎖呢，就要看後面的具體分析他們的特性；

java中的鎖

自旋鎖

自旋鎖原理非常簡單，如果持有鎖的執行緒能在很短時間內釋放鎖資源，那麼那些等待競爭鎖的執行緒就不需要做核心態和使用者態之間的切換進入阻塞掛起狀態，它們只需要等一等（自旋），等持有鎖的執行緒釋放鎖後即可立即獲取鎖，這樣就避免使用者執行緒和核心的切換的消耗。

但是執行緒自旋是需要消耗cup的，說白了就是讓cup在做無用功，如果一直獲取不到鎖，那執行緒也不能一直佔用cup自旋做無用功，所以需要設定一個自旋等待的最大時間。

如果持有鎖的執行緒執行的時間超過自旋等待的最大時間扔沒有釋放鎖，就會導致其它爭用鎖的執行緒在最大等待時間內還是獲取不到鎖，這時爭用執行緒會停止自旋進入阻塞狀態。

自旋鎖的優缺點

自旋鎖儘可能的減少執行緒的阻塞，這對於鎖的競爭不激烈，且佔用鎖時間非常短的程式碼塊來說效能能大幅度的提升，因為自旋的消耗會小於執行緒阻塞掛起再喚醒的操作的消耗，這些操作會導致執行緒發生兩次上下文切換！

但是如果鎖的競爭激烈，或者持有鎖的執行緒需要長時間佔用鎖執行同步塊，這時候就不適合使用自旋鎖了，因為自旋鎖在獲取鎖前一直都是佔用cpu做無用功，佔著XX不XX，同時有大量執行緒在競爭一個鎖，會導致獲取鎖的時間很長，執行緒自旋的消耗大於執行緒阻塞掛起操作的消耗，其它需要cup的執行緒又不能獲取到cpu，造成cpu的浪費。所以這種情況下我們要關閉自旋鎖；

自旋鎖時間閾值

自旋鎖的目的是為了佔著CPU的資源不釋放，等到獲取到鎖立即進行處理。但是如何去選擇自旋的執行時間呢？如果自旋執行時間太長，會有大量的執行緒處於自旋狀態佔用CPU資源，進而會影響整體系統的效能。因此自旋的週期選的額外重要！

JVM對於自旋週期的選擇，jdk1.5這個限度是一定的寫死的，在1.6引入了適應性自旋鎖，適應性自旋鎖意味著自旋的時間不在是固定的了，而是由前一次在同一個鎖上的自旋時間以及鎖的擁有者的狀態來決定，基本認為一個執行緒上下文切換的時間是最佳的一個時間，同時JVM還針對當前CPU的負荷情況做了較多的優化

如果平均負載小於CPUs則一直自旋
如果有超過(CPUs/2)個執行緒正在自旋，則後來執行緒直接阻塞
如果正在自旋的執行緒發現Owner發生了變化則延遲自旋時間（自旋計數）或進入阻塞
如果CPU處於節電模式則停止自旋
自旋時間的最壞情況是CPU的儲存延遲（CPU A儲存了一個資料，到CPU B得知這個資料直接的時間差）
自旋時會適當放棄執行緒優先順序之間的差異

自旋鎖的開啟

JDK1.6中-XX:+UseSpinning開啟；
-XX:PreBlockSpin=10 為自旋次數；
JDK1.7後，去掉此引數，由jvm控制；

重量級鎖Synchronized

Synchronized的作用

在JDK1.5之前都是使用synchronized關鍵字保證同步的，Synchronized的作用相信大家都已經非常熟悉了；

它可以把任意一個非NULL的物件當作鎖。

作用於方法時，鎖住的是物件的例項(this)；
當作用於靜態方法時，鎖住的是Class例項，又因為Class的相關資料儲存在永久帶PermGen（jdk1.8則是metaspace），永久帶是全域性共享的，因此靜態方法鎖相當於類的一個全域性鎖，會鎖所有呼叫該方法的執行緒；
synchronized作用於一個物件例項時，鎖住的是所有以該物件為鎖的程式碼塊。

Synchronized的實現

實現如下圖所示；

è¿éåå¾çæè¿°

它有多個佇列，當多個執行緒一起訪問某個物件監視器的時候，物件監視器會將這些執行緒儲存在不同的容器中。

Contention List：競爭佇列，所有請求鎖的執行緒首先被放在這個競爭佇列中；
Entry List：Contention List中那些有資格成為候選資源的執行緒被移動到Entry List中；
Wait Set：哪些呼叫wait方法被阻塞的執行緒被放置在這裡；
OnDeck：任意時刻，最多隻有一個執行緒正在競爭鎖資源，該執行緒被成為OnDeck；
Owner：當前已經獲取到所資源的執行緒被稱為Owner；
!Owner：當前釋放鎖的執行緒。

JVM每次從佇列的尾部取出一個資料用於鎖競爭候選者（OnDeck），但是併發情況下，ContentionList會被大量的併發執行緒進行CAS訪問，為了降低對尾部元素的競爭，JVM會將一部分執行緒移動到EntryList中作為候選競爭執行緒。Owner執行緒會在unlock時，將ContentionList中的部分執行緒遷移到EntryList中，並指定EntryList中的某個執行緒為OnDeck執行緒（一般是最先進去的那個執行緒）。Owner執行緒並不直接把鎖傳遞給OnDeck執行緒，而是把鎖競爭的權利交給OnDeck，OnDeck需要重新競爭鎖。這樣雖然犧牲了一些公平性，但是能極大的提升系統的吞吐量，在JVM中，也把這種選擇行為稱之為“競爭切換”。

OnDeck執行緒獲取到鎖資源後會變為Owner執行緒，而沒有得到鎖資源的仍然停留在EntryList中。如果Owner執行緒被wait方法阻塞，則轉移到WaitSet佇列中，直到某個時刻通過notify或者notifyAll喚醒，會重新進去EntryList中。

處於ContentionList、EntryList、WaitSet中的執行緒都處於阻塞狀態，該阻塞是由作業系統來完成的（Linux核心下采用pthread_mutex_lock核心函式實現的）。

Synchronized是非公平鎖。 Synchronized線上程進入ContentionList時，等待的執行緒會先嚐試自旋獲取鎖，如果獲取不到就進入ContentionList，這明顯對於已經進入佇列的執行緒是不公平的，還有一個不公平的事情就是自旋獲取鎖的執行緒還可能直接搶佔OnDeck執行緒的鎖資源。

偏向鎖

Java偏向鎖(Biased Locking)是Java6引入的一項多執行緒優化。
偏向鎖，顧名思義，它會偏向於第一個訪問鎖的執行緒，如果在執行過程中，同步鎖只有一個執行緒訪問，不存在多執行緒爭用的情況，則執行緒是不需要觸發同步的，這種情況下，就會給執行緒加一個偏向鎖。
如果在執行過程中，遇到了其他執行緒搶佔鎖，則持有偏向鎖的執行緒會被掛起，JVM會消除它身上的偏向鎖，將鎖恢復到標準的輕量級鎖。

它通過消除資源無競爭情況下的同步原語，進一步提高了程式的執行效能。

偏向鎖的實現

偏向鎖獲取過程：

訪問Mark Word中偏向鎖的標識是否設定成1，鎖標誌位是否為01，確認為可偏向狀態。
如果為可偏向狀態，則測試執行緒ID是否指向當前執行緒，如果是，進入步驟5，否則進入步驟3。
如果執行緒ID並未指向當前執行緒，則通過CAS操作競爭鎖。如果競爭成功，則將Mark Word中執行緒ID設定為當前執行緒ID，然後執行5；如果競爭失敗，執行4。
如果CAS獲取偏向鎖失敗，則表示有競爭。當到達全域性安全點（safepoint）時獲得偏向鎖的執行緒被掛起，偏向鎖升級為輕量級鎖，然後被阻塞在安全點的執行緒繼續往下執行同步程式碼。（撤銷偏向鎖的時候會導致stop the word）
執行同步程式碼。

注意：第四步中到達安全點safepoint會導致stop the word，時間很短。

偏向鎖的釋放：

偏向鎖的撤銷在上述第四步驟中有提到。偏向鎖只有遇到其他執行緒嘗試競爭偏向鎖時，持有偏向鎖的執行緒才會釋放鎖，執行緒不會主動去釋放偏向鎖。偏向鎖的撤銷，需要等待全域性安全點（在這個時間點上沒有位元組碼正在執行），它會首先暫停擁有偏向鎖的執行緒，判斷鎖物件是否處於被鎖定狀態，撤銷偏向鎖後恢復到未鎖定（標誌位為“01”）或輕量級鎖（標誌位為“00”）的狀態。

偏向鎖的適用場景

始終只有一個執行緒在執行同步塊，在它沒有執行完釋放鎖之前，沒有其它執行緒去執行同步塊，在鎖無競爭的情況下使用，一旦有了競爭就升級為輕量級鎖，升級為輕量級鎖的時候需要撤銷偏向鎖，撤銷偏向鎖的時候會導致stop the word操作；
在有鎖的競爭時，偏向鎖會多做很多額外操作，尤其是撤銷偏向所的時候會導致進入安全點，安全點會導致stw，導致效能下降，這種情況下應當禁用；

檢視停頓–安全點停頓日誌

要檢視安全點停頓，可以開啟安全點日誌，通過設定JVM引數 -XX:+PrintGCApplicationStoppedTime 會打出系統停止的時間，新增-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 這兩個引數會列印出詳細資訊，可以檢視到使用偏向鎖導致的停頓，時間非常短暫，但是爭用嚴重的情況下，停頓次數也會非常多；

注意：安全點日誌不能一直開啟：
1. 安全點日誌預設輸出到stdout，一是stdout日誌的整潔性，二是stdout所重定向的檔案如果不在/dev/shm，可能被鎖。
2. 對於一些很短的停頓，比如取消偏向鎖，列印的消耗比停頓本身還大。
3. 安全點日誌是在安全點內列印的，本身加大了安全點的停頓時間。

所以安全日誌應該只在問題排查時開啟。
如果在生產系統上要開啟，再再增加下面四個引數：
-XX:+UnlockDiagnosticVMOptions -XX: -DisplayVMOutput -XX:+LogVMOutput -XX:LogFile=/dev/shm/vm.log
開啟Diagnostic（只是開放了更多的flag可選，不會主動啟用某個flag），關掉輸出VM日誌到stdout，輸出到獨立檔案,/dev/shm目錄（記憶體檔案系統）。

這裡寫圖片描述

此日誌分三部分：
第一部分是時間戳，VM Operation的型別
第二部分是執行緒概況，被中括號括起來
total: 安全點裡的匯流排程數
initially_running: 安全點開始時正在執行狀態的執行緒數
wait_to_block: 在VM Operation開始前需要等待其暫停的執行緒數

第三部分是到達安全點時的各個階段以及執行操作所花的時間，其中最重要的是vmop

spin: 等待執行緒響應safepoint號召的時間；
block: 暫停所有執行緒所用的時間；
sync: 等於 spin+block，這是從開始到進入安全點所耗的時間，可用於判斷進入安全點耗時；
cleanup: 清理所用時間；
vmop: 真正執行VM Operation的時間。

可見，那些很多但又很短的安全點，全都是RevokeBias，高併發的應用會禁用掉偏向鎖。

jvm開啟/關閉偏向鎖

開啟偏向鎖：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
關閉偏向鎖：-XX:-UseBiasedLocking

輕量級鎖

輕量級鎖是由偏向所升級來的，偏向鎖執行在一個執行緒進入同步塊的情況下，當第二個執行緒加入鎖爭用的時候，偏向鎖就會升級為輕量級鎖；
輕量級鎖的加鎖過程：

在程式碼進入同步塊的時候，如果同步物件鎖狀態為無鎖狀態（鎖標誌位為“01”狀態，是否為偏向鎖為“0”），虛擬機器首先將在當前執行緒的棧幀中建立一個名為鎖記錄（Lock Record）的空間，用於儲存鎖物件目前的Mark Word的拷貝，官方稱之為 Displaced Mark Word。這時候執行緒堆疊與物件頭的狀態如圖：
　　所示。
拷貝物件頭中的Mark Word複製到鎖記錄中；
拷貝成功後，虛擬機器將使用CAS操作嘗試將物件的Mark Word更新為指向Lock Record的指標，並將Lock record裡的owner指標指向object mark word。如果更新成功，則執行步驟4，否則執行步驟5。
如果這個更新動作成功了，那麼這個執行緒就擁有了該物件的鎖，並且物件Mark Word的鎖標誌位設定為“00”，即表示此物件處於輕量級鎖定狀態，這時候執行緒堆疊與物件頭的狀態如圖所示。
　　
如果這個更新操作失敗了，虛擬機器首先會檢查物件的Mark Word是否指向當前執行緒的棧幀，如果是就說明當前執行緒已經擁有了這個物件的鎖，那就可以直接進入同步塊繼續執行。否則說明多個執行緒競爭鎖，輕量級鎖就要膨脹為重量級鎖，鎖標誌的狀態值變為“10”，Mark Word中儲存的就是指向重量級鎖（互斥量）的指標，後面等待鎖的執行緒也要進入阻塞狀態。而當前執行緒便嘗試使用自旋來獲取鎖，自旋就是為了不讓執行緒阻塞，而採用迴圈去獲取鎖的過程。

輕量級鎖的釋放

釋放鎖執行緒視角：由輕量鎖切換到重量鎖，是發生在輕量鎖釋放鎖的期間，之前在獲取鎖的時候它拷貝了鎖物件頭的markword，在釋放鎖的時候如果它發現在它持有鎖的期間有其他執行緒來嘗試獲取鎖了，並且該執行緒對markword做了修改，兩者比對發現不一致，則切換到重量鎖。

因為重量級鎖被修改了，所有display mark word和原來的markword不一樣了。

怎麼補救，就是進入mutex前，compare一下obj的markword狀態。確認該markword是否被其他執行緒持有。

此時如果執行緒已經釋放了markword，那麼通過CAS後就可以直接進入執行緒，無需進入mutex，就這個作用。

嘗試獲取鎖執行緒視角：如果執行緒嘗試獲取鎖的時候，輕量鎖正被其他執行緒佔有，那麼它就會修改markword，修改重量級鎖，表示該進入重量鎖了。

還有一個注意點：等待輕量鎖的執行緒不會阻塞，它會一直自旋等待鎖，並如上所說修改markword。

這就是自旋鎖，嘗試獲取鎖的執行緒，在沒有獲得鎖的時候，不被掛起，而轉而去執行一個空迴圈，即自旋。在若干個自旋後，如果還沒有獲得鎖，則才被掛起，獲得鎖，則執行程式碼。

總結

這裡寫圖片描述

synchronized的執行過程：
1. 檢測Mark Word裡面是不是當前執行緒的ID，如果是，表示當前執行緒處於偏向鎖
2. 如果不是，則使用CAS將當前執行緒的ID替換Mard Word，如果成功則表示當前執行緒獲得偏向鎖，置偏向標誌位1
3. 如果失敗，則說明發生競爭，撤銷偏向鎖，進而升級為輕量級鎖。
4. 當前執行緒使用CAS將物件頭的Mark Word替換為鎖記錄指標，如果成功，當前執行緒獲得鎖
5. 如果失敗，表示其他執行緒競爭鎖，當前執行緒便嘗試使用自旋來獲取鎖。
6. 如果自旋成功則依然處於輕量級狀態。
7. 如果自旋失敗，則升級為重量級鎖。

上面幾種鎖都是JVM自己內部實現，當我們執行synchronized同步塊的時候jvm會根據啟用的鎖和當前執行緒的爭用情況，決定如何執行同步操作；

在所有的鎖都啟用的情況下執行緒進入臨界區時會先去獲取偏向鎖，如果已經存在偏向鎖了，則會嘗試獲取輕量級鎖，啟用自旋鎖，如果自旋也沒有獲取到鎖，則使用重量級鎖，沒有獲取到鎖的執行緒阻塞掛起，直到持有鎖的執行緒執行完同步塊喚醒他們；

偏向鎖是在無鎖爭用的情況下使用的，也就是同步開在當前執行緒沒有執行完之前，沒有其它執行緒會執行該同步塊，一旦有了第二個執行緒的爭用，偏向鎖就會升級為輕量級鎖，如果輕量級鎖自旋到達閾值後，沒有獲取到鎖，就會升級為重量級鎖；

如果執行緒爭用激烈，那麼應該禁用偏向鎖。

鎖優化

以上介紹的鎖不是我們程式碼中能夠控制的，但是借鑑上面的思想，我們可以優化我們自己執行緒的加鎖操作；

減少鎖的時間

不需要同步執行的程式碼，能不放在同步快裡面執行就不要放在同步快內，可以讓鎖儘快釋放；

減少鎖的粒度

它的思想是將物理上的一個鎖，拆成邏輯上的多個鎖，增加並行度，從而降低鎖競爭。它的思想也是用空間來換時間；

java中很多資料結構都是採用這種方法提高併發操作的效率：

ConcurrentHashMap

java中的ConcurrentHashMap在jdk1.8之前的版本，使用一個Segment 陣列

Segment< K,V >[] segments

1

Segment繼承自ReenTrantLock，所以每個Segment就是個可重入鎖，每個Segment 有一個HashEntry< K,V >陣列用來存放資料，put操作時，先確定往哪個Segment放資料，只需要鎖定這個Segment，執行put，其它的Segment不會被鎖定；所以陣列中有多少個Segment就允許同一時刻多少個執行緒存放資料，這樣增加了併發能力。

LongAdder

LongAdder 實現思路也類似ConcurrentHashMap，LongAdder有一個根據當前併發狀況動態改變的Cell陣列，Cell物件裡面有一個long型別的value用來儲存值;
開始沒有併發爭用的時候或者是cells陣列正在初始化的時候，會使用cas來將值累加到成員變數的base上，在併發爭用的情況下，LongAdder會初始化cells陣列，在Cell陣列中選定一個Cell加鎖，陣列有多少個cell，就允許同時有多少執行緒進行修改，最後將陣列中每個Cell中的value相加，在加上base的值，就是最終的值；cell陣列還能根據當前執行緒爭用情況進行擴容，初始長度為2，每次擴容會增長一倍，直到擴容到大於等於cpu數量就不再擴容，這也就是為什麼LongAdder比cas和AtomicInteger效率要高的原因，後面兩者都是volatile+cas實現的，他們的競爭維度是1，LongAdder的競爭維度為“Cell個數+1”為什麼要+1？因為它還有一個base，如果競爭不到鎖還會嘗試將數值加到base上；

LinkedBlockingQueue

LinkedBlockingQueue也體現了這樣的思想，在佇列頭入隊，在佇列尾出隊，入隊和出隊使用不同的鎖，相對於LinkedBlockingArray只有一個鎖效率要高；

拆鎖的粒度不能無限拆，最多可以將一個鎖拆為當前cup數量個鎖即可；

鎖粗化

大部分情況下我們是要讓鎖的粒度最小化，鎖的粗化則是要增大鎖的粒度;
在以下場景下需要粗化鎖的粒度：
假如有一個迴圈，迴圈內的操作需要加鎖，我們應該把鎖放到迴圈外面，否則每次進出迴圈，都進出一次臨界區，效率是非常差的；

使用讀寫鎖

ReentrantReadWriteLock 是一個讀寫鎖，讀操作加讀鎖，可以併發讀，寫操作使用寫鎖，只能單執行緒寫；

讀寫分離

CopyOnWriteArrayList 、CopyOnWriteArraySet
CopyOnWrite容器即寫時複製的容器。通俗的理解是當我們往一個容器新增元素的時候，不直接往當前容器新增，而是先將當前容器進行Copy，複製出一個新的容器，然後新的容器裡新增元素，新增完元素之後，再將原容器的引用指向新的容器。這樣做的好處是我們可以對CopyOnWrite容器進行併發的讀，而不需要加鎖，因為當前容器不會新增任何元素。所以CopyOnWrite容器也是一種讀寫分離的思想，讀和寫不同的容器。
　CopyOnWrite併發容器用於讀多寫少的併發場景，因為，讀的時候沒有鎖，但是對其進行更改的時候是會加鎖的，否則會導致多個執行緒同時複製出多個副本，各自修改各自的；

使用cas

如果需要同步的操作執行速度非常快，並且執行緒競爭並不激烈，這時候使用cas效率會更高，因為加鎖會導致執行緒的上下文切換，如果上下文切換的耗時比同步操作本身更耗時，且執行緒對資源的競爭不激烈，使用volatiled+cas操作會是非常高效的選擇；

消除快取行的偽共享

除了我們在程式碼中使用的同步鎖和jvm自己內建的同步鎖外，還有一種隱藏的鎖就是快取行，它也被稱為效能殺手。
在多核cup的處理器中，每個cup都有自己獨佔的一級快取、二級快取，甚至還有一個共享的三級快取，為了提高效能，cpu讀寫資料是以快取行為最小單元讀寫的；32位的cpu快取行為32位元組，64位cup的快取行為64位元組，這就導致了一些問題。
例如，多個不需要同步的變數因為儲存在連續的32位元組或64位元組裡面，當需要其中的一個變數時，就將它們作為一個快取行一起載入到某個cup-1私有的快取中（雖然只需要一個變數，但是cpu讀取會以快取行為最小單位，將其相鄰的變數一起讀入），被讀入cpu快取的變數相當於是對主記憶體變數的一個拷貝，也相當於變相的將在同一個快取行中的幾個變數加了一把鎖，這個快取行中任何一個變數發生了變化，當cup-2需要讀取這個快取行時，就需要先將cup-1中被改變了的整個快取行更新回主存（即使其它變數沒有更改），然後cup-2才能夠讀取，而cup-2可能需要更改這個快取行的變數與cpu-1已經更改的快取行中的變數是不一樣的，所以這相當於給幾個毫不相關的變數加了一把同步鎖；
為了防止偽共享，不同jdk版本實現方式是不一樣的：
1. 在jdk1.7之前會將需要獨佔快取行的變數前後新增一組long型別的變數，依靠這些無意義的陣列的填充做到一個變數自己獨佔一個快取行；
2. 在jdk1.7因為jvm會將這些沒有用到的變數優化掉，所以採用繼承一個宣告瞭好多long變數的類的方式來實現；
3. 在jdk1.8中通過新增sun.misc.Contended註解來解決這個問題，若要使該註解有效必須在jvm中新增以下引數：
-XX:-RestrictContended

sun.misc.Contended註解會在變數前面新增128位元組的padding將當前變數與其他變數進行隔離；
關於什麼是快取行，jdk是如何避免快取行的，網上有非常多的解釋，在這裡就不再深入講解了；

java 中的鎖 -- 偏向鎖、輕量級鎖、自旋鎖、重量級鎖