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

基礎(chǔ)知識之一：鎖的類型
鎖從宏觀上分類，分為悲觀鎖與樂觀鎖。

樂觀鎖
樂觀鎖是一種樂觀思想，即認(rèn)為讀多寫少，遇到并發(fā)寫的可能性低，每次去拿數(shù)據(jù)的時候都認(rèn)為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數(shù)據(jù)，采取在寫時先讀出當(dāng)前版本號，然后加鎖操作（比較跟上一次的版本號，如果一樣則更新），如果失敗則要重復(fù)讀-比較-寫的操作。

java中的樂觀鎖基本都是通過CAS操作實(shí)現(xiàn)的，CAS是一種更新的原子操作，比較當(dāng)前值跟傳入值是否一樣，一樣則更新，否則失敗。

悲觀鎖
悲觀鎖是就是悲觀思想，即認(rèn)為寫多，遇到并發(fā)寫的可能性高，每次去拿數(shù)據(jù)的時候都認(rèn)為別人會修改，所以每次在讀寫數(shù)據(jù)的時候都會上鎖，這樣別人想讀寫這個數(shù)據(jù)就會block直到拿到鎖。java中的悲觀鎖就是Synchronized,AQS框架下的鎖則是先嘗試cas樂觀鎖去獲取鎖，獲取不到，才會轉(zhuǎn)換為悲觀鎖，如RetreenLock。

基礎(chǔ)知識之二：java線程阻塞的代價

java的線程是映射到操作系統(tǒng)原生線程之上的，如果要阻塞或喚醒一個線程就需要操作系統(tǒng)介入，需要在用戶態(tài)與核心態(tài)之間切換，這種切換會消耗大量的系統(tǒng)資源，因?yàn)橛脩魬B(tài)與內(nèi)核態(tài)都有各自專用的內(nèi)存空間，專用的寄存器等，用戶態(tài)切換至內(nèi)核態(tài)需要傳遞給許多變量、參數(shù)給內(nèi)核，內(nèi)核也需要保護(hù)好用戶態(tài)在切換時的一些寄存器值、變量等，以便內(nèi)核態(tài)調(diào)用結(jié)束后切換回用戶態(tài)繼續(xù)工作。

如果線程狀態(tài)切換是一個高頻操作時，這將會消耗很多CPU處理時間；
如果對于那些需要同步的簡單的代碼塊，獲取鎖掛起操作消耗的時間比用戶代碼執(zhí)行的時間還要長，這種同步策略顯然非常糟糕的。
synchronized會導(dǎo)致爭用不到鎖的線程進(jìn)入阻塞狀態(tài)，所以說它是java語言中一個重量級的同步操縱，被稱為重量級鎖，為了緩解上述性能問題，JVM從1.5開始，引入了輕量鎖與偏向鎖，默認(rèn)啟用了自旋鎖，他們都屬于樂觀鎖。

明確java線程切換的代價，是理解java中各種鎖的優(yōu)缺點(diǎn)的基礎(chǔ)之一。

基礎(chǔ)知識之三：markword
在介紹java鎖之前，先說下什么是markword，markword是java對象數(shù)據(jù)結(jié)構(gòu)中的一部分，要詳細(xì)了解java對象的結(jié)構(gòu)可以點(diǎn)擊這里,這里只做markword的詳細(xì)介紹，因?yàn)閷ο蟮膍arkword和java各種類型的鎖密切相關(guān)；

markword數(shù)據(jù)的長度在32位和64位的虛擬機(jī)（未開啟壓縮指針）中分別為32bit和64bit，它的最后2bit是鎖狀態(tài)標(biāo)志位，用來標(biāo)記當(dāng)前對象的狀態(tài)，對象的所處的狀態(tài)，決定了markword存儲的內(nèi)容，如下表所示:

32位虛擬機(jī)在不同狀態(tài)下markword結(jié)構(gòu)如下圖所示：

了解了markword結(jié)構(gòu)，有助于后面了解java鎖的加鎖解鎖過程；

小結(jié)
前面提到了java的4種鎖，他們分別是重量級鎖、自旋鎖、輕量級鎖和偏向鎖，?
不同的鎖有不同特點(diǎn)，每種鎖只有在其特定的場景下，才會有出色的表現(xiàn)，java中沒有哪種鎖能夠在所有情況下都能有出色的效率，引入這么多鎖的原因就是為了應(yīng)對不同的情況；

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

