在Java并發(fā)場(chǎng)景中，會(huì)涉及到各種各樣的鎖如公平鎖，樂觀鎖，悲觀鎖等等，這篇文章介紹各種鎖的分類：

公平鎖/非公平鎖

可重入鎖

獨(dú)享鎖/共享鎖

樂觀鎖/悲觀鎖

分段鎖

自旋鎖

線程鎖

樂觀鎖 VS 悲觀鎖

樂觀鎖與悲觀鎖是一種廣義上的概念，體現(xiàn)了看待線程同步的不同角度，在Java和數(shù)據(jù)庫(kù)中都有此概念對(duì)應(yīng)的實(shí)際應(yīng)用。

1.樂觀鎖

顧名思義，就是很樂觀，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人不會(huì)修改，所以不會(huì)上鎖，但是在更新的時(shí)候會(huì)判斷一下在此期間別人有沒有去更新這個(gè)數(shù)據(jù)，可以使用版本號(hào)等機(jī)制。

樂觀鎖適用于多讀的應(yīng)用類型，樂觀鎖在Java中是通過使用無(wú)鎖編程來實(shí)現(xiàn)，最常采用的是CAS算法，Java原子類中的遞增操作就通過CAS自旋實(shí)現(xiàn)的。

CAS全稱 Compare And Swap（比較與交換），是一種無(wú)鎖算法。在不使用鎖（沒有線程被阻塞）的情況下實(shí)現(xiàn)多線程之間的變量同步。java.util.concurrent包中的原子類就是通過CAS來實(shí)現(xiàn)了樂觀鎖。

簡(jiǎn)單來說，CAS算法有3個(gè)三個(gè)操作數(shù)：

• 需要讀寫的內(nèi)存值 V。
• 進(jìn)行比較的值 A。
• 要寫入的新值 B。

當(dāng)且僅當(dāng)預(yù)期值A(chǔ)和內(nèi)存值V相同時(shí)，將內(nèi)存值V修改為B，否則返回V。這是一種樂觀鎖的思路，它相信在它修改之前，沒有其它線程去修改它；而Synchronized是一種悲觀鎖，它認(rèn)為在它修改之前，一定會(huì)有其它線程去修改它，悲觀鎖效率很低。

2.悲觀鎖

總是假設(shè)最壞的情況，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人會(huì)修改，所以每次在拿數(shù)據(jù)的時(shí)候都會(huì)上鎖，這樣別人想拿這個(gè)數(shù)據(jù)就會(huì)阻塞直到它拿到鎖。

傳統(tǒng)的MySQL關(guān)系型數(shù)據(jù)庫(kù)里邊就用到了很多這種鎖機(jī)制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。

相對(duì)其他數(shù)據(jù)庫(kù)而言，MySQL的鎖機(jī)制比較簡(jiǎn)單，其最顯著的特點(diǎn)是不同的存儲(chǔ)引擎支持不同的鎖機(jī)制。

比如：

MyISAM和MEMORY存儲(chǔ)引擎采用的是表級(jí)鎖（table-level locking）；

InnoDB存儲(chǔ)引擎既支持行級(jí)鎖（ row-level locking），也支持表級(jí)鎖，但默認(rèn)情況下是采用行級(jí)鎖。

MySQL主要的兩種鎖的特性可大致歸納如下:

• 表級(jí)鎖： 開銷小，加鎖快；不會(huì)出現(xiàn)死鎖(因?yàn)镸yISAM會(huì)一次性獲得SQL所需的全部鎖)；鎖定粒度大，發(fā)生鎖沖突的概率最高,并發(fā)度最低。
• 行級(jí)鎖： 開銷大，加鎖慢；會(huì)出現(xiàn)死鎖；鎖定粒度最小，發(fā)生鎖沖突的概率最低,并發(fā)度也最高。
• 頁(yè)鎖：開銷和加鎖速度介于表鎖和行鎖之間；會(huì)出現(xiàn)死鎖；鎖定粒度介于表鎖和行鎖之間，并發(fā)度一般

行鎖 和 表鎖

1.主要是針對(duì)鎖粒度劃分的，一般分為：行鎖、表鎖、庫(kù)鎖

