一、樂觀鎖與悲觀鎖
悲觀鎖
總是假設最壞的情況，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會阻塞直到它拿到鎖（共享資源每次只給一個線程使用，其它線程阻塞，用完后再把資源轉讓給其它線程）。傳統的關系型數據庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。Java中synchronized和ReentrantLock等獨占鎖就是悲觀鎖思想的實現。
樂觀鎖
總是假設最好的情況，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號機制和CAS算法實現。樂觀鎖適用於多讀的應用類型，這樣可以提高吞吐量，像數據庫提供的類似於write_condition機制，其實都是提供的樂觀鎖。在Java中java.util.concurrent.atomic包下面的原子變量類就是使用了樂觀鎖的一種實現方式CAS實現的。
兩種鎖的使用場景
從上面對兩種鎖的介紹，我們知道兩種鎖各有優缺點，不可認為一種好於另一種，像樂觀鎖適用於寫比較少的情況下（多讀場景），即沖突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果是多寫的情況，一般會經常產生沖突，這就會導致上層應用會不斷的進行retry，這樣反倒是降低了性能，所以一般多寫的場景下用悲觀鎖就比較合適。
樂觀鎖一般會使用版本號機制或CAS算法實現。
1. 版本號機制
一般是在數據表中加上一個數據版本號version字段，表示數據被修改的次數，當數據被修改時，version值會加一。當線程A要更新數據值時，在讀取數據的同時也會讀取version值，在提交更新時，若剛才讀取到的version值為當前數據庫中的version值相等時才更新，否則重試更新操作，直到更新成功。
舉一個簡單的例子：
假設數據庫中帳戶信息表中有一個 version 字段，當前值為 1 ；而當前帳戶余額字段（ balance ）為 $100 。
操作員 A 此時將其讀出（ version=1 ），並從其帳戶余額中扣除 50（50（100-$50 ）。
在操作員 A 操作的過程中，操作員B 也讀入此用戶信息（ version=1 ），並從其帳戶余額中扣除 20（20（100-$20 ）。
操作員 A 完成了修改工作，將數據版本號加一（ version=2 ），連同帳戶扣除后余額（ balance=$50 ），提交至數據庫更新，此時由於提交數據版本大於數據庫記錄當前版本，數據被更新，數據庫記錄 version 更新為 2 。
操作員 B 完成了操作，也將版本號加一（ version=2 ）試圖向數據庫提交數據（ balance=$80 ），但此時比對數據庫記錄版本時發現，操作員 B 提交的數據版本號為 2 ，數據庫記錄當前版本也為 2 ，不滿足 “ 提交版本必須大於記錄當前版本才能執行更新 “ 的樂觀鎖策略，因此，操作員 B 的提交被駁回。
這樣，就避免了操作員 B 用基於 version=1 的舊數據修改的結果覆蓋操作員A 的操作結果的可能。
2. CAS算法
即compare and swap（比較與交換），是一種有名的無鎖算法。無鎖編程，即不使用鎖的情況下實現多線程之間的變量同步，也就是在沒有線程被阻塞的情況下實現變量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三個操作數
需要讀寫的內存值 V
進行比較的值 A
擬寫入的新值 B
當且僅當 V 的值等於 A時，CAS通過原子方式用新值B來更新V的值，否則不會執行任何操作（比較和替換是一個原子操作）。一般情況下是一個自旋操作，即不斷的重試。
舉例：
多線程情況下如何實現count++?
使用悲觀鎖可以使用synchronized對變量進行加鎖；
CAS的操作流程如下：
1.讀取內存數據j=count;
2.CAS(j,j++);即比較內存中count數據是否還為j,如果是才進行修改；整個操作具有原子性
3.如果成功，返回；失敗則重新執行第一步直到成功，也稱之為自旋。
由於第二步成功的概率很大，所以采用CAS的代價很小；當高並發情況下由於CAS采用自旋的方式對CPU會有較大的操作負擔，所以可能會損耗部分CPU資源。
樂觀鎖的缺點
1 ABA 問題
如果一個變量V初次讀取的時候是A值，並且在准備賦值的時候檢查到它仍然是A值，那我們就能說明它的值沒有被其他線程修改過了嗎？很明顯是不能的，因為在這段時間它的值可能被改為其他值，然后又改回A，那CAS操作就會誤認為它從來沒有被修改過。這個問題被稱為CAS操作的 “ABA”問題。
JDK 1.5 以后的 AtomicStampedReference 類就提供了此種能力，其中的 compareAndSet 方法就是首先檢查當前引用是否等於預期引用，並且當前標志是否等於預期標志，如果全部相等，則以原子方式將該引用和該標志的值設置為給定的更新值。
2 循環時間長開銷大
自旋CAS（也就是不成功就一直循環執行直到成功）如果長時間不成功，會給CPU帶來非常大的執行開銷。 如果JVM能支持處理器提供的pause指令那么效率會有一定的提升，pause指令有兩個作用，第一它可以延遲流水線執行指令（de-pipeline）,使CPU不會消耗過多的執行資源，延遲的時間取決於具體實現的版本，在一些處理器上延遲時間是零。第二它可以避免在退出循環的時候因內存順序沖突（memory order violation）而引起CPU流水線被清空（CPU pipeline flush），從而提高CPU的執行效率。
3 只能保證一個共享變量的原子操作
CAS 只對單個共享變量有效，當操作涉及跨多個共享變量時 CAS 無效。但是從 JDK 1.5開始，提供了AtomicReference類來保證引用對象之間的原子性，你可以把多個變量放在一個對象里來進行 CAS 操作.所以我們可以使用鎖或者利用AtomicReference類把多個共享變量合並成一個共享變量來操作。
參考https://blog.csdn.net/qq_34337272/article/details/81072874
https://blog.csdn.net/u010904188/article/details/87712060
二、鎖機制
有些業務邏輯在執行過程中要求對數據進行排他性的訪問，於是需要通過一些機制保證在此過程中數據被鎖住不會被外界修改，這就是所謂的鎖機制。
CAS是Compare And Set的縮寫，是以一種無鎖的方式實現並發控制。在實際情況下，同時操作同一個對象的概率非常小，所以多數加鎖操作做的是無用功，CAS以一種樂觀鎖的方式實現並發控制。CAS的具體實現就是給定內存中的期望值和修改后的目標值，如果實際內存中的值等於期望值，則內存值替換為目標值，否則操作失敗。該操作具有原子性。
悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關系型數據庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。
樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數
重入鎖（ReentrantLock）是一種遞歸無阻塞的同步機制。重入鎖，也叫做遞歸鎖，指的是同一線程 外層函數獲得鎖之后 ，內層遞歸函數仍然有獲取該鎖的代碼，但不受影響。在JAVA環境下 ReentrantLock 和synchronized 都是 可重入鎖。
自旋鎖，由於自旋鎖使用者一般保持鎖時間非常短，因此選擇自旋而不是睡眠是非常必要的，自旋鎖的效率遠高於互斥鎖。如何旋轉呢？何為自旋鎖，就是如果發現鎖定了，不是睡眠等待，而是采用讓當前線程不停地的在循環體內執行實現的，當循環的條件被其他線程改變時 才能進入臨界區。
偏向鎖(Biased Locking)是Java6引入的一項多線程優化，它會偏向於第一個訪問鎖的線程，如果在運行過程中，同步鎖只有一個線程訪問，不存在多線程爭用的情況，則線程是不需要觸發同步的，這種情況下，就會給線程加一個偏向鎖。 如果在運行過程中，遇到了其他線程搶占鎖，則持有偏向鎖的線程會被掛起，JVM會消除它身上的偏向鎖，將鎖恢復到標准的輕量級鎖。
輕量級鎖是由偏向所升級來的，偏向鎖運行在一個線程進入同步塊的情況下，當第二個線程加入鎖爭用的時候，偏向鎖就會升級為輕量級鎖。
公平鎖，就是很公平，在並發環境中，每個線程在獲取鎖時會先查看此鎖維護的等待隊列，如果為空，或者當前線程線程是等待隊列的第一個，就占有鎖，否則就會加入到等待隊列中，以后會按照FIFO的規則從隊列中取到自己
非公平鎖比較粗魯，上來就直接嘗試占有鎖，如果嘗試失敗，就再采用類似公平鎖那種方式。
據，可以使用版本號等機制。樂觀鎖適用於多讀的應用類型，這樣可以提高吞吐量，像數據庫如果提供類似於write_condition機制的其實都是提供的樂觀鎖。
方法鎖（synchronized修飾方法時）通過在方法聲明中加入 synchronized關鍵字來聲明 synchronized 方法。synchronized 方法控制對類成員變量的訪問： 每個類實例對應一把鎖，每個 synchronized 方法都必須獲得調用該方法的類實例的鎖方能執行，否則所屬線程阻塞，方法一旦執行，就獨占該鎖，直到從該方法返回時才將鎖釋放，此后被阻塞的線程方能獲得該鎖，重新進入可執行狀態。這種機制確保了同一時刻對於每一個類實例，其所有聲明為 synchronized 的成員函數中至多只有一個處於可執行狀態，從而有效避免了類成員變量的訪問沖突。
對象鎖（synchronized修飾方法或代碼塊）當一個對象中有synchronized method或synchronized block的時候調用此對象的同步方法或進入其同步區域時，就必須先獲得對象鎖。如果此對象的對象鎖已被其他調用者占用，則需要等待此鎖被釋放。（方法鎖也是對象鎖）。java的所有對象都含有1個互斥鎖，這個鎖由JVM自動獲取和釋放。線程進入synchronized方法的時候獲取該對象的鎖，當然如果已經有線程獲取了這個對象的鎖，那么當前線程會等待；synchronized方法正常返回或者拋異常而終止，JVM會自動釋放對象鎖。這里也體現了用synchronized來加鎖的1個好處，方法拋異常的時候，鎖仍然可以由JVM來自動釋放。
類鎖(synchronized修飾靜態的方法或代碼塊)，由於一個class不論被實例化多少次，其中的靜態方法和靜態變量在內存中都只有一份。所以，一旦一個靜態的方法被申明為synchronized。此類所有的實例化對象在調用此方法，共用同一把鎖，我們稱之為類鎖。對象鎖是用來控制實例方法之間的同步，類鎖是用來控制靜態方法（或靜態變量互斥體）之間的同步。類鎖只是一個概念上的東西，並不是真實存在的，它只是用來幫助我們理解鎖定實例方法和靜態方法的區別的。java類可能會有很多個對象，但是只有1個Class對象，也就是說類的不同實例之間共享該類的Class對象。Class對象其實也僅僅是1個java對象，只不過有點特殊而已。由於每個java對象都有1個互斥鎖，而類的靜態方法是需要Class對象。所以所謂的類鎖，不過是Class對象的鎖而已。獲取類的Class對象有好幾種，最簡單的就是［類名.class］的方式。
死鎖：是指兩個或兩個以上的進程（或線程）在執行過程中，因爭奪資源而造成的一種互相等待的現象，若無外力作用，它們都將無法推進下去。此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的進程稱為死鎖進程。
死鎖發生的四個條件
- 互斥條件：線程對資源的訪問是排他性的，如果一個線程對占用了某資源，那么其他線程必須處於等待狀態，直到資源被釋放。
- 請求和保持條件：線程T1至少已經保持了一個資源R1占用,但又提出對另一個資源R2請求，而此時，資源R2被其他線程T2占用，於是該線程T1也必須等待，但又對自己保持的資源R1不釋放。
- 不剝奪條件：線程已獲得的資源，在未使用完之前，不能被其他線程剝奪，只能在使用完以后由自己釋放。
- 環路等待條件：在死鎖發生時，必然存在一個“進程-資源環形鏈”，即：{p0,p1,p2,...pn},進程p0（或線程）等待p1占用的資源，p1等待p2占用的資源，pn等待p0占用的資源。（最直觀的理解是，p0等待p1占用的資源，而p1而在等待p0占用的資源，於是兩個進程就相互等待）
預防死鎖，預先破壞產生死鎖的四個條件。互斥不可能破壞，所以有如下3種方法：
- 破壞，請求和保持條件。進程等所有要請求的資源都空閑時才能申請資源，這種方法會使資源嚴重浪費（有些資源可能僅在運行初期或結束時才使用，甚至根本不使用）。允許進程獲取初期所需資源后，便開始運行，運行過程中再逐步釋放自己占有的資源。比如有一個進程的任務是把數據復制到磁盤中再打印，前期只需要獲得磁盤資源而不需要獲得打印機資源，待復制完畢后再釋放掉磁盤資源。這種方法比上一種好，會使資源利用率上升。
- 破壞，不可搶占條件。這種方法代價大，實現復雜
- 破壞，循壞等待條件。對各進程請求資源的順序做一個規定，避免相互等待。這種方法對資源的利用率比前兩種都高，但是前期要為設備指定序號，新設備加入會有一個問題，其次對用戶編程也有限制
活鎖：是指線程1可以使用資源，但它很禮貌，讓其他線程先使用資源，線程2也可以使用資源，但它很紳士，也讓其他線程先使用資源。這樣你讓我，我讓你，最后兩個線程都無法使用資源。
死鎖與飢餓的區別
相同點：二者都是由於競爭資源而引起的。
不同點：
- 從進程狀態考慮，死鎖進程都處於等待狀態，忙等待(處於運行或就緒狀態)的進程並非處於等待狀態，但卻可能被餓死；
- 死鎖進程等待永遠不會被釋放的資源，餓死進程等待會被釋放但卻不會分配給自己的資源，表現為等待時限沒有上界(排隊等待或忙式等待)；
- 死鎖一定發生了循環等待，而餓死則不然。這也表明通過資源分配圖可以檢測死鎖存在與否，但卻不能檢測是否有進程餓死；
- 死鎖一定涉及多個進程，而飢餓或被餓死的進程可能只有一個。
- 在飢餓的情形下，系統中有至少一個進程能正常運行，只是飢餓進程得不到執行機會。而死鎖則可能會最終使整個系統陷入死鎖並崩潰
怎么檢測一個線程是否擁有鎖
java.lang.Thread中有一個方法叫holdsLock()，它返回true如果當且僅當當前線程擁有某個具體對象的鎖
三、什么時候應該使用可重入鎖？
場景1：如果已加鎖，則不再重復加鎖。a、忽略重復加鎖。b、用在界面交互時點擊執行較長時間請求操作時，防止多次點擊導致后台重復執行（忽略重復觸發）。以上兩種情況多用於進行非重要任務防止重復執行，（如：清除無用臨時文件，檢查某些資源的可用性，數據備份操作等）
場景2：如果發現該操作已經在執行，則嘗試等待一段時間，等待超時則不執行（嘗試等待執行）這種其實屬於場景2的改進，等待獲得鎖的操作有一個時間的限制，如果超時則放棄執行。用來防止由於資源處理不當長時間占用導致死鎖情況（大家都在等待資源，導致線程隊列溢出）。
場景3：如果發現該操作已經加鎖，則等待一個一個加鎖（同步執行，類似synchronized）這種比較常見大家也都在用，主要是防止資源使用沖突，保證同一時間內只有一個操作可以使用該資源。但與synchronized的明顯區別是性能優勢（伴隨jvm的優化這個差距在減小）。同時Lock有更靈活的鎖定方式，公平鎖與不公平鎖，而synchronized永遠是公平的。這種情況主要用於對資源的爭搶（如：文件操作，同步消息發送，有狀態的操作等）
場景4：可中斷鎖。synchronized與Lock在默認情況下是不會響應中斷(interrupt)操作，會繼續執行完。lockInterruptibly()提供了可中斷鎖來解決此問題。（場景3的另一種改進，沒有超時，只能等待中斷或執行完畢）這種情況主要用於取消某些操作對資源的占用。如：（取消正在同步運行的操作，來防止不正常操作長時間占用造成的阻塞）
四、如何實現分布式鎖
基於數據庫實現分布式鎖
基於緩存（redis，memcached，tair）實現分布式鎖
基於Zookeeper實現分布式鎖
參考https://www.cnblogs.com/rwxwsblog/p/6046034.html
http://www.hollischuang.com/archives/1716