鎖的基礎知識

鎖的類型

鎖從宏觀上分類，只分爲兩種：悲觀鎖與樂觀鎖。java

樂觀鎖

樂觀鎖是一種樂觀思想，即認爲讀多寫少，遇到併發寫的可能性低，每次去拿數據的時候都認爲別人不會修改，因此不會上鎖，可是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，採起在寫時先讀出當前版本號，而後加鎖操做（比較跟上一次的版本號，若是同樣則更新），若是失敗則要重複讀-比較-寫的操做。Java中的樂觀鎖基本都是經過CAS操做實現的，CAS是一種更新的原子操做，比較當前值跟傳入值是否同樣，同樣則更新，不然失敗。git

悲觀鎖

悲觀鎖是就是悲觀思想，即認爲寫多，遇到併發寫的可能性高，每次去拿數據的時候都認爲別人會修改，因此每次在讀寫數據的時候都會上鎖，這樣別人想讀寫這個數據就會block直到拿到鎖。java中的悲觀鎖就是Synchronized，AQS框架下的鎖則是先嚐試CAS樂觀鎖去獲取鎖，獲取不到，纔會轉換爲悲觀鎖，如RetreenLock自旋鎖。程序員

線程阻塞的代價

Java的線程是映射到操做系統原生線程之上的，若是要阻塞或喚醒一個線程就須要操做系統介入，須要在戶態與核心態之間切換，這種切換會消耗大量的系統資源，由於用戶態與內核態都有各自專用的內存空間，專用的寄存器等，用戶態切換至內核態須要傳遞給許多變量、參數給內核，內核也須要保護好用戶態在切換時的一些寄存器值、變量等，以便內核態調用結束後切換回用戶態繼續工做。數組

若是線程狀態切換是一個高頻操做時，這將會消耗不少CPU處理時間；
若是對於那些須要同步的簡單的代碼塊，獲取鎖掛起操做消耗的時間比用戶代碼執行的時間還要長，這種同步策略顯然很是糟糕的。

synchronized會致使爭用不到鎖的線程進入阻塞狀態，因此說它是java語言中一個重量級的同步操縱，被稱爲重量級鎖，爲了緩解上述性能問題，JVM從1.5開始，引入了輕量鎖與偏向鎖，默認啓用了自旋鎖，他們都屬於樂觀鎖。緩存

明確java線程切換的代價，是理解java中各類鎖的優缺點的基礎之一。安全

Java中的鎖

自旋鎖

自旋鎖原理很是簡單，若是持有鎖的線程能在很短期內釋放鎖資源，那麼那些等待競爭鎖的線程就不須要作內核態和用戶態之間的切換進入阻塞掛起狀態，它們只須要等一等（自旋），等持有鎖的線程釋放鎖後便可當即獲取鎖，這樣就避免用戶線程和內核的切換的消耗。網絡

可是線程自旋是須要消耗cup的，說白了就是讓cup在作無用功，若是一直獲取不到鎖，那線程也不能一直佔用cup自旋作無用功，因此須要設定一個自旋等待的最大時間。多線程

若是持有鎖的線程執行的時間超過自旋等待的最大時間扔沒有釋放鎖，就會致使其它爭用鎖的線程在最大等待時間內仍是獲取不到鎖，這時爭用線程會中止自旋進入阻塞狀態。併發

自旋鎖的優缺點

自旋鎖儘量的減小線程的阻塞，這對於鎖的競爭不激烈，且佔用鎖時間很是短的代碼塊來講性能能大幅度的提高，由於自旋的消耗會小於線程阻塞掛起再喚醒的操做的消耗，這些操做會致使線程發生兩次上下文切換！app

可是若是鎖的競爭激烈，或者持有鎖的線程須要長時間佔用鎖執行同步塊，這時候就不適合使用自旋鎖了，由於自旋鎖在獲取鎖前一直都是佔用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會根據啓用的鎖和當前線程的爭用狀況，決定如何執行同步操做；

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

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

若是線程爭用激烈，那麼應該禁用偏向鎖。

鎖優化建議

雖然對於以上介紹的鎖都不是咱們代碼中可以控制的，可是借鑑上面的思想，咱們能夠優化咱們本身線程的加鎖操做。

減小鎖的時間

不須要同步執行的代碼，能不放在同步快裏面執行就不要放在同步快內，可讓鎖儘快釋放。

減小鎖的粒度

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

鎖粗化