java中的鎖
自旋鎖
自旋鎖原理非常簡單，如果持有鎖的線程能在很短時間內(nèi)釋放鎖資源，那么那些等待競爭鎖的線程就不需要做內(nèi)核態(tài)和用戶態(tài)之間的切換進(jìn)入阻塞掛起狀態(tài)，它們只需要等一等（自旋），等持有鎖的線程釋放鎖后即可立即獲取鎖，這樣就避免用戶線程和內(nèi)核的切換的消耗。（也就是不釋放CPU）

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

如果持有鎖的線程執(zhí)行的時間超過自旋等待的最大時間扔沒有釋放鎖，就會導(dǎo)致其它爭用鎖的線程在最大等待時間內(nèi)還是獲取不到鎖，這時爭用線程會停止自旋進(jìn)入阻塞狀態(tài)。

自旋鎖的優(yōu)缺點(diǎn)
自旋鎖盡可能的減少線程的阻塞，這對于鎖的競爭不激烈，且占用鎖時間非常短的代碼塊來說性能能大幅度的提升，因?yàn)樽孕南臅∮诰€程阻塞掛起再喚醒的操作的消耗，這些操作會導(dǎo)致線程發(fā)生兩次上下文切換！

但是如果鎖的競爭激烈，或者持有鎖的線程需要長時間占用鎖執(zhí)行同步塊，這時候就不適合使用自旋鎖了，因?yàn)樽孕i在獲取鎖前一直都是占用cpu做無用功，占著XX不XX，同時有大量線程在競爭一個鎖，會導(dǎo)致獲取鎖的時間很長，線程自旋的消耗大于線程阻塞掛起操作的消耗，其它需要cup的線程又不能獲取到cpu，造成cpu的浪費(fèi)。所以這種情況下我們要關(guān)閉自旋鎖；

自旋鎖時間閾值
自旋鎖的目的是為了占著CPU的資源不釋放，等到獲取到鎖立即進(jìn)行處理。但是如何去選擇自旋的執(zhí)行時間呢？如果自旋執(zhí)行時間太長，會有大量的線程處于自旋狀態(tài)占用CPU資源，進(jìn)而會影響整體系統(tǒng)的性能。因此自旋的周期選的額外重要！

JVM對于自旋周期的選擇，jdk1.5這個限度是一定的寫死的，在1.6引入了適應(yīng)性自旋鎖，適應(yīng)性自旋鎖意味著自旋的時間不在是固定的了，而是由前一次在同一個鎖上的自旋時間以及鎖的擁有者的狀態(tài)來決定，基本認(rèn)為一個線程上下文切換的時間是最佳的一個時間，同時JVM還針對當(dāng)前CPU的負(fù)荷情況做了較多的優(yōu)化

如果平均負(fù)載小于CPUs則一直自旋

如果有超過(CPUs/2)個線程正在自旋，則后來線程直接阻塞

如果正在自旋的線程發(fā)現(xiàn)Owner發(fā)生了變化則延遲自旋時間（自旋計數(shù)）或進(jìn)入阻塞

如果CPU處于節(jié)電模式則停止自旋

自旋時間的最壞情況是CPU的存儲延遲（CPU A存儲了一個數(shù)據(jù)，到CPU B得知這個數(shù)據(jù)直接的時間差）

自旋時會適當(dāng)放棄線程優(yōu)先級之間的差異

自旋鎖的開啟
JDK1.6中-XX:+UseSpinning開啟；?
-XX:PreBlockSpin=10 為自旋次數(shù)；?
JDK1.7后，去掉此參數(shù)，由jvm控制；

重量級鎖Synchronized
Synchronized的作用
在JDK1.5之前都是使用synchronized關(guān)鍵字保證同步的，Synchronized的作用相信大家都已經(jīng)非常熟悉了；

它可以把任意一個非NULL的對象當(dāng)作鎖。

作用于方法時，鎖住的是對象的實(shí)例(this)；
當(dāng)作用于靜態(tài)方法時，鎖住的是Class實(shí)例，又因?yàn)镃lass的相關(guān)數(shù)據(jù)存儲在永久帶PermGen（jdk1.8則是metaspace），永久帶是全局共享的，因此靜態(tài)方法鎖相當(dāng)于類的一個全局鎖，會鎖所有調(diào)用該方法的線程；
synchronized作用于一個對象實(shí)例時，鎖住的是所有以該對象為鎖的代碼塊。
Synchronized的實(shí)現(xiàn)
實(shí)現(xiàn)如下圖所示；

