一、悲觀鎖

悲觀鎖顧名思義是從悲觀的角度去思考問題，解決問題。它總是會假設(shè)當(dāng)前情況是最壞的情況，在每次去拿數(shù)據(jù)的時候，都會認(rèn)為數(shù)據(jù)會被別人改變，因此在每次進(jìn)行拿數(shù)據(jù)操作的時候都會加鎖，如此一來，如果此時有別人也來拿這個數(shù)據(jù)的時候就會阻塞知道它拿到鎖。在Java中，Synchronized和ReentrantLock等獨(dú)占鎖的實(shí)現(xiàn)機(jī)制就是基于悲觀鎖思想。在數(shù)據(jù)庫中也經(jīng)常用到這種鎖機(jī)制，如行鎖，表鎖，讀寫鎖等，都是在操作之前先上鎖，保證共享資源只能給一個操作（一個線程）使用。

由于悲觀鎖的頻繁加鎖，因此導(dǎo)致了一些問題的出現(xiàn)：比如在多線程競爭下，頻繁加鎖、釋放鎖導(dǎo)致頻繁的上下文切換和調(diào)度延時，一個線程持有鎖會導(dǎo)致其他線程進(jìn)入阻塞狀態(tài)，從而引起性能問題。

二、樂觀鎖

樂觀鎖從字面上看是從積極，樂觀的角度去看待問題，因此它認(rèn)為數(shù)據(jù)一般不會產(chǎn)生沖突，因此一般不加鎖，當(dāng)數(shù)據(jù)進(jìn)行提交更新時，才會真正對數(shù)據(jù)是否產(chǎn)生沖突進(jìn)行監(jiān)測。如果發(fā)生沖突，就返回給用戶錯誤信息，由用戶來決定如何去做，主要有兩個步驟：沖突檢測和數(shù)據(jù)更新。

三、CAS

CAS(compare and set），比較和更新。CAS是樂觀鎖的技術(shù)實(shí)現(xiàn)，當(dāng)多個線程嘗試使用CAS同時來更新同一個變量，只有一個線程能夠更新變量值，而其他的線程都會失敗，失敗的線程并不會被掛起，告知這次競爭失敗，可以再次嘗試。

CAS操作包含三個操作數(shù)：

• 需要讀寫的內(nèi)存位置(V)
• 需要比較的預(yù)期原值(A)
• 擬寫入的新值(B)

如果內(nèi)存位置V的值與原預(yù)期值A(chǔ)相匹配，那么處理器就會自動將該位置更新為新值B，否則處理器不做任何處理。樂觀鎖是一種思想，CAS是這種思想的一種實(shí)現(xiàn)方法。Java中對CAS支持，在jdk1.5之后新增java.util.concurrent(J.U.C)就是建立CAS基礎(chǔ)上，CAS是一種非阻塞的實(shí)現(xiàn)，例如：Atomic

四、AtomicXXX

在Java中，提供了一些原子化的操作類型，如下操作

 private volatile int value;
 
public final int get() {
        return value;
    }

讀取的值，value是聲明為volatile的，就可以保證在沒有鎖的情況下，線程可見性

在涉及到數(shù)據(jù)變更,以incrementAndGet實(shí)例：++i操作

public final int incrementAndGet() {
        for (;;) {
            int current = get();
            int next = current + 1;
            if (compareAndSet(current, next))
                return next;
        }
    }

采用的CAS的操作，每次讀取內(nèi)存中的數(shù)據(jù)，讓后將數(shù)據(jù)+1的結(jié)果進(jìn)行CAS操作，如果成功就返回結(jié)果，負(fù)責(zé)重試指導(dǎo)成功為止，這里調(diào)用compareAndSet是CAS所依賴的JNI的實(shí)現(xiàn)的樂觀鎖 。

public final boolean compareAndSet(int expect, int update) {
        return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
    }

Atomic就是volatile的使用場景，也是CAS的使用場景。

五、CAS中的ABA問題

CAS使用起來能夠提高性能，但會引起ABA的問題

假如如下事件序列：

1、線程1從內(nèi)次位置V來獲取值A(chǔ)

2、線程2從內(nèi)存位置V獲取A

3、線程2進(jìn)行一些操作，將B寫入到V

4、線程2將A寫入位置V

5、線程1進(jìn)行CAS操作，發(fā)現(xiàn)位置V的值任然為A,操作成功了

6、線程1盡管CAS操作成功了，該過程有可能出現(xiàn)問題，對于線程1，線程2做的處理就可能丟失了

舉例說明：一個鏈表ABA的例子

1、現(xiàn)有一個用單向鏈表實(shí)現(xiàn)的堆棧，棧頂為A。這時線程T1已經(jīng)知道A.next為B，然后希望用CAS將棧頂替換為B：

1head.compareAndSet(A,B);

2、在T1執(zhí)行上面這條指令之前，線程T2介入，將A、B出棧，再依次入棧D、C、A，而對象B此時處于游離狀態(tài)。

3、此時輪到線程T1執(zhí)行CAS操作，檢測發(fā)現(xiàn)棧頂仍為A，所以CAS成功，棧頂變?yōu)锽。但實(shí)際上B.next為null，此時堆棧中只有B一個元素，C和D組成的鏈表不再存在于堆棧中，C、D被丟掉了。