大部分狀況下咱們是要讓鎖的粒度最小化，鎖的粗化則是要增大鎖的粒度。
在如下場景下須要粗化鎖的粒度：
假若有一個循環，循環內的操做須要加鎖，咱們應該把鎖放到循環外面，不然每次進出循環，都進出一次臨界區，效率是很是差的。

使用讀寫鎖

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將當前變量與其餘變量進行隔離；

volatile關鍵字

volatile是Java中的輕量級同步機制，使用volatile能夠保持內存可見性和防止指令重排序。

保持內存可見性

內存可見性是指全部線程都能看到共享內存的最新狀態。

Java內存模型

在Java內存模型中，分爲棧內存（線程私有）和堆內存（線程共享），Java中的內存模型依賴於硬件的存儲模型。

Java內存模型和硬件存儲模型的大體關係以下圖所示（圖片來源於網絡）：

而對於多個線程共享的變量，Java內存模型規定，變量存儲在主內存當中，每一個線程都有本身獨立的工做內存（好比CPU的寄存器），線程只能訪問本身的工做內存，不能夠訪問其它線程的工做內存。

工做內存中保存了主內存共享變量的副本，線程要操做這些共享變量，只能經過操做工做內存中的副原本實現，操做完畢以後再同步回到主內存當中。

如何保證多個線程操做主內存的數據完整性是一個難題，Java內存模型也規定了工做內存與主內存之間交互的協議，定義了8種原子操做：

(1) lock:將主內存中的變量鎖定，爲一個線程所獨佔

(2) unclock:將lock加的鎖定解除，此時其它的線程能夠有機會訪問此變量

(3) read:將主內存中的變量值讀到工做內存當中

(4) load:將read讀取的值保存到工做內存中的變量副本中

(5) use:將值傳遞給線程的代碼執行引擎

(6) assign:將執行引擎處理返回的值從新賦值給變量副本

(7) store:將變量副本的值存儲到主內存中

(8) write:將store存儲的值寫入到主內存的共享變量當中

大體過程以下圖所示（圖片來源於網絡）：

可見性帶來的數據失效問題

經過上面Java內存模型的描述，咱們會注意到這麼一個問題，每一個線程在獲取鎖以後會在本身的工做內存來操做共享變量，操做完成以後將工做內存中的副本回寫到主內存，而且在其它線程從主內存將變量同步回本身的工做內存以前，共享變量的改變對其是不可見的。即其餘線程的本地內存中的變量已是過期的，並非更新後的值，也就是說其餘線程本地內存中保持的是失效數據。

好比以下代碼是一個可變整數類：

MutableInteger.java

public class MutableInteger { private int value; public int get() { return value; } public void set(int value) { this.value = value; } }

MutableInteger不是線程安全的，由於get和set方法都是在沒有同步的狀況下進行的。若是線程1調用了set方法，那麼正在調用的get的線程2可能會看到更新後的value值，也有可能看不到，這就是數據失效問題。

要解決這個問題其實也很簡單，只須要將value聲明爲volatile變量便可。

private volatile int value;

volatile如何保持內存可見性

volatile的特殊規則就是：

read、load、use動做必須連續出現。
assign、store、write動做必須連續出現。

因此，使用volatile變量可以保證:

每次讀取前必須先從主內存刷新最新的值。
每次寫入後必須當即同步回主內存當中。

也就是說，使用volatile關鍵字修飾的變量看到的隨時都是本身的最新值。線程1中對變量value的最新修改，對線程2是可見的。這是由於每當修改本地內存變量的值時，在將更新同步到主內存的同時還會根據MESI清除其餘線程中本地變量副本值，迫使變量副本從新同步爲主內存的最新值。

防止指令重排

指令重排序

指令重排序是JVM爲了優化指令，提升程序運行效率，在不影響單線程程序執行結果的前提下，儘量地提升並行度。編譯器、處理器也遵循這樣一個目標。注意是單線程。多線程的狀況下指令重排序就會給程序員帶來問題。

不一樣的指令間可能存在數據依賴。好比下面計算圓的面積的語句：

double r = 2.5d; //(1)

double pi =3.1415926; //(2)

double area = pi* r * r; //(3)

area的計算依賴於r與pi兩個變量的賦值指令。而r與pi無依賴關係。

as-if-serial語義是指：無論如何重排序（編譯器與處理器爲了提升並行度），（單線程）程序的結果不能被改變。這是編譯器、Runtime、處理器必須遵照的語義。

雖然，（1） - happensbefore -> （2）,（2） - happens before -> （3），可是計算順序(1)(2)(3)與(2)(1)(3) 對於r、pi、area變量的結果並沒有區別。編譯器、Runtime在優化時能夠根據狀況重排序（1）與（2），而絲絕不影響程序的結果。