它有多個隊(duì)列，當(dāng)多個線程一起訪問某個對象監(jiān)視器的時候，對象監(jiān)視器會將這些線程存儲在不同的容器中。

Contention List：競爭隊(duì)列，所有請求鎖的線程首先被放在這個競爭隊(duì)列中；

Entry List：Contention List中那些有資格成為候選資源·的線程被移動到Entry List中；

Wait Set：哪些調(diào)用wait方法被阻塞的線程被放置在這里；

OnDeck：任意時刻，最多只有一個線程正在競爭鎖資源，該線程被成為OnDeck；

Owner：當(dāng)前已經(jīng)獲取到所資源的線程被稱為Owner；

!Owner：當(dāng)前釋放鎖的線程。

JVM每次從隊(duì)列的尾部取出一個數(shù)據(jù)用于鎖競爭候選者（OnDeck），但是并發(fā)情況下，ContentionList會被大量的并發(fā)線程進(jìn)行CAS訪問，為了降低對尾部元素的競爭，JVM會將一部分線程移動到EntryList中作為候選競爭線程。Owner線程會在unlock時，將ContentionList中的部分線程遷移到EntryList中，并指定EntryList中的某個線程為OnDeck線程（一般是最先進(jìn)去的那個線程）。Owner線程并不直接把鎖傳遞給OnDeck線程，而是把鎖競爭的權(quán)利交給OnDeck，OnDeck需要重新競爭鎖。這樣雖然犧牲了一些公平性，但是能極大的提升系統(tǒng)的吞吐量，在JVM中，也把這種選擇行為稱之為“競爭切換”。

OnDeck線程獲取到鎖資源后會變?yōu)镺wner線程，而沒有得到鎖資源的仍然停留在EntryList中。如果Owner線程被wait方法阻塞，則轉(zhuǎn)移到WaitSet隊(duì)列中，直到某個時刻通過notify或者notifyAll喚醒，會重新進(jìn)去EntryList中。

處于ContentionList、EntryList、WaitSet中的線程都處于阻塞狀態(tài)，該阻塞是由操作系統(tǒng)來完成的（Linux內(nèi)核下采用pthread_mutex_lock內(nèi)核函數(shù)實(shí)現(xiàn)的）。

Synchronized是非公平鎖。 Synchronized在線程進(jìn)入ContentionList時，等待的線程會先嘗試自旋獲取鎖，如果獲取不到就進(jìn)入ContentionList，這明顯對于已經(jīng)進(jìn)入隊(duì)列的線程是不公平的，還有一個不公平的事情就是自旋獲取鎖的線程還可能直接搶占OnDeck線程的鎖資源。

偏向鎖
Java偏向鎖(Biased Locking)是Java6引入的一項(xiàng)多線程優(yōu)化。?
偏向鎖，顧名思義，它會偏向于第一個訪問鎖的線程，如果在運(yùn)行過程中，同步鎖只有一個線程訪問，不存在多線程爭用的情況，則線程是不需要觸發(fā)同步的，這種情況下，就會給線程加一個偏向鎖。?
如果在運(yùn)行過程中，遇到了其他線程搶占鎖，則持有偏向鎖的線程會被掛起，JVM會消除它身上的偏向鎖，將鎖恢復(fù)到標(biāo)準(zhǔn)的輕量級鎖。

它通過消除資源無競爭情況下的同步原語，進(jìn)一步提高了程序的運(yùn)行性能。

偏向鎖的實(shí)現(xiàn)
偏向鎖獲取過程：
訪問Mark Word中偏向鎖的標(biāo)識是否設(shè)置成1，鎖標(biāo)志位是否為01，確認(rèn)為可偏向狀態(tài)。

如果為可偏向狀態(tài)，則測試線程ID是否指向當(dāng)前線程，如果是，進(jìn)入步驟5，否則進(jìn)入步驟3。

如果線程ID并未指向當(dāng)前線程，則通過CAS操作競爭鎖。如果競爭成功，則將Mark Word中線程ID設(shè)置為當(dāng)前線程ID，然后執(zhí)行5；如果競爭失敗，執(zhí)行4。