（1）行鎖：訪問數(shù)據(jù)庫(kù)的時(shí)候，鎖定整個(gè)行數(shù)據(jù)，防止并發(fā)錯(cuò)誤。

（2）表鎖：訪問數(shù)據(jù)庫(kù)的時(shí)候，鎖定整個(gè)表數(shù)據(jù)，防止并發(fā)錯(cuò)誤。

2.行鎖 和 表鎖 的區(qū)別：

• 表鎖： 開銷小，加鎖快，不會(huì)出現(xiàn)死鎖；鎖定力度大，發(fā)生鎖沖突概率高，并發(fā)度最低
• 行鎖： 開銷大，加鎖慢，會(huì)出現(xiàn)死鎖；鎖定粒度小，發(fā)生鎖沖突的概率低，并發(fā)度高

悲觀鎖 和 樂觀鎖

（1）悲觀鎖：顧名思義，就是很悲觀，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人會(huì)修改，所以每次在拿數(shù)據(jù)的時(shí)候都會(huì)上鎖，這樣別人想拿這個(gè)數(shù)據(jù)就會(huì)block直到它拿到鎖。

傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)里邊就用到了很多這種鎖機(jī)制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。

（2）樂觀鎖： 顧名思義，就是很樂觀，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人不會(huì)修改，所以不會(huì)上鎖，但是在更新的時(shí)候會(huì)判斷一下在此期間別人有沒有去更新這個(gè)數(shù)據(jù)，可以使用版本號(hào)等機(jī)制。

樂觀鎖適用于多讀的應(yīng)用類型，這樣可以提高吞吐量，像數(shù)據(jù)庫(kù)如果提供類似于write_condition機(jī)制的其實(shí)都是提供的樂觀鎖。

（3）悲觀鎖 和 樂觀鎖的區(qū)別：

兩種鎖各有優(yōu)缺點(diǎn)，不可認(rèn)為一種好于另一種，像樂觀鎖適用于寫比較少的情況下，即沖突真的很少發(fā)生的時(shí)候，這樣可以省去了鎖的開銷，加大了系統(tǒng)的整個(gè)吞吐量。但如果經(jīng)常產(chǎn)生沖突，上層應(yīng)用會(huì)不斷的進(jìn)行retry，這樣反倒是降低了性能，所以這種情況下用悲觀鎖就比較合適。

共享鎖

共享鎖指的就是對(duì)于多個(gè)不同的事務(wù)，對(duì)同一個(gè)資源共享同一個(gè)鎖。相當(dāng)于對(duì)于同一把門，它擁有多個(gè)鑰匙一樣。就像這樣，你家有一個(gè)大門，大門的鑰匙有好幾把，你有一把，你女朋友有一把，你們都可能通過這把鑰匙進(jìn)入你們家，這個(gè)就是所謂的共享鎖。

剛剛說了，對(duì)于悲觀鎖，一般數(shù)據(jù)庫(kù)已經(jīng)實(shí)現(xiàn)了，共享鎖也屬于悲觀鎖的一種，那么共享鎖在mysql中是通過什么命令來調(diào)用呢。通過查詢資料，了解到通過在執(zhí)行語(yǔ)句后面加上lock in share mode就代表對(duì)某些資源加上共享鎖了。

什么時(shí)候使用表鎖

對(duì)于InnoDB表，在絕大部分情況下都應(yīng)該使用行級(jí)鎖，因?yàn)槭聞?wù)和行鎖往往是我們之所以選擇InnoDB表的理由。但在個(gè)別特殊事務(wù)中，也可以考慮使用表級(jí)鎖。

• 第一種情況是：事務(wù)需要更新大部分或全部數(shù)據(jù)，表又比較大，如果使用默認(rèn)的行鎖，不僅這個(gè)事務(wù)執(zhí)行效率低，而且可能造成其他事務(wù)長(zhǎng)時(shí)間鎖等待和鎖沖突，這種情況下可以考慮使用表鎖來提高該事務(wù)的執(zhí)行速度。
• 第二種情況是：事務(wù)涉及多個(gè)表，比較復(fù)雜，很可能引起死鎖，造成大量事務(wù)回滾。這種情況也可以考慮一次性鎖定事務(wù)涉及的表，從而避免死鎖、減少數(shù)據(jù)庫(kù)因事務(wù)回滾帶來的開銷。

