Java锁详解：“独享锁/共享锁+公平锁/非公平锁+乐观锁/悲观锁+线程锁”
在Java并發場景中，會涉及到各種各樣的鎖如公平鎖，樂觀鎖，悲觀鎖等等，這篇文章介紹各種鎖的分類：
公平鎖/非公平鎖
可重入鎖
獨享鎖/共享鎖
樂觀鎖/悲觀鎖
分段鎖
自旋鎖
線程鎖
樂觀鎖 VS 悲觀鎖
樂觀鎖與悲觀鎖是一種廣義上的概念，體現了看待線程同步的不同角度，在Java和數據庫中都有此概念對應的實際應用。
1.樂觀鎖
顧名思義，就是很樂觀，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制。
樂觀鎖適用于多讀的應用類型，樂觀鎖在Java中是通過使用無鎖編程來實現，最常采用的是CAS算法，Java原子類中的遞增操作就通過CAS自旋實現的。
CAS全稱 Compare And Swap（比較與交換），是一種無鎖算法。在不使用鎖（沒有線程被阻塞）的情況下實現多線程之間的變量同步。java.util.concurrent包中的原子類就是通過CAS來實現了樂觀鎖。
簡單來說，CAS算法有3個三個操作數：
- 需要讀寫的內存值 V。
- 進行比較的值 A。
- 要寫入的新值 B。
當且僅當預期值A和內存值V相同時，將內存值V修改為B，否則返回V。這是一種樂觀鎖的思路，它相信在它修改之前，沒有其它線程去修改它；而Synchronized是一種悲觀鎖，它認為在它修改之前，一定會有其它線程去修改它，悲觀鎖效率很低。
2.悲觀鎖
總是假設最壞的情況，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會阻塞直到它拿到鎖。
傳統的MySQL關系型數據庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。
相對其他數據庫而言，MySQL的鎖機制比較簡單，其最顯著的特點是不同的存儲引擎支持不同的鎖機制。
比如：
MySQL主要的兩種鎖的特性可大致歸納如下:
- 表級鎖： 開銷小，加鎖快；不會出現死鎖(因為MyISAM會一次性獲得SQL所需的全部鎖)；鎖定粒度大，發生鎖沖突的概率最高,并發度最低。
- 行級鎖： 開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低,并發度也最高。
- 頁鎖：開銷和加鎖速度介于表鎖和行鎖之間；會出現死鎖；鎖定粒度介于表鎖和行鎖之間，并發度一般
行鎖 和 表鎖
1.主要是針對鎖粒度劃分的，一般分為：行鎖、表鎖、庫鎖
（1）行鎖：訪問數據庫的時候，鎖定整個行數據，防止并發錯誤。
（2）表鎖：訪問數據庫的時候，鎖定整個表數據，防止并發錯誤。
2.行鎖 和 表鎖 的區別：
- 表鎖： 開銷小，加鎖快，不會出現死鎖；鎖定力度大，發生鎖沖突概率高，并發度最低
- 行鎖： 開銷大，加鎖慢，會出現死鎖；鎖定粒度小，發生鎖沖突的概率低，并發度高
悲觀鎖 和 樂觀鎖
（1）悲觀鎖：顧名思義，就是很悲觀，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。
傳統的關系型數據庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。
（2）樂觀鎖： 顧名思義，就是很樂觀，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制。
樂觀鎖適用于多讀的應用類型，這樣可以提高吞吐量，像數據庫如果提供類似于write_condition機制的其實都是提供的樂觀鎖。
（3）悲觀鎖 和 樂觀鎖的區別：
兩種鎖各有優缺點，不可認為一種好于另一種，像樂觀鎖適用于寫比較少的情況下，即沖突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果經常產生沖突，上層應用會不斷的進行retry，這樣反倒是降低了性能，所以這種情況下用悲觀鎖就比較合適。
共享鎖
共享鎖指的就是對于多個不同的事務，對同一個資源共享同一個鎖。相當于對于同一把門，它擁有多個鑰匙一樣。就像這樣，你家有一個大門，大門的鑰匙有好幾把，你有一把，你女朋友有一把，你們都可能通過這把鑰匙進入你們家，這個就是所謂的共享鎖。
剛剛說了，對于悲觀鎖，一般數據庫已經實現了，共享鎖也屬于悲觀鎖的一種，那么共享鎖在mysql中是通過什么命令來調用呢。通過查詢資料，了解到通過在執行語句后面加上lock in share mode就代表對某些資源加上共享鎖了。
什么時候使用表鎖
對于InnoDB表，在絕大部分情況下都應該使用行級鎖，因為事務和行鎖往往是我們之所以選擇InnoDB表的理由。但在個別特殊事務中，也可以考慮使用表級鎖。
- 第一種情況是：事務需要更新大部分或全部數據，表又比較大，如果使用默認的行鎖，不僅這個事務執行效率低，而且可能造成其他事務長時間鎖等待和鎖沖突，這種情況下可以考慮使用表鎖來提高該事務的執行速度。
- 第二種情況是：事務涉及多個表，比較復雜，很可能引起死鎖，造成大量事務回滾。這種情況也可以考慮一次性鎖定事務涉及的表，從而避免死鎖、減少數據庫因事務回滾帶來的開銷。
當然，應用中這兩種事務不能太多，否則，就應該考慮使用MyISAM表了。
表鎖和行鎖應用場景：
- 表級鎖使用與并發性不高，以查詢為主，少量更新的應用，比如小型的web應用；
- 而行級鎖適用于高并發環境下，對事務完整性要求較高的系統，如在線事務處理系統。
再比如上面提到的Java的同步synchronized關鍵字的實現就是典型的悲觀鎖。
3.總之：
- 悲觀鎖適合寫操作多的場景，先加鎖可以保證寫操作時數據正確。
- 樂觀鎖適合讀操作多的場景，不加鎖的特點能夠使其讀操作的性能大幅提升。
公平鎖 VS 非公平鎖
1.公平鎖
就是很公平，在并發環境中，每個線程在獲取鎖時會先查看此鎖維護的等待隊列，如果為空，或者當前線程是等待隊列的第一個，就占有鎖，否則就會加入到等待隊列中，以后會按照FIFO的規則從隊列中取到自己。
公平鎖的優點是等待鎖的線程不會餓死。缺點是整體吞吐效率相對非公平鎖要低，等待隊列中除第一個線程以外的所有線程都會阻塞，CPU喚醒阻塞線程的開銷比非公平鎖大。
2.非公平鎖
上來就直接嘗試占有鎖，如果嘗試失敗，就再采用類似公平鎖那種方式。
非公平鎖的優點是可以減少喚起線程的開銷，整體的吞吐效率高，因為線程有幾率不阻塞直接獲得鎖，CPU不必喚醒所有線程。缺點是處于等待隊列中的線程可能會餓死，或者等很久才會獲得鎖。
3.典型應用:
java jdk并發包中的ReentrantLock可以指定構造函數的boolean類型來創建公平鎖和非公平鎖（默認）,比如：公平鎖可以使用new ReentrantLock(true)實現。
獨享鎖 VS 共享鎖
1.獨享鎖
是指該鎖一次只能被一個線程所持有。
2.共享鎖
是指該鎖可被多個線程所持有。
3.比較
對于Java ReentrantLock而言，其是獨享鎖。但是對于Lock的另一個實現類ReadWriteLock，其讀鎖是共享鎖，其寫鎖是獨享鎖。
讀鎖的共享鎖可保證并發讀是非常高效的，讀寫，寫讀 ，寫寫的過程是互斥的。
獨享鎖與共享鎖也是通過AQS來實現的，通過實現不同的方法，來實現獨享或者共享。
4.AQS
抽象隊列同步器（AbstractQueuedSynchronizer，簡稱AQS）是用來構建鎖或者其他同步組件的基礎框架，它使用一個整型的volatile變量（命名為state）來維護同步狀態，通過內置的FIFO隊列來完成資源獲取線程的排隊工作。
concurrent包的實現結構如上圖所示，AQS、非阻塞數據結構和原子變量類等基礎類都是基于volatile變量的讀/寫和CAS實現，而像Lock、同步器、阻塞隊列、Executor和并發容器等高層類又是基于基礎類實現。
分段鎖
分段鎖其實是一種鎖的設計，并不是具體的一種鎖，對于ConcurrentHashMap而言，其并發的實現就是通過分段鎖的形式來實現高效的并發操作。
我們以ConcurrentHashMap來說一下分段鎖的含義以及設計思想，ConcurrentHashMap中的分段鎖稱為Segment，它即類似于HashMap（JDK7與JDK8中HashMap的實現）的結構，即內部擁有一個Entry數組，數組中的每個元素又是一個鏈表；同時又是一個ReentrantLock（Segment繼承了ReentrantLock)。
當需要put元素的時候，并不是對整個hashmap進行加鎖，而是先通過hashcode來知道他要放在那一個分段中，然后對這個分段進行加鎖，所以當多線程put的時候，只要不是放在一個分段中，就實現了真正的并行的插入。
但是，在統計size的時候，可就是獲取hashmap全局信息的時候，就需要獲取所有的分段鎖才能統計。
分段鎖的設計目的是細化鎖的粒度，當操作不需要更新整個數組的時候，就僅僅針對數組中的一項進行加鎖操作。
Java線程鎖
多線程資源空閑
線程死鎖
鎖的選擇
由于多個線程是共同占有所屬進程的資源和地址空間的，那么就會存在一個問題：
如果多個線程要同時訪問某個資源，怎么處理？
在Java并發編程中，經常遇到多個線程訪問同一個 共享資源 ，這時候作為開發者必須考慮如何維護數據一致性，這就是Java鎖機制(同步問題)的來源。
Java提供了多種多線程鎖機制的實現方式，常見的有：
每種機制都有優缺點與各自的適用場景，必須熟練掌握他們的特點才能在Java多線程應用開發時得心應手。
4種Java線程鎖(線程同步)
1.synchronized
在Java中synchronized關鍵字被常用于維護數據一致性。
synchronized機制是給共享資源上鎖，只有拿到鎖的線程才可以訪問共享資源，這樣就可以強制使得對共享資源的訪問都是順序的。
Java開發人員都認識synchronized，使用它來實現多線程的同步操作是非常簡單的，只要在需要同步的對方的方法、類或代碼塊中加入該關鍵字，它能夠保證在同一個時刻最多只有一個線程執行同一個對象的同步代碼，可保證修飾的代碼在執行過程中不會被其他線程干擾。使用synchronized修飾的代碼具有原子性和可見性，在需要進程同步的程序中使用的頻率非常高，可以滿足一般的進程同步要求。
synchronized (obj) {
//方法
…….
}
synchronized實現的機理依賴于軟件層面上的JVM，因此其性能會隨著Java版本的不斷升級而提高。
到了Java1.6，synchronized進行了很多的優化，有適應自旋、鎖消除、鎖粗化、輕量級鎖及偏向鎖等，效率有了本質上的提高。在之后推出的Java1.7與1.8中，均對該關鍵字的實現機理做了優化。
需要說明的是，當線程通過synchronized等待鎖時是不能被Thread.interrupt()中斷的，因此程序設計時必須檢查確保合理，否則可能會造成線程死鎖的尷尬境地。
最后，盡管Java實現的鎖機制有很多種，并且有些鎖機制性能也比synchronized高，但還是強烈推薦在多線程應用程序中使用該關鍵字，因為實現方便，后續工作由JVM來完成，可靠性高。只有在確定鎖機制是當前多線程程序的性能瓶頸時，才考慮使用其他機制，如ReentrantLock等。
2.ReentrantLock
可重入鎖，顧名思義，這個鎖可以被線程多次重復進入進行獲取操作。
ReentantLock繼承接口Lock并實現了接口中定義的方法，除了能完成synchronized所能完成的所有工作外，還提供了諸如可響應中斷鎖、可輪詢鎖請求、定時鎖等避免多線程死鎖的方法。
Lock實現的機理依賴于特殊的CPU指定，可以認為不受JVM的約束，并可以通過其他語言平臺來完成底層的實現。在并發量較小的多線程應用程序中，ReentrantLock與synchronized性能相差無幾，但在高并發量的條件下，synchronized性能會迅速下降幾十倍，而ReentrantLock的性能卻能依然維持一個水準。
因此我們建議在高并發量情況下使用ReentrantLock。
ReentrantLock引入兩個概念：公平鎖與非公平鎖。
公平鎖指的是鎖的分配機制是公平的，通常先對鎖提出獲取請求的線程會先被分配到鎖。反之，JVM按隨機、就近原則分配鎖的機制則稱為不公平鎖。
ReentrantLock在構造函數中提供了是否公平鎖的初始化方式，默認為非公平鎖。這是因為，非公平鎖實際執行的效率要遠遠超出公平鎖，除非程序有特殊需要，否則最常用非公平鎖的分配機制。
ReentrantLock通過方法lock()與unlock()來進行加鎖與解鎖操作，與synchronized會被JVM自動解鎖機制不同，ReentrantLock加鎖后需要手動進行解鎖。為了避免程序出現異常而無法正常解鎖的情況，使用ReentrantLock必須在finally控制塊中進行解鎖操作。通常使用方式如下所示：
Lock lock = new ReentrantLock();
try {
lock.lock();
//…進行任務操作5 }
finally {
lock.unlock();
}
3.Semaphore
上述兩種鎖機制類型都是“互斥鎖”，學過操作系統的都知道，互斥是進程同步關系的一種特殊情況，相當于只存在一個臨界資源，因此同時最多只能給一個線程提供服務。但是，在實際復雜的多線程應用程序中，可能存在多個臨界資源，這時候我們可以借助Semaphore信號量來完成多個臨界資源的訪問。
Semaphore基本能完成ReentrantLock的所有工作，使用方法也與之類似，通過acquire()與release()方法來獲得和釋放臨界資源。
經實測，Semaphone.acquire()方法默認為可響應中斷鎖，與ReentrantLock.lockInterruptibly()作用效果一致，也就是說在等待臨界資源的過程中可以被Thread.interrupt()方法中斷。
此外，Semaphore也實現了可輪詢的鎖請求與定時鎖的功能，除了方法名tryAcquire與tryLock不同，其使用方法與ReentrantLock幾乎一致。Semaphore也提供了公平與非公平鎖的機制，也可在構造函數中進行設定。
Semaphore的鎖釋放操作也由手動進行，因此與ReentrantLock一樣，為避免線程因拋出異常而無法正常釋放鎖的情況發生，釋放鎖的操作也必須在finally代碼塊中完成。
4.AtomicInteger
首先說明，此處AtomicInteger是一系列相同類的代表之一，常見的還有AtomicLong、AtomicLong等，他們的實現原理相同，區別在與運算對象類型的不同。
我們知道，在多線程程序中，諸如++i
或
i++等運算不具有原子性，是不安全的線程操作之一。通常我們會使用synchronized將該操作變成一個原子操作，但JVM為此類操作特意提供了一些同步類，使得使用更方便，且使程序運行效率變得更高。通過相關資料顯示，通常AtomicInteger的性能是ReentantLock的好幾倍。
Java線程鎖總結
1.synchronized：
在資源競爭不是很激烈的情況下，偶爾會有同步的情形下，synchronized是很合適的。原因在于，編譯程序通常會盡可能的進行優化synchronize，另外可讀性非常好。
2.ReentrantLock:
在資源競爭不激烈的情形下，性能稍微比synchronized差點點。但是當同步非常激烈的時候，synchronized的性能一下子能下降好幾十倍，而ReentrantLock確還能維持常態。
高并發量情況下使用ReentrantLock。
3.Atomic:
和上面的類似，不激烈情況下，性能比synchronized略遜，而激烈的時候，也能維持常態。激烈的時候，Atomic的性能會優于ReentrantLock一倍左右。但是其有一個缺點，就是只能同步一個值，一段代碼中只能出現一個Atomic的變量，多于一個同步無效。因為他不能在多個Atomic之間同步。
所以，我們寫同步的時候，優先考慮synchronized，如果有特殊需要，再進一步優化。ReentrantLock和Atomic如果用的不好，不僅不能提高性能，還可能帶來災難。
以上就是Java線程鎖的詳解，除了從編程的角度應對高并發，更多還需要從架構設計的層面來應對高并發場景，例如：Redis緩存、CDN、異步消息等，詳細的內容如下。
轉載于:https://juejin.im/post/5cf5eb2df265da1bca51c77c
總結
以上是生活随笔為你收集整理的Java锁详解：“独享锁/共享锁+公平锁/非公平锁+乐观锁/悲观锁+线程锁”的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 5分钟学会如何创建spring boot
- 下一篇： 好程序员web前端分享函数作用域及递归