ps：這連天看鎖看了好多資料，資料也不分前后順序，理順概念，搞定關(guān)聯(lián)脈絡(luò)著是廢了一番勁，總算是基本搞清楚了，真是不容易啊，這個時刻我想起一句話：越往深里學，越得看書，權(quán)威書籍的資料更全面，連貫

老規(guī)矩，妹子鎮(zhèn)樓，撫慰心靈

鎖涉及到的點

鎖涉及到的點很多，這里從底層向上列舉出來：

AQS(抽象隊列同步器)、非阻塞數(shù)據(jù)結(jié)構(gòu)和原子變量類等基礎(chǔ)類都是基于 volatile 變量的讀/寫和 CAS 實現(xiàn)，是 Java 并發(fā)包里實現(xiàn)鎖、同步的一個重要的基礎(chǔ)框架，而像 Lock 、同步器、阻塞隊列、Executor 和并發(fā)容器等高層類又是基于基礎(chǔ)類實現(xiàn)

其實每個部分都可以講很多，這里列出來，大家心里有個數(shù)

java 線程阻塞的代價

• 如果要阻塞或喚醒一個線程就需要操作系統(tǒng)介入，需要在戶態(tài)與核心態(tài)之間切換，這種切換會消耗大量的系統(tǒng)資源，因為用戶態(tài)與內(nèi)核態(tài)都有各自專用的內(nèi)存空間，專用的寄存器等，用戶態(tài)切換至內(nèi)核態(tài)需要傳遞給許多變量、參數(shù)給內(nèi)核，內(nèi)核也需要保護好用戶態(tài)在切換時的一些寄存器值、變量等，以便內(nèi)核態(tài)調(diào)用結(jié)束后切換回用戶態(tài)繼續(xù)工作
• 如果線程狀態(tài)切換是一個高頻操作時，這將會消耗很多CPU處理時間
• 如果對于那些需要同步的簡單的代碼塊，獲取鎖掛起操作消耗的時間比用戶代碼執(zhí)行的時間還要長，這種同步策略顯然非常糟糕的
• 另外線程的切換還涉及到線程自身的上下文切換，原理和戶態(tài) -> 核心態(tài)切換一樣

Synchronize 原理

簡單來說 Synchronize 是通過 JVM 的對象監(jiān)視器 Monitor 進入和退出命令來實現(xiàn)對方法、同步塊的同步的，在進入同步方法調(diào)用前加入一個 monitor.enter 指令，在退出方法和異常處插入 monitor.exit 的指令，本質(zhì)就是獲取一個 Monitor，而這個獲取過程具有排他性從而達到了同一時刻只能一個線程訪問的目的，而對于沒有獲取到鎖的線程將會阻塞到方法入口處，直到獲取鎖的線程 monitor.exit 之后才能嘗試繼續(xù)獲取鎖。

然后我們來看看線程在進入同步隊列之后是怎么競爭資源的

別的不用關(guān)系，我們熟悉 Contention List 、EntryList 就行

競爭順序：

• 首先競爭鎖的線程第一次會加入到 Contention List 這個隊列里
• 然后在 Owner unlock 也就是當前線程完事釋放鎖之后，從 Contention List 里面挑選由資格競爭鎖的線程放到 EntryList 里面來
• EntryList 里面所有的線程被喚醒，做一次非公平的 CAS 競爭

其他特征：

• WaitSet 里面放的是被 obj.wait 的線程，只有 notify 、nitifyAll 時才會重新參與競爭
• 處于 ContentionList、EntryList、WaitSet 中的線程都處于阻塞狀態(tài)，每次喚醒 EntryList 里面的線程是很大的性能開銷
• 更坑爹的是 Synchronized 是非公平鎖，外面等待的線程會先嘗試自旋獲取鎖，如果獲取不到才進入ContentionList，這明顯對于已經(jīng)進入隊列的線程是不公平的，還有一個不公平的事情就是自旋獲取鎖的線程還可能直接獲得鎖資源

鎖的特性

這里介紹 java 中并發(fā)核心鎖的特性，不是具體的鎖，具體的鎖一般都是多種特性符合存在的，但是的確有些鎖只具有一種特性，但是這種鎖一般都是有專門應(yīng)用場景的，不具有普遍適用性

• 公平鎖 / 非公平鎖
• 獨享鎖/共享鎖
• 樂觀鎖/悲觀鎖
• 可重入鎖
• 分段鎖
• 自旋鎖

樂觀鎖 / 悲觀鎖

• 樂觀鎖 - 既無鎖機制，好比做人，這個人很樂觀，每次訪問數(shù)據(jù)的時候都認為別人不會修改，也就不加鎖。適用于多并發(fā)讀的場景，CAS算法就是最典型的樂觀鎖

• 悲觀鎖 - 看名字自然也知道悲觀鎖是樂觀鎖的對立面，悲觀鎖在獲取資源時不管有沒有來競爭，都先加一把鎖，這也是并發(fā)中最常用也普通的做法，保險不會出錯，但是缺點是性能不高，使用于多并發(fā)寫的場景

公平鎖 / 非公平鎖

• 公平鎖 - 這個也好理解，還是好比做人，公平鎖做人很規(guī)矩，在希望申請資源時，先看看有沒有其他線程排隊等著，有的話就去后面排隊去。缺點同樣是性能低，等待隊列中除第一個線程以外的所有線程都會阻塞，CPU喚醒阻塞線程的開銷比非公平鎖大

