[數據庫鎖機制] 深刻理解樂觀鎖、悲觀鎖以及CAS樂觀鎖的實現機制原理分析

時間 2019-11-07

標籤數據庫機制深刻理解樂觀悲觀以及 cas 實現原理分析欄目 SQL 简体版

原文原文鏈接

前言：

在併發訪問狀況下，可能會出現髒讀、不可重複讀和幻讀等讀現象，爲了應對這些問題，主流數據庫都提供了鎖機制，並引入了事務隔離級別的概念。數據庫管理系統（DBMS）中的併發控制的任務是確保在多個事務同時存取數據庫中同一數據時不破壞事務的隔離性和統一性以及數據庫的統一性。
樂觀併發控制(樂觀鎖)和悲觀併發控制（悲觀鎖）是併發控制主要採用的技術手段。不管是悲觀鎖仍是樂觀鎖，都是人們定義出來的概念，能夠認爲是一種思想。其實不只僅是關係型數據庫系統中有樂觀鎖和悲觀鎖的概念，像memcache、hibernate、tair等都有相似的概念。
本文中也將深刻分析一下樂觀鎖的實現機制，介紹什麼是CAS、CAS的應用以及CAS存在的問題等。

併發控制html

在計算機科學，特別是程序設計、操做系統、多處理機和數據庫等領域，併發控制（Concurrency control）是確保及時糾正由併發操做致使的錯誤的一種機制。java

數據庫管理系統（DBMS）中的併發控制的任務是確保在多個事務同時存取數據庫中同一數據時不破壞事務的隔離性和統一性以及數據庫的統一性。下面舉例說明併發操做帶來的數據不一致性問題：mysql

現有兩處火車票售票點，同時讀取某一趟列車車票數據庫中車票餘額爲 X。兩處售票點同時賣出一張車票，同時修改餘額爲 X -1寫回數據庫，這樣就形成了實際賣出兩張火車票而數據庫中的記錄卻只少了一張。產生這種狀況的緣由是由於兩個事務讀入同一數據並同時修改，其中一個事務提交的結果破壞了另外一個事務提交的結果，致使其數據的修改被丟失，破壞了事務的隔離性。併發控制要解決的就是這類問題。算法

封鎖、時間戳、樂觀併發控制(樂觀鎖)和悲觀併發控制（悲觀鎖）是併發控制主要採用的技術手段。sql

1、數據庫的鎖

鎖數據庫

當併發事務同時訪問一個資源時，有可能致使數據不一致，所以須要一種機制來將數據訪問順序化，以保證數據庫數據的一致性。鎖就是其中的一種機制。緩存

在計算機科學中，鎖是在執行多線程時用於強行限制資源訪問的同步機制，即用於在併發控制中保證對互斥要求的知足。安全

鎖的分類(oracle)數據結構

1、按操做劃分，可分爲DML鎖、DDL鎖多線程

2、按鎖的粒度劃分，可分爲表級鎖、行級鎖、頁級鎖（mysql）

3、按鎖級別劃分，可分爲共享鎖、排他鎖

4、按加鎖方式劃分，可分爲自動鎖、顯示鎖

5、按使用方式劃分，可分爲樂觀鎖、悲觀鎖

DML鎖（data locks，數據鎖），用於保護數據的完整性，其中包括行級鎖(Row Locks (TX鎖))、表級鎖(table lock(TM鎖))。

DDL鎖（dictionary locks，數據字典鎖），用於保護數據庫對象的結構，如表、索引等的結構定義。其中包排他DDL鎖（Exclusive DDL lock）、共享DDL鎖（Share DDL lock）、可中斷解析鎖（Breakable parse locks）

1.1 鎖機制

經常使用的鎖機制有兩種：

一、悲觀鎖：假定會發生併發衝突，屏蔽一切可能違反數據完整性的操做。悲觀鎖的實現，每每依靠底層提供的鎖機制；悲觀鎖會致使其它全部須要鎖的線程掛起，等待持有鎖的線程釋放鎖。

二、樂觀鎖：假設不會發生併發衝突，每次不加鎖而是假設沒有衝突而去完成某項操做，只在提交操做時檢查是否違反數據完整性。若是由於衝突失敗就重試，直到成功爲止。樂觀鎖大可能是基於數據版本記錄機制實現。爲數據增長一個版本標識，好比在基於數據庫表的版本解決方案中，通常是經過爲數據庫表增長一個「version」字段來實現。讀取出數據時，將此版本號一同讀出，以後更新時，對此版本號加一。此時，將提交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對，若是提交的數據版本號大於數據庫表當前版本號，則予以更新，不然認爲是過時數據。