如果CAS獲取偏向鎖失敗，則表示有競爭。當(dāng)?shù)竭_(dá)全局安全點(diǎn)（safepoint）時獲得偏向鎖的線程被掛起，偏向鎖升級為輕量級鎖，然后被阻塞在安全點(diǎn)的線程繼續(xù)往下執(zhí)行同步代碼。（撤銷偏向鎖的時候會導(dǎo)致stop the word）

執(zhí)行同步代碼。

注意：第四步中到達(dá)安全點(diǎn)safepoint會導(dǎo)致stop the word，時間很短。

偏向鎖的釋放：
偏向鎖的撤銷在上述第四步驟中有提到。偏向鎖只有遇到其他線程嘗試競爭偏向鎖時，持有偏向鎖的線程才會釋放鎖，線程不會主動去釋放偏向鎖。偏向鎖的撤銷，需要等待全局安全點(diǎn)（在這個時間點(diǎn)上沒有字節(jié)碼正在執(zhí)行），它會首先暫停擁有偏向鎖的線程，判斷鎖對象是否處于被鎖定狀態(tài)，撤銷偏向鎖后恢復(fù)到未鎖定（標(biāo)志位為“01”）或輕量級鎖（標(biāo)志位為“00”）的狀態(tài)。

偏向鎖的適用場景
始終只有一個線程在執(zhí)行同步塊，在它沒有執(zhí)行完釋放鎖之前，沒有其它線程去執(zhí)行同步塊，在鎖無競爭的情況下使用，一旦有了競爭就升級為輕量級鎖，升級為輕量級鎖的時候需要撤銷偏向鎖，撤銷偏向鎖的時候會導(dǎo)致stop the word操作；?
在有鎖的競爭時，偏向鎖會多做很多額外操作，尤其是撤銷偏向所的時候會導(dǎo)致進(jìn)入安全點(diǎn)，安全點(diǎn)會導(dǎo)致stw，導(dǎo)致性能下降，這種情況下應(yīng)當(dāng)禁用；

查看停頓–安全點(diǎn)停頓日志
要查看安全點(diǎn)停頓，可以打開安全點(diǎn)日志，通過設(shè)置JVM參數(shù) -XX:+PrintGCApplicationStoppedTime 會打出系統(tǒng)停止的時間，添加-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 這兩個參數(shù)會打印出詳細(xì)信息，可以查看到使用偏向鎖導(dǎo)致的停頓，時間非常短暫，但是爭用嚴(yán)重的情況下，停頓次數(shù)也會非常多；

注意：安全點(diǎn)日志不能一直打開：?
1. 安全點(diǎn)日志默認(rèn)輸出到stdout，一是stdout日志的整潔性，二是stdout所重定向的文件如果不在/dev/shm，可能被鎖。?
2. 對于一些很短的停頓，比如取消偏向鎖，打印的消耗比停頓本身還大。?
3. 安全點(diǎn)日志是在安全點(diǎn)內(nèi)打印的，本身加大了安全點(diǎn)的停頓時間。

所以安全日志應(yīng)該只在問題排查時打開。?
如果在生產(chǎn)系統(tǒng)上要打開，再再增加下面四個參數(shù)：?
-XX:+UnlockDiagnosticVMOptions -XX: -DisplayVMOutput -XX:+LogVMOutput -XX:LogFile=/dev/shm/vm.log?
打開Diagnostic（只是開放了更多的flag可選，不會主動激活某個flag），關(guān)掉輸出VM日志到stdout，輸出到獨(dú)立文件,/dev/shm目錄（內(nèi)存文件系統(tǒng)）。

此日志分三部分：?
第一部分是時間戳，VM Operation的類型?
第二部分是線程概況，被中括號括起來?
total: 安全點(diǎn)里的總線程數(shù)?
initially_running: 安全點(diǎn)開始時正在運(yùn)行狀態(tài)的線程數(shù)?
wait_to_block: 在VM Operation開始前需要等待其暫停的線程數(shù)

第三部分是到達(dá)安全點(diǎn)時的各個階段以及執(zhí)行操作所花的時間，其中最重要的是vmop

spin: 等待線程響應(yīng)safepoint號召的時間；
block: 暫停所有線程所用的時間；
sync: 等于 spin+block，這是從開始到進(jìn)入安全點(diǎn)所耗的時間，可用于判斷進(jìn)入安全點(diǎn)耗時；
cleanup: 清理所用時間；
vmop: 真正執(zhí)行VM Operation的時間。
可見，那些很多但又很短的安全點(diǎn)，全都是RevokeBias， 高并發(fā)的應(yīng)用會禁用掉偏向鎖。