當(dāng)然，應(yīng)用中這兩種事務(wù)不能太多，否則，就應(yīng)該考慮使用MyISAM表了。

表鎖和行鎖應(yīng)用場(chǎng)景：

• 表級(jí)鎖使用與并發(fā)性不高，以查詢?yōu)橹?#xff0c;少量更新的應(yīng)用，比如小型的web應(yīng)用；
• 而行級(jí)鎖適用于高并發(fā)環(huán)境下，對(duì)事務(wù)完整性要求較高的系統(tǒng)，如在線事務(wù)處理系統(tǒng)。

再比如上面提到的Java的同步synchronized關(guān)鍵字的實(shí)現(xiàn)就是典型的悲觀鎖。

3.總之：

• 悲觀鎖適合寫操作多的場(chǎng)景，先加鎖可以保證寫操作時(shí)數(shù)據(jù)正確。
• 樂觀鎖適合讀操作多的場(chǎng)景，不加鎖的特點(diǎn)能夠使其讀操作的性能大幅提升。

公平鎖 VS 非公平鎖

1.公平鎖

就是很公平，在并發(fā)環(huán)境中，每個(gè)線程在獲取鎖時(shí)會(huì)先查看此鎖維護(hù)的等待隊(duì)列，如果為空，或者當(dāng)前線程是等待隊(duì)列的第一個(gè)，就占有鎖，否則就會(huì)加入到等待隊(duì)列中，以后會(huì)按照FIFO的規(guī)則從隊(duì)列中取到自己。

公平鎖的優(yōu)點(diǎn)是等待鎖的線程不會(huì)餓死。缺點(diǎn)是整體吞吐效率相對(duì)非公平鎖要低，等待隊(duì)列中除第一個(gè)線程以外的所有線程都會(huì)阻塞，CPU喚醒阻塞線程的開銷比非公平鎖大。

2.非公平鎖

上來就直接嘗試占有鎖，如果嘗試失敗，就再采用類似公平鎖那種方式。

非公平鎖的優(yōu)點(diǎn)是可以減少喚起線程的開銷，整體的吞吐效率高，因?yàn)榫€程有幾率不阻塞直接獲得鎖，CPU不必喚醒所有線程。缺點(diǎn)是處于等待隊(duì)列中的線程可能會(huì)餓死，或者等很久才會(huì)獲得鎖。

3.典型應(yīng)用:

java jdk并發(fā)包中的ReentrantLock可以指定構(gòu)造函數(shù)的boolean類型來創(chuàng)建公平鎖和非公平鎖（默認(rèn)）,比如：公平鎖可以使用new ReentrantLock(true)實(shí)現(xiàn)。

獨(dú)享鎖 VS 共享鎖

1.獨(dú)享鎖

是指該鎖一次只能被一個(gè)線程所持有。

2.共享鎖

是指該鎖可被多個(gè)線程所持有。

3.比較

對(duì)于Java ReentrantLock而言，其是獨(dú)享鎖。但是對(duì)于Lock的另一個(gè)實(shí)現(xiàn)類ReadWriteLock，其讀鎖是共享鎖，其寫鎖是獨(dú)享鎖。

讀鎖的共享鎖可保證并發(fā)讀是非常高效的，讀寫，寫讀 ，寫寫的過程是互斥的。

獨(dú)享鎖與共享鎖也是通過AQS來實(shí)現(xiàn)的，通過實(shí)現(xiàn)不同的方法，來實(shí)現(xiàn)獨(dú)享或者共享。

4.AQS

抽象隊(duì)列同步器（AbstractQueuedSynchronizer，簡(jiǎn)稱AQS）是用來構(gòu)建鎖或者其他同步組件的基礎(chǔ)框架，它使用一個(gè)整型的volatile變量（命名為state）來維護(hù)同步狀態(tài)，通過內(nèi)置的FIFO隊(duì)列來完成資源獲取線程的排隊(duì)工作。