樂觀鎖的缺點是不能解決部分髒讀的問題，例如ABA問題（下面會講到）。

在實際生產環境裏邊,若是併發量不大且不容許髒讀，可使用悲觀鎖解決併發問題；但若是系統的併發很是大的話,悲觀鎖定會帶來很是大的性能問題,因此咱們就要選擇樂觀鎖定的方法。

2、悲觀鎖與樂觀鎖詳解

2.1 悲觀鎖

在關係數據庫管理系統裏，悲觀併發控制（又名「悲觀鎖」，Pessimistic Concurrency Control，縮寫「PCC」）是一種併發控制的方法。它能夠阻止一個事務以影響其餘用戶的方式來修改數據。若是一個事務執行的操做都某行數據應用了鎖，那只有當這個事務把鎖釋放，其餘事務纔可以執行與該鎖衝突的操做。
悲觀併發控制主要用於數據爭用激烈的環境，以及發生併發衝突時使用鎖保護數據的成本要低於回滾事務的成本的環境中。

悲觀鎖，正如其名，它指的是對數據被外界（包括本系統當前的其餘事務，以及來自外部系統的事務處理）修改持保守態度(悲觀)，所以，在整個數據處理過程當中，將數據處於鎖定狀態。悲觀鎖的實現，每每依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，不然，即便在本系統中實現了加鎖機制，也沒法保證外部系統不會修改數據）

在數據庫中，悲觀鎖的流程以下：

在對任意記錄進行修改前，先嚐試爲該記錄加上排他鎖（exclusive locking）。

若是加鎖失敗，說明該記錄正在被修改，那麼當前查詢可能要等待或者拋出異常。具體響應方式由開發者根據實際須要決定。

若是成功加鎖，那麼就能夠對記錄作修改，事務完成後就會解鎖了。

其間若是有其餘對該記錄作修改或加排他鎖的操做，都會等待咱們解鎖或直接拋出異常。

MySQL InnoDB中使用悲觀鎖：

要使用悲觀鎖，咱們必須關閉mysql數據庫的自動提交屬性，由於MySQL默認使用autocommit模式，也就是說，當你執行一個更新操做後，MySQL會馬上將結果進行提交。set autocommit=0;

//0.開始事務
begin;/begin work;/start transaction; (三者選一就能夠)
//1.查詢出商品信息
select status from t_goods where id=1 for update;
//2.根據商品信息生成訂單
insert into t_orders (id,goods_id) values (null,1);
//3.修改商品status爲2
update t_goods set status=2;
//4.提交事務
commit;/commit work;

上面的查詢語句中，咱們使用了select…for update的方式，這樣就經過開啓排他鎖的方式實現了悲觀鎖。此時在t_goods表中，id爲1的那條數據就被咱們鎖定了，其它的事務必須等本次事務提交以後才能執行。這樣咱們能夠保證當前的數據不會被其它事務修改。

上面咱們提到，使用select…for update會把數據給鎖住，不過咱們須要注意一些鎖的級別，MySQL InnoDB默認行級鎖。行級鎖都是基於索引的，若是一條SQL語句用不到索引是不會使用行級鎖的，會使用表級鎖把整張表鎖住，這點須要注意。

優勢與不足

悲觀併發控制其實是「先取鎖再訪問」的保守策略，爲數據處理的安全提供了保證。可是在效率方面，處理加鎖的機制會讓數據庫產生額外的開銷，還有增長產生死鎖的機會；另外，在只讀型事務處理中因爲不會產生衝突，也不必使用鎖，這樣作只能增長系統負載；還有會下降了並行性，一個事務若是鎖定了某行數據，其餘事務就必須等待該事務處理完才能夠處理那行數

2.2 樂觀鎖

在關係數據庫管理系統裏，樂觀併發控制（又名「樂觀鎖」，Optimistic Concurrency Control，縮寫「OCC」）是一種併發控制的方法。它假設多用戶併發的事務在處理時不會彼此互相影響，各事務可以在不產生鎖的狀況下處理各自影響的那部分數據。在提交數據更新以前，每一個事務會先檢查在該事務讀取數據後，有沒有其餘事務又修改了該數據。若是其餘事務有更新的話，正在提交的事務會進行回滾。樂觀事務控制最先是由孔祥重（H.T.Kung）教授提出。

樂觀鎖（ Optimistic Locking ）相對悲觀鎖而言，樂觀鎖假設認爲數據通常狀況下不會形成衝突，因此在數據進行提交更新的時候，纔會正式對數據的衝突與否進行檢測，若是發現衝突了，則讓返回用戶錯誤的信息，讓用戶決定如何去作。