jvm開啟/關(guān)閉偏向鎖
開啟偏向鎖：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
關(guān)閉偏向鎖：-XX:-UseBiasedLocking
輕量級鎖
輕量級鎖是由偏向所升級來的，偏向鎖運(yùn)行在一個線程進(jìn)入同步塊的情況下，當(dāng)?shù)诙€線程加入鎖爭用的時候，偏向鎖就會升級為輕量級鎖；?
輕量級鎖的加鎖過程：

在代碼進(jìn)入同步塊的時候，如果同步對象鎖狀態(tài)為無鎖狀態(tài)（鎖標(biāo)志位為“01”狀態(tài)，是否為偏向鎖為“0”），虛擬機(jī)首先將在當(dāng)前線程的棧幀中建立一個名為鎖記錄（Lock Record）的空間，用于存儲鎖對象目前的Mark Word的拷貝，官方稱之為 Displaced Mark Word。這時候線程堆棧與對象頭的狀態(tài)如圖：?
　　所示。

拷貝對象頭中的Mark Word復(fù)制到鎖記錄中；

拷貝成功后，虛擬機(jī)將使用CAS操作嘗試將對象的Mark Word更新為指向Lock Record的指針，并將Lock record里的owner指針指向object mark word。如果更新成功，則執(zhí)行步驟4，否則執(zhí)行步驟5。

如果這個更新動作成功了，那么這個線程就擁有了該對象的鎖，并且對象Mark Word的鎖標(biāo)志位設(shè)置為“00”，即表示此對象處于輕量級鎖定狀態(tài)，這時候線程堆棧與對象頭的狀態(tài)如圖所示。?
　　

如果這個更新操作失敗了，虛擬機(jī)首先會檢查對象的Mark Word是否指向當(dāng)前線程的棧幀，如果是就說明當(dāng)前線程已經(jīng)擁有了這個對象的鎖，那就可以直接進(jìn)入同步塊繼續(xù)執(zhí)行。否則說明多個線程競爭鎖，輕量級鎖就要膨脹為重量級鎖，鎖標(biāo)志的狀態(tài)值變?yōu)椤?0”，Mark Word中存儲的就是指向重量級鎖（互斥量）的指針，后面等待鎖的線程也要進(jìn)入阻塞狀態(tài)。 而當(dāng)前線程便嘗試使用自旋來獲取鎖，自旋就是為了不讓線程阻塞，而采用循環(huán)去獲取鎖的過程。

輕量級鎖的釋放
釋放鎖線程視角：由輕量鎖切換到重量鎖，是發(fā)生在輕量鎖釋放鎖的期間，之前在獲取鎖的時候它拷貝了鎖對象頭的markword，在釋放鎖的時候如果它發(fā)現(xiàn)在它持有鎖的期間有其他線程來嘗試獲取鎖了，并且該線程對markword做了修改，兩者比對發(fā)現(xiàn)不一致，則切換到重量鎖。

因?yàn)橹亓考夋i被修改了，所有display mark word和原來的markword不一樣了。

怎么補(bǔ)救，就是進(jìn)入mutex前，compare一下obj的markword狀態(tài)。確認(rèn)該markword是否被其他線程持有。

此時如果線程已經(jīng)釋放了markword，那么通過CAS后就可以直接進(jìn)入線程，無需進(jìn)入mutex，就這個作用。

嘗試獲取鎖線程視角：如果線程嘗試獲取鎖的時候，輕量鎖正被其他線程占有，那么它就會修改markword，修改重量級鎖，表示該進(jìn)入重量鎖了。

還有一個注意點(diǎn)：等待輕量鎖的線程不會阻塞，它會一直自旋等待鎖，并如上所說修改markword。

這就是自旋鎖，嘗試獲取鎖的線程，在沒有獲得鎖的時候，不被掛起，而轉(zhuǎn)而去執(zhí)行一個空循環(huán)，即自旋。在若干個自旋后，如果還沒有獲得鎖，則才被掛起，獲得鎖，則執(zhí)行代碼。

總結(jié)