concurrent包的實(shí)現(xiàn)結(jié)構(gòu)如上圖所示，AQS、非阻塞數(shù)據(jù)結(jié)構(gòu)和原子變量類等基礎(chǔ)類都是基于volatile變量的讀/寫和CAS實(shí)現(xiàn)，而像Lock、同步器、阻塞隊(duì)列、Executor和并發(fā)容器等高層類又是基于基礎(chǔ)類實(shí)現(xiàn)。

分段鎖

分段鎖其實(shí)是一種鎖的設(shè)計(jì)，并不是具體的一種鎖，對(duì)于ConcurrentHashMap而言，其并發(fā)的實(shí)現(xiàn)就是通過分段鎖的形式來實(shí)現(xiàn)高效的并發(fā)操作。

我們以ConcurrentHashMap來說一下分段鎖的含義以及設(shè)計(jì)思想，ConcurrentHashMap中的分段鎖稱為Segment，它即類似于HashMap（JDK7與JDK8中HashMap的實(shí)現(xiàn)）的結(jié)構(gòu)，即內(nèi)部擁有一個(gè)Entry數(shù)組，數(shù)組中的每個(gè)元素又是一個(gè)鏈表；同時(shí)又是一個(gè)ReentrantLock（Segment繼承了ReentrantLock)。

當(dāng)需要put元素的時(shí)候，并不是對(duì)整個(gè)hashmap進(jìn)行加鎖，而是先通過hashcode來知道他要放在那一個(gè)分段中，然后對(duì)這個(gè)分段進(jìn)行加鎖，所以當(dāng)多線程put的時(shí)候，只要不是放在一個(gè)分段中，就實(shí)現(xiàn)了真正的并行的插入。

但是，在統(tǒng)計(jì)size的時(shí)候，可就是獲取hashmap全局信息的時(shí)候，就需要獲取所有的分段鎖才能統(tǒng)計(jì)。

分段鎖的設(shè)計(jì)目的是細(xì)化鎖的粒度，當(dāng)操作不需要更新整個(gè)數(shù)組的時(shí)候，就僅僅針對(duì)數(shù)組中的一項(xiàng)進(jìn)行加鎖操作。

Java線程鎖

多線程資源空閑

線程死鎖

鎖的選擇

由于多個(gè)線程是共同占有所屬進(jìn)程的資源和地址空間的，那么就會(huì)存在一個(gè)問題：

如果多個(gè)線程要同時(shí)訪問某個(gè)資源，怎么處理？

在Java并發(fā)編程中，經(jīng)常遇到多個(gè)線程訪問同一個(gè) 共享資源 ，這時(shí)候作為開發(fā)者必須考慮如何維護(hù)數(shù)據(jù)一致性，這就是Java鎖機(jī)制(同步問題)的來源。

Java提供了多種多線程鎖機(jī)制的實(shí)現(xiàn)方式，常見的有：

synchronized

ReentrantLock

Semaphore

AtomicInteger等

每種機(jī)制都有優(yōu)缺點(diǎn)與各自的適用場(chǎng)景，必須熟練掌握他們的特點(diǎn)才能在Java多線程應(yīng)用開發(fā)時(shí)得心應(yīng)手。

4種Java線程鎖(線程同步)

1.synchronized

在Java中synchronized關(guān)鍵字被常用于維護(hù)數(shù)據(jù)一致性。

synchronized機(jī)制是給共享資源上鎖，只有拿到鎖的線程才可以訪問共享資源，這樣就可以強(qiáng)制使得對(duì)共享資源的訪問都是順序的。

Java開發(fā)人員都認(rèn)識(shí)synchronized，使用它來實(shí)現(xiàn)多線程的同步操作是非常簡(jiǎn)單的，只要在需要同步的對(duì)方的方法、類或代碼塊中加入該關(guān)鍵字，它能夠保證在同一個(gè)時(shí)刻最多只有一個(gè)線程執(zhí)行同一個(gè)對(duì)象的同步代碼，可保證修飾的代碼在執(zhí)行過程中不會(huì)被其他線程干擾。使用synchronized修飾的代碼具有原子性和可見性，在需要進(jìn)程同步的程序中使用的頻率非常高，可以滿足一般的進(jìn)程同步要求。