相對於悲觀鎖，在對數據庫進行處理的時候，樂觀鎖並不會使用數據庫提供的鎖機制。通常的實現樂觀鎖的方式就是記錄數據版本。

數據版本,爲數據增長的一個版本標識。當讀取數據時，將版本標識的值一同讀出，數據每更新一次，同時對版本標識進行更新。當咱們提交更新的時候，判斷數據庫表對應記錄的當前版本信息與第一次取出來的版本標識進行比對，若是數據庫表當前版本號與第一次取出來的版本標識值相等，則予以更新，不然認爲是過時數據。

實現數據版本有兩種方式，第一種是使用版本號，第二種是使用時間戳。

使用版本號實現樂觀鎖

使用版本號時，能夠在數據初始化時指定一個版本號，每次對數據的更新操做都對版本號執行+1操做。並判斷當前版本號是否是該數據的最新的版本號。

1.查詢出商品信息
select (status,status,version) from t_goods where id=#{id}
2.根據商品信息生成訂單
3.修改商品status爲2
update t_goods 
set status=2,version=version+1
where id=#{id} and version=#{version};

優勢與不足

樂觀併發控制相信事務之間的數據競爭(data race)的機率是比較小的，所以儘量直接作下去，直到提交的時候纔去鎖定，因此不會產生任何鎖和死鎖。但若是直接簡單這麼作，仍是有可能會遇到不可預期的結果，例如兩個事務都讀取了數據庫的某一行，通過修改之後寫回數據庫，這時就遇到了問題。

3、CAS詳解

在說CAS以前，咱們不得不提一下Java的線程安全問題。

線程安全：

衆所周知，Java是多線程的。可是，Java對多線程的支持實際上是一把雙刃劍。一旦涉及到多個線程操做共享資源的狀況時，處理很差就可能產生線程安全問題。線程安全性多是很是複雜的，在沒有充足的同步的狀況下，多個線程中的操做執行順序是不可預測的。

Java裏面進行多線程通訊的主要方式就是共享內存的方式，共享內存主要的關注點有兩個：可見性和有序性。加上覆合操做的原子性，咱們能夠認爲Java的線程安全性問題主要關注點有3個：可見性、有序性和原子性。

Java內存模型（JMM）解決了可見性和有序性的問題，而鎖解決了原子性的問題。這裏再也不詳細介紹JMM及鎖的其餘相關知識。可是咱們要討論一個問題，那就是鎖究竟是不是有利無弊的？

3.1 鎖存在的問題

Java在JDK1.5以前都是靠synchronized關鍵字保證同步的，這種經過使用一致的鎖定協議來協調對共享狀態的訪問，能夠確保不管哪一個線程持有共享變量的鎖，都採用獨佔的方式來訪問這些變量。獨佔鎖其實就是一種悲觀鎖，因此能夠說synchronized是悲觀鎖。

悲觀鎖機制存在如下問題：

1) 在多線程競爭下，加鎖、釋放鎖會致使比較多的上下文切換和調度延時，引發性能問題。

2) 一個線程持有鎖會致使其它全部須要此鎖的線程掛起。

3) 若是一個優先級高的線程等待一個優先級低的線程釋放鎖會致使優先級倒置，引發性能風險。

而另外一個更加有效的鎖就是樂觀鎖。所謂樂觀鎖就是，每次不加鎖而是假設沒有衝突而去完成某項操做，若是由於衝突失敗就重試，直到成功爲止。

與鎖相比，volatile變量是一個更輕量級的同步機制，由於在使用這些變量時不會發生上下文切換和線程調度等操做，可是volatile不能解決原子性問題，所以當一個變量依賴舊值時就不能使用volatile變量。所以對於同步最終仍是要回到鎖機制上來。

樂觀鎖

樂觀鎖（ Optimistic Locking）實際上是一種思想。相對悲觀鎖而言，樂觀鎖假設認爲數據通常狀況下不會形成衝突，因此在數據進行提交更新的時候，纔會正式對數據的衝突與否進行檢測，若是發現衝突了，則讓返回用戶錯誤的信息，讓用戶決定如何去作。

上面提到的樂觀鎖的概念中其實已經闡述了他的具體實現細節：

主要就是兩個步驟：衝突檢測和數據更新。

其實現方式有一種比較典型的就是Compare and Swap(CAS)。

3.2 CAS

CAS是項樂觀鎖技術，當多個線程嘗試使用CAS同時更新同一個變量時，只有其中一個線程能更新變量的值，而其它線程都失敗，失敗的線程並不會被掛起，而是被告知此次競爭中失敗，並能夠再次嘗試。