synchronized的執(zhí)行過程：?
1. 檢測Mark Word里面是不是當(dāng)前線程的ID，如果是，表示當(dāng)前線程處于偏向鎖?
2. 如果不是，則使用CAS將當(dāng)前線程的ID替換Mard Word，如果成功則表示當(dāng)前線程獲得偏向鎖，置偏向標(biāo)志位1?
3. 如果失敗，則說明發(fā)生競爭，撤銷偏向鎖，進(jìn)而升級為輕量級鎖。?
4. 當(dāng)前線程使用CAS將對象頭的Mark Word替換為鎖記錄指針，如果成功，當(dāng)前線程獲得鎖?
5. 如果失敗，表示其他線程競爭鎖，當(dāng)前線程便嘗試使用自旋來獲取鎖。?
6. 如果自旋成功則依然處于輕量級狀態(tài)。?
7. 如果自旋失敗，則升級為重量級鎖。

上面幾種鎖都是JVM自己內(nèi)部實(shí)現(xiàn)，當(dāng)我們執(zhí)行synchronized同步塊的時候jvm會根據(jù)啟用的鎖和當(dāng)前線程的爭用情況，決定如何執(zhí)行同步操作；

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

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

如果線程爭用激烈，那么應(yīng)該禁用偏向鎖。

鎖優(yōu)化
以上介紹的鎖不是我們代碼中能夠控制的，但是借鑒上面的思想，我們可以優(yōu)化我們自己線程的加鎖操作；

減少鎖的時間
不需要同步執(zhí)行的代碼，能不放在同步快里面執(zhí)行就不要放在同步快內(nèi)，可以讓鎖盡快釋放；

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

java中很多數(shù)據(jù)結(jié)構(gòu)都是采用這種方法提高并發(fā)操作的效率：

ConcurrentHashMap
java中的ConcurrentHashMap在jdk1.8之前的版本，使用一個Segment 數(shù)組

Segment< K,V >[] segments
1
Segment繼承自ReenTrantLock，所以每個Segment就是個可重入鎖，每個Segment 有一個HashEntry< K,V >數(shù)組用來存放數(shù)據(jù)，put操作時，先確定往哪個Segment放數(shù)據(jù)，只需要鎖定這個Segment，執(zhí)行put，其它的Segment不會被鎖定；所以數(shù)組中有多少個Segment就允許同一時刻多少個線程存放數(shù)據(jù)，這樣增加了并發(fā)能力。

LongAdder
LongAdder 實(shí)現(xiàn)思路也類似ConcurrentHashMap，LongAdder有一個根據(jù)當(dāng)前并發(fā)狀況動態(tài)改變的Cell數(shù)組，Cell對象里面有一個long類型的value用來存儲值;?
開始沒有并發(fā)爭用的時候或者是cells數(shù)組正在初始化的時候，會使用cas來將值累加到成員變量的base上，在并發(fā)爭用的情況下，LongAdder會初始化cells數(shù)組，在Cell數(shù)組中選定一個Cell加鎖，數(shù)組有多少個cell，就允許同時有多少線程進(jìn)行修改，最后將數(shù)組中每個Cell中的value相加，在加上base的值，就是最終的值；cell數(shù)組還能根據(jù)當(dāng)前線程爭用情況進(jìn)行擴(kuò)容，初始長度為2，每次擴(kuò)容會增長一倍，直到擴(kuò)容到大于等于cpu數(shù)量就不再擴(kuò)容，這也就是為什么LongAdder比cas和AtomicInteger效率要高的原因，后面兩者都是volatile+cas實(shí)現(xiàn)的，他們的競爭維度是1，LongAdder的競爭維度為“Cell個數(shù)+1”為什么要+1？因?yàn)樗€有一個base，如果競爭不到鎖還會嘗試將數(shù)值加到base上；

LinkedBlockingQueue
LinkedBlockingQueue也體現(xiàn)了這樣的思想，在隊(duì)列頭入隊(duì)，在隊(duì)列尾出隊(duì)，入隊(duì)和出隊(duì)使用不同的鎖，相對于LinkedBlockingArray只有一個鎖效率要高；

拆鎖的粒度不能無限拆，最多可以將一個鎖拆為當(dāng)前cup數(shù)量個鎖即可；

鎖粗化
大部分情況下我們是要讓鎖的粒度最小化，鎖的粗化則是要增大鎖的粒度;?
在以下場景下需要粗化鎖的粒度：?
假如有一個循環(huán)，循環(huán)內(nèi)的操作需要加鎖，我們應(yīng)該把鎖放到循環(huán)外面，否則每次進(jìn)出循環(huán)，都進(jìn)出一次臨界區(qū)，效率是非常差的；