synchronized (obj) {

//方法

…….

}

synchronized實(shí)現(xiàn)的機(jī)理依賴于軟件層面上的JVM，因此其性能會(huì)隨著Java版本的不斷升級(jí)而提高。

到了Java1.6，synchronized進(jìn)行了很多的優(yōu)化，有適應(yīng)自旋、鎖消除、鎖粗化、輕量級(jí)鎖及偏向鎖等，效率有了本質(zhì)上的提高。在之后推出的Java1.7與1.8中，均對(duì)該關(guān)鍵字的實(shí)現(xiàn)機(jī)理做了優(yōu)化。

需要說明的是，當(dāng)線程通過synchronized等待鎖時(shí)是不能被Thread.interrupt()中斷的，因此程序設(shè)計(jì)時(shí)必須檢查確保合理，否則可能會(huì)造成線程死鎖的尷尬境地。

最后，盡管Java實(shí)現(xiàn)的鎖機(jī)制有很多種，并且有些鎖機(jī)制性能也比synchronized高，但還是強(qiáng)烈推薦在多線程應(yīng)用程序中使用該關(guān)鍵字，因?yàn)閷?shí)現(xiàn)方便，后續(xù)工作由JVM來完成，可靠性高。只有在確定鎖機(jī)制是當(dāng)前多線程程序的性能瓶頸時(shí)，才考慮使用其他機(jī)制，如ReentrantLock等。

2.ReentrantLock

可重入鎖，顧名思義，這個(gè)鎖可以被線程多次重復(fù)進(jìn)入進(jìn)行獲取操作。

ReentantLock繼承接口Lock并實(shí)現(xiàn)了接口中定義的方法，除了能完成synchronized所能完成的所有工作外，還提供了諸如可響應(yīng)中斷鎖、可輪詢鎖請(qǐng)求、定時(shí)鎖等避免多線程死鎖的方法。

Lock實(shí)現(xiàn)的機(jī)理依賴于特殊的CPU指定，可以認(rèn)為不受JVM的約束，并可以通過其他語(yǔ)言平臺(tái)來完成底層的實(shí)現(xiàn)。在并發(fā)量較小的多線程應(yīng)用程序中，ReentrantLock與synchronized性能相差無(wú)幾，但在高并發(fā)量的條件下，synchronized性能會(huì)迅速下降幾十倍，而ReentrantLock的性能卻能依然維持一個(gè)水準(zhǔn)。

因此我們建議在高并發(fā)量情況下使用ReentrantLock。

ReentrantLock引入兩個(gè)概念：公平鎖與非公平鎖。

公平鎖指的是鎖的分配機(jī)制是公平的，通常先對(duì)鎖提出獲取請(qǐng)求的線程會(huì)先被分配到鎖。反之，JVM按隨機(jī)、就近原則分配鎖的機(jī)制則稱為不公平鎖。

ReentrantLock在構(gòu)造函數(shù)中提供了是否公平鎖的初始化方式，默認(rèn)為非公平鎖。這是因?yàn)?#xff0c;非公平鎖實(shí)際執(zhí)行的效率要遠(yuǎn)遠(yuǎn)超出公平鎖，除非程序有特殊需要，否則最常用非公平鎖的分配機(jī)制。

ReentrantLock通過方法lock()與unlock()來進(jìn)行加鎖與解鎖操作，與synchronized會(huì)被JVM自動(dòng)解鎖機(jī)制不同，ReentrantLock加鎖后需要手動(dòng)進(jìn)行解鎖。為了避免程序出現(xiàn)異常而無(wú)法正常解鎖的情況，使用ReentrantLock必須在finally控制塊中進(jìn)行解鎖操作。通常使用方式如下所示：

Lock lock = new ReentrantLock();