CAS 操做包含三個操做數 —— 內存位置（V）、預期原值（A）和新值(B)。若是內存位置的值與預期原值相匹配，那麼處理器會自動將該位置值更新爲新值。不然，處理器不作任何操做。不管哪一種狀況，它都會在 CAS 指令以前返回該位置的值。（在 CAS 的一些特殊狀況下將僅返回 CAS 是否成功，而不提取當前值。）CAS 有效地說明了「我認爲位置 V 應該包含值 A；若是包含該值，則將 B 放到這個位置；不然，不要更改該位置，只告訴我這個位置如今的值便可。」這其實和樂觀鎖的衝突檢查+數據更新的原理是同樣的。

這裏再強調一下，樂觀鎖是一種思想。CAS是這種思想的一種實現方式。

3.3 Java對CAS的支持

JDK 5以前Java語言是靠synchronized關鍵字保證同步的，這是一種獨佔鎖，也是是悲觀鎖。j在JDK1.5 中新增java.util.concurrent(J.U.C)就是創建在CAS之上的。相對於對於synchronized這種阻塞算法，CAS是非阻塞算法的一種常見實現。因此J.U.C在性能上有了很大的提高。

現代的CPU提供了特殊的指令，容許算法執行讀-修改-寫操做，而無需懼怕其餘線程同時修改變量，由於若是其餘線程修改變量，那麼CAS會檢測它（並失敗），算法能夠對該操做從新計算。而 compareAndSet() 就用這些代替了鎖定。

咱們以java.util.concurrent中的AtomicInteger爲例，看一下在沒有鎖的狀況下是如何保證線程安全的。主要理解getAndIncrement方法，該方法的做用至關於 ++i 操做。

public class AtomicInteger extends Number implements java.io.Serializable {
    
    private volatile int value;
    
    public final int get() {
        return value;
    }
    
    public final int getAndIncrement() {
        for (;;) {
            int current = get();
            int next = current + 1;
            if (compareAndSet(current, next))
                return current;
        }
    }
    
    public final boolean compareAndSet(int expect, int update) {
        return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
    }

字段value須要藉助volatile原語，保證線程間的數據是可見的（共享的）。這樣在獲取變量的值的時候才能直接讀取。而後來看看++i是怎麼作到的。getAndIncrement採用了CAS操做，每次從內存中讀取數據而後將此數據和+1後的結果進行CAS操做，若是成功就返回結果，不然重試直到成功爲止。而compareAndSet利用JNI來完成CPU指令的操做。

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

總體的過程就是這樣子的，利用CPU的CAS指令，同時藉助JNI來完成Java的非阻塞算法。其它原子操做都是利用相似的特性完成的。

而整個J.U.C都是創建在CAS之上的，所以對於synchronized阻塞算法，J.U.C在性能上有了很大的提高。

3.4 CAS會致使「ABA問題」：

ABA問題：

aba其實是樂觀鎖沒法解決髒數據讀取的一種體現。CAS算法實現一個重要前提須要取出內存中某時刻的數據，而在下時刻比較並替換，那麼在這個時間差類會致使數據的變化。

好比說一個線程one從內存位置V中取出A，這時候另外一個線程two也從內存中取出A，而且two進行了一些操做變成了B，而後two又將V位置的數據變成A，這時候線程one進行CAS操做發現內存中仍然是A，而後one操做成功。儘管線程one的CAS操做成功，可是不表明這個過程就是沒有問題的。

部分樂觀鎖的實現是經過版本號（version）的方式來解決ABA問題，樂觀鎖每次在執行數據的修改操做時，都會帶上一個版本號，一旦版本號和數據的版本號一致就能夠執行修改操做並對版本號執行+1操做，不然就執行失敗。由於每次操做的版本號都會隨之增長，因此不會出現ABA問題，由於版本號只會增長不會減小。

若是鏈表的頭在變化了兩次後恢復了原值，可是不表明鏈表就沒有變化。所以AtomicStampedReference/AtomicMarkableReference就頗有用了。

AtomicMarkableReference 類描述的一個<Object,Boolean>的對，能夠原子的修改Object或者Boolean的值，這種數據結構在一些緩存或者狀態描述中比較有用。這種結構在單個或者同時修改Object/Boolean的時候可以有效的提升吞吐量。

AtomicStampedReference 類維護帶有整數「標誌」的對象引用，能夠用原子方式對其進行更新。對比AtomicMarkableReference 類的<Object,Boolean>，AtomicStampedReference 維護的是一種相似<Object,int>的數據結構，其實就是對對象（引用）的一個併發計數（標記版本戳stamp）。可是與AtomicInteger 不一樣的是，此數據結構能夠攜帶一個對象引用（Object），而且可以對此對象和計數同時進行原子操做。