指令重排序包括編譯器重排序和運行時重排序。

指令重排序帶來的問題

例子1：A線程指令重排致使B線程出錯

對於在同一個線程內，這樣的改變是不會對邏輯產生影響的，可是在多線程的狀況下，指令重排序會帶來一些問題。

咱們來看下面這個情景:

在線程A中:

context = loadContext(); init = true;

在線程B中:

while(!init) {  // 根據線程A中對init變量的修改決定是否使用context變量
 sleep(1000); } doSomethingWithConfig(context);

假設此時在線程A中發生了指令重排序:

init = true; context = loadContext();

那麼B中極可能就會拿到一個還沒有初始化或還沒有初始化完成的context，從而引起程序錯誤。

例子2：指令重排致使單例模式失效

以下，是一個懶加載的單例模式，在單線程中這個單例是沒有問題的，可是在多線程中，競態條件會致使instance引用被屢次賦值，使用戶獲得兩個不一樣的單例。

class Singleton {
 private static Singleton instance;
 private Singleton(){}
 public static Singleton getInstance() { if ( instance == null ) { // 這裏存在競態條件
            instance = new Singleton(); } return instance; } }

爲了解決這個問題，可使用synchronized關鍵字將getInstance方法改成同步方法；但這樣串行化的單例效率是很低下的。因此就有前輩設計了DCL（Double Check Lock，雙重檢查鎖）機制，使得大部分請求都不會進入阻塞代碼塊。