六、ABA問題解決方案

ABA問題解決思路就是使用版本號，在變量前面追加版本號，每次對變量你進(jìn)行更新的時候?qū)Π姹具M(jìn)行加1，對于A->B->A 就會變成1A ->2B->3A

七、使用CAS會引起的問題

1.ABA問題

ABA問題可以使用版本號解決

2.循環(huán)時間長開銷大

 自旋CAS如果長時間不成功，CPU帶來非常大的執(zhí)行開銷，需要考慮長時間循環(huán)問題，給每個線程循環(huán)給定循環(huán)次數(shù)閾值，讓當(dāng)前線程釋放CPU的使用權(quán)，進(jìn)入阻塞中

3.只能保證一個共享變量的原子操作

八、Synchronized鎖優(yōu)化

JDK1.5之前， Synchronized稱之為“重量級鎖”，對該做了各種所有，分別為偏向鎖、輕量級鎖、重量級鎖

Java對象內(nèi)存布局：

說到 synchronized 加鎖原理與Java對象在內(nèi)存中的布局有很大關(guān)系， Java 對象內(nèi)存布局如下:

如上圖所示，在創(chuàng)建一個對象后，在 JVM 虛擬機(jī)( HotSpot )中，對象在 Java 內(nèi)存中的存儲布局 可分為三塊:

對象頭區(qū)域

存放鎖信息，對象年齡等信息

實(shí)例數(shù)據(jù)區(qū)域

此處存儲的是對象真正有效的信息，比如對象中所有字段的內(nèi)容

對齊填充區(qū)域

JVM 的實(shí)現(xiàn) HostSpot 規(guī)定對象的起始地址必須是 8 字節(jié)的整數(shù)倍，換句話來說，現(xiàn)在 64 位的 OS 往外讀取數(shù)據(jù)的時候一次性讀取 64bit 整數(shù)倍的數(shù)據(jù)，也就是 8 個字節(jié)，所以 HotSpot 為了高效讀取對象，就做了"對齊"，如果一個對象實(shí)際占的內(nèi)存大小不是 8byte 的整數(shù)倍時，就"補(bǔ)位"到 8byte 的整數(shù)倍。所以對齊填充區(qū)域的大小不是固定的。

synchronized用的鎖是存在Java對象頭里的，如果對象是數(shù)組類型，則虛擬機(jī)用3個字寬（Word）存儲對象頭，如果對象是非數(shù)組類型，則用2字寬存儲對象頭。在32位虛擬機(jī)中，1字寬等于4字節(jié)，即32bit，如下圖：

Java對象頭里的Mark Word里默認(rèn)存儲對象的HashCode、分代年齡和鎖標(biāo)記位。32位JVM的Mark Word的默認(rèn)存儲結(jié)構(gòu)如下圖所示：