try {

lock.lock();

//…進(jìn)行任務(wù)操作5 }

finally {

lock.unlock();

}

3.Semaphore

上述兩種鎖機(jī)制類型都是“互斥鎖”，學(xué)過操作系統(tǒng)的都知道，互斥是進(jìn)程同步關(guān)系的一種特殊情況，相當(dāng)于只存在一個(gè)臨界資源，因此同時(shí)最多只能給一個(gè)線程提供服務(wù)。但是，在實(shí)際復(fù)雜的多線程應(yīng)用程序中，可能存在多個(gè)臨界資源，這時(shí)候我們可以借助Semaphore信號(hào)量來完成多個(gè)臨界資源的訪問。

Semaphore基本能完成ReentrantLock的所有工作，使用方法也與之類似，通過acquire()與release()方法來獲得和釋放臨界資源。

經(jīng)實(shí)測(cè)，Semaphone.acquire()方法默認(rèn)為可響應(yīng)中斷鎖，與ReentrantLock.lockInterruptibly()作用效果一致，也就是說在等待臨界資源的過程中可以被Thread.interrupt()方法中斷。

此外，Semaphore也實(shí)現(xiàn)了可輪詢的鎖請(qǐng)求與定時(shí)鎖的功能，除了方法名tryAcquire與tryLock不同，其使用方法與ReentrantLock幾乎一致。Semaphore也提供了公平與非公平鎖的機(jī)制，也可在構(gòu)造函數(shù)中進(jìn)行設(shè)定。

Semaphore的鎖釋放操作也由手動(dòng)進(jìn)行，因此與ReentrantLock一樣，為避免線程因拋出異常而無(wú)法正常釋放鎖的情況發(fā)生，釋放鎖的操作也必須在finally代碼塊中完成。

4.AtomicInteger

首先說明，此處AtomicInteger是一系列相同類的代表之一，常見的還有AtomicLong、AtomicLong等，他們的實(shí)現(xiàn)原理相同，區(qū)別在與運(yùn)算對(duì)象類型的不同。

我們知道，在多線程程序中，諸如++i
或
i++等運(yùn)算不具有原子性，是不安全的線程操作之一。通常我們會(huì)使用synchronized將該操作變成一個(gè)原子操作，但JVM為此類操作特意提供了一些同步類，使得使用更方便，且使程序運(yùn)行效率變得更高。通過相關(guān)資料顯示，通常AtomicInteger的性能是ReentantLock的好幾倍。

Java線程鎖總結(jié)

1.synchronized：

在資源競(jìng)爭(zhēng)不是很激烈的情況下，偶爾會(huì)有同步的情形下，synchronized是很合適的。原因在于，編譯程序通常會(huì)盡可能的進(jìn)行優(yōu)化synchronize，另外可讀性非常好。

2.ReentrantLock:

在資源競(jìng)爭(zhēng)不激烈的情形下，性能稍微比synchronized差點(diǎn)點(diǎn)。但是當(dāng)同步非常激烈的時(shí)候，synchronized的性能一下子能下降好幾十倍，而ReentrantLock確還能維持常態(tài)。

高并發(fā)量情況下使用ReentrantLock。

3.Atomic:

和上面的類似，不激烈情況下，性能比synchronized略遜，而激烈的時(shí)候，也能維持常態(tài)。激烈的時(shí)候，Atomic的性能會(huì)優(yōu)于ReentrantLock一倍左右。但是其有一個(gè)缺點(diǎn)，就是只能同步一個(gè)值，一段代碼中只能出現(xiàn)一個(gè)Atomic的變量，多于一個(gè)同步無(wú)效。因?yàn)樗荒茉诙鄠€(gè)Atomic之間同步。

所以，我們寫同步的時(shí)候，優(yōu)先考慮synchronized，如果有特殊需要，再進(jìn)一步優(yōu)化。ReentrantLock和Atomic如果用的不好，不僅不能提高性能，還可能帶來災(zāi)難。

以上就是Java線程鎖的詳解，除了從編程的角度應(yīng)對(duì)高并發(fā)，更多還需要從架構(gòu)設(shè)計(jì)的層面來應(yīng)對(duì)高并發(fā)場(chǎng)景，例如：Redis緩存、CDN、異步消息等，詳細(xì)的內(nèi)容如下。

轉(zhuǎn)載于:https://juejin.im/post/5cf5eb2df265da1bca51c77c

總結(jié)

以上是生活随笔為你收集整理的Java锁详解：“独享锁/共享锁+公平锁/非公平锁+乐观锁/悲观锁+线程锁”的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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