class Singleton { private static Singleton instance; private Singleton() { } public static Singleton getInstance() { if (instance == null) { // 當instance不爲null時，仍可能指向一個「被部分初始化的對象」
            synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; } }

「看起來」很是完美：既減小了阻塞，又避免了競態條件。不錯，但實際上仍然存在一個問題——當instance不爲null時，仍可能指向一個"被部分初始化的對象"。

問題出在這行簡單的賦值語句：

instance = new Singleton();

它並非一個原子操做。事實上，它能夠」抽象「爲下面幾條JVM指令：

memory = allocate();    // 1：分配對象的內存空間
initInstance(memory);   // 2：初始化對象
instance = memory;      // 3：設置instance指向剛分配的內存地址

上面操做2依賴於操做1，可是操做3並不依賴於操做2，因此JVM能夠以「優化」爲目的對它們進行重排序，通過重排序後以下：

memory = allocate();    //1：分配對象的內存空間
instance = memory;      //3：設置instance指向剛分配的內存地址（此時對象還未初始化）
ctorInstance(memory);   //2：初始化對象

能夠看到指令重排以後，操做 3 排在了操做 2 以前，即引用instance指向內存memory時，而這段嶄新的內存尚未初始化，即引用instance指向了一個"被部分初始化的對象"。此時，若是另外一個線程調用getInstance方法，因爲instance已經指向了一塊內存空間，從而if條件判爲false，方法返回instance引用，用戶獲得了沒有完成初始化的「半個」單例。

解決這個問題也很簡單，只須要將instance聲明爲volatile變量便可。

private static volatile Singleton instance;

volatile如何防止指令重排

volatile關鍵字是經過提供「內存屏障」的方式來防止指令被重排序，爲了實現volatile的內存語義，編譯器在生成字節碼時，會在指令序列中插入內存屏障來禁止特定類型的處理器重排序。

大多數的處理器都支持內存屏障的指令。但對於編譯器來講，發現一個最優佈置來最小化插入屏障的總數是不太可能的，爲此，Java內存模型採起了保守的策略。

下面是基於保守策略的JMM內存屏障插入策略：

在每一個volatile寫操做的前面插入一個StoreStore屏障。
在每一個volatile寫操做的後面插入一個StoreLoad屏障。
在每一個volatile讀操做的後面插入一個LoadLoad屏障。
在每一個volatile讀操做的後面插入一個LoadStore屏障。

注意要點

1.volatile是一種稍弱的同步機制，在訪問volatile變量時不會執行加鎖操做，也就不會執行線程阻塞，所以volatilei變量是一種比synchronized關鍵字更輕量級的同步機制。

2.因爲使用volatile屏蔽掉了JVM中必要的代碼優化，因此在效率上比較低，所以必定在必要時才使用此關鍵字。在兩個或者更多的線程須要訪問的成員變量上使用volatile。當要訪問的變量已在synchronized代碼塊中，或者爲常量時，不必使用volatile。

3.加鎖機制（即同步機制）既能夠確保可見性又能夠確保原子性，而volatile變量只能確保可見性，緣由是聲明爲volatile的簡單變量若是當前值與該變量之前的值相關，那麼volatile關鍵字不起做用，也就是說以下的表達式都不是原子操做：「count++」、「count = count+1」。

4.在須要同步的時候，第一選擇應該是synchronized關鍵字，這是最安全的方式，嘗試其餘任何方式都是有風險的。尤爲在、jdK1.5以後，對synchronized同步機制作了不少優化，如：自適應的自旋鎖、鎖粗化、鎖消除、輕量級鎖等，使得它的性能明顯有了很大的提高。

Volatile與Synchronized的區別

一、volatile不須要加鎖，比synchronized更輕量級，不會阻塞線程；而且volatile只能修飾變量，而synchronized能夠修飾方法，以及代碼塊。

二、從內存可見性角度看，volatile讀至關於加鎖，volatile寫至關於解鎖。

三、synchronized既能保證可見性，又能保證原子性，而volatile只能保證可見性，沒法保證原子性。

四、關鍵字volatile解決的是變量在多個線程之間的可見性問題，而synchronized關鍵字解決的是多個線程之間訪問資源的同步性。

sleep和wait的區別

一、sleep是Thread的靜態方法、wait是Object的方法；
二、sleep不釋放鎖對象，wait放棄鎖對象；
三、sleep暫停線程，但監控狀態仍然保持，結束後自動恢復；
四、wait、notify和notifyAll只能在同步控制方法控制塊裏面使用，而sleep能夠在任意地方使用；
五、wait方法致使線程放棄對象鎖，只有針對此對象發出notify（或notifyAll）後才進入對象鎖定池準備從新得到對象鎖，而後進入就緒狀態，準備運行。

sleep方法屬於Thread類中方法，表示讓一個線程進入睡眠狀態，等待必定的時間以後，自動醒來進入到可運行狀態，不會立刻進入運行狀態，由於線程調度機制恢復線程的運行也須要時間，一個線程對象調用了sleep方法以後，並不會釋放他所持有的全部對象鎖，因此也就不會影響其餘進程對象的運行。但在sleep的過程當中有可能被其餘對象調用它的interrupt()，產生InterruptedException異常，若是你的程序不捕獲這個異常，線程就會異常終止，進入TERMINATED狀態，若是你的程序捕獲了這個異常，那麼程序就會繼續執行catch語句塊(可能還有finally語句塊)以及之後的代碼。
注意sleep()方法是一個靜態方法，也就是說他只對當前對象有效，經過t.sleep()讓t對象進入sleep，這樣的作法是錯誤的，它只會是使當前線程被sleep 而不是t線程。

wait屬於Object的成員方法，一旦一個對象調用了wait方法，必需要採用notify()或notifyAll()方法喚醒該進程；若是線程擁有某個或某些對象的同步鎖，那麼在調用了wait()後，這個線程就會釋放它持有的全部同步資源，而不限於這個被調用了wait()方法的對象。wait()方法也一樣會在wait的過程當中有可能被其餘對象調用interrupt()方法而產生InterruptedException異常。

其實二者均可以讓線程暫停一段時間，可是本質的區別是sleep是線程的運行狀態控制，wait是線程之間的通信問題。sleep()是讓某個線程暫停運行一段時間，其控制範圍是由當前線程決定，也就是說，在線程裏面決定。比如如說，我要作的事情是"點火->燒水->煮麪"，而當我點完火以後我不當即燒水，我要休息一段時間再燒。對於運行的主動權是由個人流程來控制。而wait()，首先，這是由某個肯定的對象來調用的，將這個對象理解成一個傳話的人，當這我的在某個線程裏面說"暫停!"，也是 thisOBJ.wait()，這裏的暫停是阻塞。仍是"點火->燒水->煮飯"，thisOBJ就比如一個監督個人人站在我旁邊，原本該線程應該執行1後執行2，再執行3，而在2處被那個對象喊暫停，那麼我就會一直等在這裏而不執行3，但正個流程並無結束，我一直想去煮飯，但還沒被容許，直到那個對象在某個地方說"通知暫停的線程啓動!"，也就是thisOBJ.notify()的時候，那麼我就能夠煮飯了，這個被暫停的線程就會從暫停處繼續執行。

源碼下載

碼雲：https://gitee.com/liuge1988/java-demo.git

做者：朝雨憶輕塵
出處：https://www.cnblogs.com/xifengxiaoma/ 版權全部，歡迎轉載，轉載請註明原文做者及出處。

Java併發編程：Java中的鎖和線程同步機制