• 非公平鎖 - 非公平鎖自然也是公平鎖對立的，非公平鎖做人就不地道了，這丫的不排隊，非公平鎖來了才不管你有沒有排隊等著，直接競爭資源，沒競爭才取排隊。優(yōu)點是比公平鎖性能好些，新的線程有可能直接獲取到 cpu 資源從而減少喚醒阻塞線程的開銷

• 典型應(yīng)用 - 就是 ReentrantLock 這個鎖，ReentrantLock(true) 構(gòu)造參數(shù)有一個 boolean 值，true = 公平鎖 ，false = 非公平鎖（默認）

獨享鎖 / 共享鎖

• 獨享鎖 - 鎖只能被一個線程持有， 絕大部分鎖都是獨享鎖，比如我們常用的 synchronized、ReentrantLock 都是獨享鎖
• 共享鎖 - 鎖可以被多個線程持有，但是共享鎖的應(yīng)用非常狹窄，比如 ReadWriteLock 就是共享鎖， 其寫鎖是獨享鎖，讀鎖是共享鎖

分段鎖

• 分段鎖 - 是特定領(lǐng)域的鎖，一般數(shù)據(jù)結(jié)構(gòu)上多見，比如 ConcurrentHashMap 用的就是這種鎖。分段鎖核心思路細化鎖的粒度，把整體分成多段，每段有一把鎖，這樣鎖住的只是一段，不影響其他段的讀寫。在 ConcurrentHashMap 中就是給每個分段鏈表加一把鎖，這樣可以大大提高 map 在多線程下整體的讀寫效率。但是在統(tǒng)計 size 的時候，可就是獲取 hashmap 全局信息的時候，就需要獲取所有的分段鎖才能統(tǒng)計

可重入鎖

• 可重入鎖 - 指的是同一個方法若是已經(jīng)獲取了鎖，但是在方法內(nèi)還有地方需要這個鎖的話，可以不受鎖的影響，無阻礙的獲得鎖，這點在遞歸函數(shù)中是至關(guān)重要的，所以也叫可重入鎖遞歸鎖。ReentrantLock、synchronized 都是可重入鎖，但是自旋鎖就不是可重入鎖

自旋鎖

自旋鎖是互斥鎖的進步，自旋鎖在有其他線程競爭同步代碼時，我們可以讓后面請求鎖的那個線程“稍等一會”，但不放棄處理器的執(zhí)行時間，看看持有鎖的線程是否很快就會釋放鎖，為了讓線程等待，我們只須讓線程執(zhí)行一個忙循環(huán)（自旋），這項技術(shù)就是所謂的自旋鎖。這種優(yōu)化思路就是基于前面說的鎖阻塞的時間總是很短的考量

自旋鎖在 JDK 1.4 中就已經(jīng)引入，只不過默認是關(guān)閉的，在 JDK 1.6 中就已經(jīng)改為默認開啟了，但是自旋鎖也有自身的局限

java 中鎖的 API

• synchronized - 由 JVM 實現(xiàn)的內(nèi)置鎖，其特征是：非公平，悲觀，獨享，互斥，可重入鎖，在 JDL 1.6 對其優(yōu)化之后，可以根據(jù)競爭激烈程度，從 無鎖 -> 偏向鎖 -> 輕量級所 -> 重量級鎖升級
• ReentrantLock - 基于 AQS 開發(fā)的可重入鎖，自旋鎖，由 JDK 實現(xiàn)，有公平和非公平之分，也可以感知到中斷。ReenTrantLock的自旋，是通過循環(huán)調(diào)用 CAS 操作來實現(xiàn)加鎖的，它的性能好是因為避免了使線程進入內(nèi)核態(tài)的阻塞狀態(tài)
• Condition - 條件鎖，用在阻塞隊列中，可控制消費者和生產(chǎn)者的讀取進度
• ReentrantReadWriteLock - 讀寫鎖，讀和寫拆開，可以極大的提高讀多寫少的場景下的性能
• CyclicBarrier - 同樣是基于 AQS 開發(fā)的鎖，也叫柵欄鎖，有換代的操作，可重置（想象成多個柵欄一般）
• CountDownLatch - 基于AQS開發(fā)的鎖，也叫計時器鎖，當計數(shù)器減為0后，就可以執(zhí)行其他任務(wù)了，不可重置
• - 3.Semaphore
• AtomicInteger -

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

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

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

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

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

性能對比：

• synchronized 經(jīng)過 JDK 1.6 的優(yōu)化，在低并發(fā)時 ReentrantLock 和 synchronized 性能相差無幾，但在高并發(fā)時 synchronized 性能會迅速下降幾十倍，而 ReentrantLock 的性能卻能依然維持一個水準，因為 ReentrantLock 采取的是循環(huán)調(diào)用 CAS 避免了線程切換到阻塞，所以在高并發(fā)時建議使用ReentrantLock
• 非公平鎖實際執(zhí)行效率要遠遠超出公平鎖，一般推薦使用非公平鎖
• 在高并發(fā)時 Atomic 性能會優(yōu)于 ReentrantLock 一倍左右，但是 Atomic 在一段同步代碼中只能出現(xiàn)一個 Atomic 的變量，多于一個同步無效，因為他不能在多個Atomic之間同步

鎖使用策略：

一般來說同步我們優(yōu)先考慮 synchronized ，synchronized 是 JVM 層面的，自動加鎖取消鎖，不會出 bug，如果有特殊需要再進一步優(yōu)化。ReentrantLock 和 Atomic 如果用的不好，不僅不能提高性能，還可能帶來災(zāi)難

參考資料：

• 最全Java鎖詳解：獨享鎖/共享鎖+公平鎖/非公平鎖+樂觀鎖/悲觀鎖