使用讀寫鎖
ReentrantReadWriteLock 是一個讀寫鎖，讀操作加讀鎖，可以并發(fā)讀，寫操作使用寫鎖，只能單線程寫；

讀寫分離
CopyOnWriteArrayList 、CopyOnWriteArraySet?
CopyOnWrite容器即寫時復(fù)制的容器。通俗的理解是當(dāng)我們往一個容器添加元素的時候，不直接往當(dāng)前容器添加，而是先將當(dāng)前容器進(jìn)行Copy，復(fù)制出一個新的容器，然后新的容器里添加元素，添加完元素之后，再將原容器的引用指向新的容器。這樣做的好處是我們可以對CopyOnWrite容器進(jìn)行并發(fā)的讀，而不需要加鎖，因?yàn)楫?dāng)前容器不會添加任何元素。所以CopyOnWrite容器也是一種讀寫分離的思想，讀和寫不同的容器。?
　CopyOnWrite并發(fā)容器用于讀多寫少的并發(fā)場景，因?yàn)?#xff0c;讀的時候沒有鎖，但是對其進(jìn)行更改的時候是會加鎖的，否則會導(dǎo)致多個線程同時復(fù)制出多個副本，各自修改各自的；

使用cas
如果需要同步的操作執(zhí)行速度非常快，并且線程競爭并不激烈，這時候使用cas效率會更高，因?yàn)榧渔i會導(dǎo)致線程的上下文切換，如果上下文切換的耗時比同步操作本身更耗時，且線程對資源的競爭不激烈，使用volatiled+cas操作會是非常高效的選擇；

消除緩存行的偽共享
除了我們在代碼中使用的同步鎖和jvm自己內(nèi)置的同步鎖外，還有一種隱藏的鎖就是緩存行，它也被稱為性能殺手。?
在多核cup的處理器中，每個cup都有自己獨(dú)占的一級緩存、二級緩存，甚至還有一個共享的三級緩存，為了提高性能，cpu讀寫數(shù)據(jù)是以緩存行為最小單元讀寫的；32位的cpu緩存行為32字節(jié)，64位cup的緩存行為64字節(jié)，這就導(dǎo)致了一些問題。?
例如，多個不需要同步的變量因?yàn)榇鎯υ谶B續(xù)的32字節(jié)或64字節(jié)里面，當(dāng)需要其中的一個變量時，就將它們作為一個緩存行一起加載到某個cup-1私有的緩存中（雖然只需要一個變量，但是cpu讀取會以緩存行為最小單位，將其相鄰的變量一起讀入），被讀入cpu緩存的變量相當(dāng)于是對主內(nèi)存變量的一個拷貝，也相當(dāng)于變相的將在同一個緩存行中的幾個變量加了一把鎖，這個緩存行中任何一個變量發(fā)生了變化，當(dāng)cup-2需要讀取這個緩存行時，就需要先將cup-1中被改變了的整個緩存行更新回主存（即使其它變量沒有更改），然后cup-2才能夠讀取，而cup-2可能需要更改這個緩存行的變量與cpu-1已經(jīng)更改的緩存行中的變量是不一樣的，所以這相當(dāng)于給幾個毫不相關(guān)的變量加了一把同步鎖；?
為了防止偽共享，不同jdk版本實(shí)現(xiàn)方式是不一樣的：?
1. 在jdk1.7之前會 將需要獨(dú)占緩存行的變量前后添加一組long類型的變量，依靠這些無意義的數(shù)組的填充做到一個變量自己獨(dú)占一個緩存行；?
2. 在jdk1.7因?yàn)閖vm會將這些沒有用到的變量優(yōu)化掉，所以采用繼承一個聲明了好多l(xiāng)ong變量的類的方式來實(shí)現(xiàn)；?
3. 在jdk1.8中通過添加sun.misc.Contended注解來解決這個問題，若要使該注解有效必須在jvm中添加以下參數(shù)：?
-XX:-RestrictContended

sun.misc.Contended注解會在變量前面添加128字節(jié)的padding將當(dāng)前變量與其他變量進(jìn)行隔離；?
關(guān)于什么是緩存行，jdk是如何避免緩存行的，網(wǎng)上有非常多的解釋，在這里就不再深入講解了；

其它方式等待著大家一起補(bǔ)充
?

總結(jié)

以上是生活随笔為你收集整理的JVM：锁机制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。