在Java SE 1.6中，鎖一共有4種狀態(tài)，級別從低到高依次是：無鎖狀態(tài)、偏向鎖狀態(tài)、輕量級鎖狀態(tài)和重量級鎖狀態(tài)，這幾個狀態(tài)會隨著競爭情況逐漸升級。鎖可以升級但不能降級，意味著偏向鎖升級成輕量級鎖后不能降級成偏向鎖。這種鎖升級卻不能降級的策略，目的是為了提高獲得鎖和釋放鎖的效率。

九、偏向鎖

偏向鎖的操作根本沒有去找操作系統(tǒng)， 每個對象都有對象頭，看看這個account對象的所謂“對象頭”，其中有個叫做Mark Word：里邊有幾個標(biāo)識位，還有其他數(shù)據(jù)。

JVM使用CAS操作把線程ID記錄到了這個Mark Word當(dāng)中，修改了標(biāo)識位，當(dāng)前線程就擁有這把鎖了

可以看出：JVM不用和操作系統(tǒng)協(xié)商設(shè)置Mutex，它只記錄下線程ID，就表示當(dāng)前線程擁有這把鎖了，不用操作系統(tǒng)介入

這時線程獲得了鎖，可以執(zhí)行synchronized修飾的代碼塊。

當(dāng)線程再次執(zhí)行到這個synchronized的時候，JVM通過鎖對象account的Mark Word判斷：“當(dāng)前線程ID還在，還持有著這個對象的鎖，就可以繼續(xù)進(jìn)入臨界區(qū)執(zhí)行

這就是偏向鎖，在沒有別的線程競爭的時候，一直偏向當(dāng)前線程，當(dāng)前線程可以一直執(zhí)行

十、輕量級鎖

繼續(xù)沿著偏向鎖思路研究

另一個線程0x3704也要進(jìn)入這個代碼塊執(zhí)行，但是鎖對象account 保存的是當(dāng)前線程ID，他是沒法進(jìn)入臨界區(qū)的。

這時也不需要和操作系統(tǒng)交流，JVM可以對偏向鎖升級一下，變成一個輕量級的鎖。

JVM把鎖對象account恢復(fù)成無鎖狀態(tài)，在當(dāng)前兩線程的棧幀中各自分配了一個空間，叫做Lock Record，把鎖對象account的Mark Word在倆線程的棧幀中各自復(fù)制了一份，叫做Displaced Mark Word

然后當(dāng)前線程的Lock Record的地址使用CAS放到了Mark Word當(dāng)中，并且把鎖標(biāo)志位改為00， 這意味著當(dāng)前線程也已經(jīng)獲得了這個輕量級的鎖了，可以繼續(xù)進(jìn)入臨界區(qū)執(zhí)行。

0x3704線程沒有獲得鎖，但不阻塞，JVM讓他自旋幾次，等待一會兒。等當(dāng)前退出臨界區(qū)，釋放鎖的時候，需要把這個Displaced markd word 使用CAS復(fù)制回去。接下來他就可以加鎖了。

兩線程交替著進(jìn)入臨界區(qū)，執(zhí)行這段代碼，相安無事，很少出現(xiàn)真正的競爭。

即使是出現(xiàn)了競爭，想獲得鎖的線程只要自旋幾次，等待一會兒，鎖就可能釋放了。

很明顯，如果沒有競爭或者輕度的競爭，輕量級鎖僅僅使用CAS操作和Lock record就避免了重量級互斥鎖的開銷

十一、重量級鎖

再次分析：輕量級鎖運(yùn)行時，一線程0x3704 正在持有鎖。另一線程自旋了好多次，0x3704還是沒釋放鎖。 這時候JVM考慮自旋次數(shù)太多了浪費(fèi)CPU。接則升級為重量級鎖！

重量級鎖需要操作系統(tǒng)的介入，依賴操作系統(tǒng)底層的Mutex Lock。

JVM創(chuàng)建了一個monitor 對象，把這個對象的地址更新到了Mark word當(dāng)中。

在持有鎖運(yùn)行，而另一線程則切換進(jìn)程狀態(tài)至：阻塞

到此這篇關(guān)于詳解Java中的悲觀鎖與樂觀鎖的文章就介紹到這了,更多相關(guān)悲觀鎖與樂觀鎖內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論