一、什么是樂觀鎖？什么是悲觀鎖

個人理解一句話概括就是，在應(yīng)用層面會造成線程阻塞的是悲觀鎖，而不會造成線程阻塞的是樂觀鎖，為什么這么說會在后續(xù)的內(nèi)容中做詳細(xì)介紹。

1.1、悲觀鎖

• 悲觀鎖是一種基于悲觀態(tài)度的數(shù)據(jù)并發(fā)控制機(jī)制，用于防止數(shù)據(jù)沖突。它采取預(yù)防性的措施，在修改數(shù)據(jù)之前將其鎖定，并在操作完成后釋放鎖定，以確保數(shù)據(jù)的一致性和完整性。悲觀鎖通常用于并發(fā)環(huán)境下的數(shù)據(jù)庫系統(tǒng)，是數(shù)據(jù)庫本身實現(xiàn)鎖機(jī)制的一種方式。

• 在悲觀鎖的機(jī)制下，當(dāng)一個使用者要修改某個數(shù)據(jù)時，首先會嘗試獲取該數(shù)據(jù)的鎖。如果鎖已經(jīng)被其他使用者持有，則當(dāng)前使用者會被阻塞，直到對應(yīng)的鎖被釋放。這種悲觀的態(tài)度認(rèn)為數(shù)據(jù)沖突是不可避免的，因此在修改數(shù)據(jù)之前先鎖定數(shù)據(jù)，以防止沖突的發(fā)生。

• 在Java中，常見的悲觀鎖實現(xiàn)是使用synchronized關(guān)鍵字或ReentrantLock類。這些鎖能夠確保同一時刻只有一個線程可以訪問被鎖定的代碼塊或資源，其他線程必須等待鎖釋放后才能繼續(xù)執(zhí)行。

1.2、樂觀鎖

• 樂觀鎖是一種基于版本控制的并發(fā)控制機(jī)制。在樂觀鎖的思想中，認(rèn)為數(shù)據(jù)訪問沖突的概率很低，因此不加鎖直接進(jìn)行操作，但在更新數(shù)據(jù)時會進(jìn)行版本比對，以確保數(shù)據(jù)的一致性。

• 樂觀鎖的原理主要基于版本號或時間戳來實現(xiàn)。在每次更新數(shù)據(jù)時，先獲取當(dāng)前數(shù)據(jù)的版本號或時間戳，然后在更新時比對版本號或時間戳是否一致，若一致則更新成功，否則表示數(shù)據(jù)已被其他線程修改，更新失敗。

• 在Java中，常見的樂觀鎖實現(xiàn)是使用Atomic類，例如AtomicInteger、AtomicLong等。這些類提供了原子操作，可以確保對共享資源的更新操作是原子性的，從而避免了鎖的開銷和線程等待，另外，CAS（Compare-And-Swap）是實現(xiàn)樂觀鎖的核心算法，它通過比較內(nèi)存中的值是否和預(yù)期的值相等來判斷是否存在沖突。如果存在，則返回失敗；如果不存在，則執(zhí)行更新操作。Java中提供了AtomicInteger、AtomicLong、AtomicReference等原子類來支持CAS操作。

二、樂觀鎖與悲觀鎖分別適用于什么場景

2.1、悲觀鎖適用場景

• 高并發(fā)且數(shù)據(jù)競爭激烈的場景：當(dāng)多個事務(wù)需要同時訪問和修改同一份數(shù)據(jù)時，使用悲觀鎖可以確保數(shù)據(jù)在任一時刻只被一個事務(wù)訪問和修改，從而避免數(shù)據(jù)的不一致性和臟讀。
• 數(shù)據(jù)一致性要求極高的場景：在金融、醫(yī)療等行業(yè)中，對數(shù)據(jù)的一致性要求非常高，不允許出現(xiàn)任何的數(shù)據(jù)不一致或臟讀現(xiàn)象。在這些場景中，使用悲觀鎖可以確保數(shù)據(jù)在任一時刻只被一個事務(wù)訪問和修改，從而滿足數(shù)據(jù)一致性的要求。
• 寫操作頻繁的場景：如果系統(tǒng)中寫操作（如更新、刪除等）遠(yuǎn)多于讀操作（如查詢），那么使用悲觀鎖可以更有效地保護(hù)數(shù)據(jù)，避免在寫操作時被其他事務(wù)干擾。
• 事務(wù)執(zhí)行時間較長的場景：當(dāng)事務(wù)的執(zhí)行時間較長時，使用悲觀鎖可以確保在該事務(wù)執(zhí)行期間，數(shù)據(jù)不會被其他事務(wù)修改，從而避免數(shù)據(jù)的不一致性和臟讀。

2.2、樂觀鎖適用場景

• 寫操作較少：在這種場景下，多個事務(wù)或線程大部分時間都在讀取數(shù)據(jù)，而寫操作的頻率相對較低。樂觀鎖能夠減少鎖的持有時間，允許多個事務(wù)或線程同時讀取數(shù)據(jù)，而不會相互阻塞。
• 數(shù)據(jù)沖突較少：如果數(shù)據(jù)更新操作之間的沖突較少，即多個事務(wù)或線程同時更新同一份數(shù)據(jù)的概率較低，那么樂觀鎖能夠發(fā)揮很好的性能。因為即使偶爾出現(xiàn)沖突，也只是在更新數(shù)據(jù)時才會被檢測到，而不需要在整個數(shù)據(jù)處理過程中都鎖定資源。
• 重試成本較低：樂觀鎖在檢測到?jīng)_突時會回滾事務(wù)或提示沖突，需要客戶端重新嘗試更新操作。因此，如果重試的成本較低（例如，重試不會導(dǎo)致大量計算或I/O操作），那么使用樂觀鎖是合適的。
• 系統(tǒng)能夠容忍一定程度的失敗：由于樂觀鎖在更新數(shù)據(jù)時可能會因為版本沖突而失敗，因此系統(tǒng)需要能夠處理這種失敗情況。如果系統(tǒng)能夠容忍一定程度的失?。ɡ?，通過重試或其他補(bǔ)償機(jī)制來恢復(fù)），那么使用樂觀鎖是可行的。

三、樂觀鎖與悲觀鎖各自優(yōu)缺點(diǎn)

3.1、悲觀鎖

優(yōu)點(diǎn)：

• 數(shù)據(jù)一致性高：悲觀鎖認(rèn)為沖突一定會發(fā)生，因此在數(shù)據(jù)處理前會先加鎖，這樣可以確保數(shù)據(jù)在任一時刻只被一個事務(wù)訪問和修改，從而避免數(shù)據(jù)的不一致性和臟讀。
• 簡單易用：悲觀鎖的實現(xiàn)相對簡單，只需要在操作數(shù)據(jù)前獲取鎖即可。

缺點(diǎn)：

• 性能開銷大：悲觀鎖在操作數(shù)據(jù)前需要獲取鎖，如果有大量的并發(fā)操作，可能會導(dǎo)致性能問題，因為其他事務(wù)需要等待鎖釋放。
• 容易造成死鎖：如果多個事務(wù)相互等待對方釋放鎖，可能會導(dǎo)致死鎖的發(fā)生，影響系統(tǒng)的穩(wěn)定性和可用性。
• 可能導(dǎo)致資源浪費(fèi)：如果獲取鎖后長時間不釋放，可能會導(dǎo)致其他事務(wù)無法操作數(shù)據(jù)，從而造成資源浪費(fèi)。

3.2、樂觀鎖

優(yōu)點(diǎn)：

• 高并發(fā)高吞吐：樂觀鎖不會阻塞其他事務(wù)的讀取操作，只在提交時檢查數(shù)據(jù)是否被修改，因此可以提供更好的并發(fā)性能。
• 無鎖操作：樂觀鎖不需要顯式地獲取和釋放鎖，減少了鎖競爭和上下文切換的開銷。
• 無死鎖風(fēng)險：由于樂觀鎖不會阻塞其他事務(wù)的訪問，因此不會出現(xiàn)死鎖的情況。

缺點(diǎn)：

• 沖突處理復(fù)雜：由于樂觀鎖不會阻塞其他事務(wù)，因此在提交時需要檢查數(shù)據(jù)是否被其他事務(wù)修改，如果發(fā)現(xiàn)沖突，需要回滾事務(wù)或重新嘗試操作，這增加了沖突處理的復(fù)雜性。
• 數(shù)據(jù)一致性風(fēng)險：樂觀鎖假設(shè)并發(fā)沖突較少，因此可能存在數(shù)據(jù)一致性的風(fēng)險。如果多個事務(wù)同時對同一數(shù)據(jù)進(jìn)行修改，可能會導(dǎo)致數(shù)據(jù)不一致的情況。
• 需要額外字段：為了實現(xiàn)樂觀鎖，通常需要在數(shù)據(jù)表中添加額外的版本號或時間戳字段，這增加了存儲空間的需求。
• 處理不當(dāng)造成死循環(huán)風(fēng)險：在大多數(shù)業(yè)務(wù)中樂觀鎖更新失敗都會進(jìn)行自旋，如果沒有控制好自旋退出邏輯可能會造成遞歸死循環(huán)問題。

四、樂觀鎖與悲觀鎖使用示例

這里舉例會以操作數(shù)據(jù)庫實現(xiàn)樂觀鎖與悲觀鎖示例，在實際開發(fā)中一般在操作數(shù)據(jù)庫時經(jīng)常會使用到樂觀鎖與悲觀鎖的實現(xiàn)思路來確保數(shù)據(jù)一致性問題，這里會以一個更新用戶錢包舉例。

用戶錢包表

CREATE TABLE `customer_wallet` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `customer_id` bigint(20) DEFAULT NULL COMMENT '客戶ID',
  `balance_amount` bigint(20) DEFAULT NULL COMMENT '剩余金額',
  `version` bigint(20) DEFAULT '1' COMMENT '版本鎖',
  PRIMARY KEY (`id`) USING BTREE,
  KEY `idx_customer_id` (`customer_id`)
) COMMENT='客戶錢包信息';

4.1、悲觀鎖實現(xiàn)更新用戶錢包示例

這里提供一個使用悲觀鎖扣減錢包余額的示例，在第一次查詢時添加for update操作，那么其它線程進(jìn)入該方法時則會阻塞等待上一個方法事務(wù)提交才能繼續(xù)執(zhí)行，在這整個方法中都是線程安全的，這就是常見的結(jié)合數(shù)據(jù)庫實現(xiàn)悲觀鎖更新數(shù)據(jù)的示例，所有線程都必須排隊串行更新數(shù)據(jù)。

    @Transactional(rollbackFor = Exception.class)
    public boolean pessimisticLockSubAmount(Long customerId, Long happenAmount) {
        // 1、查詢用戶錢包 - 并且添加for update 鎖，這里customer_id字段添加了索引最終鎖定的還是索引定義行的ID，和直接使用ID區(qū)別不大
        // 這段代碼相當(dāng)于 select * from customer_wallet where customer_id = ? for update
        CustomerWallet customerWallet = lambdaQuery()
                .eq(CustomerWallet::getCustomerId, customerId)
                .last("for update")
                .one();
        if(customerWallet == null){
            throw new RuntimeException("用戶錢包不存在");
        }
        // 2、校驗用戶余額是否足夠
        Long balanceAmount = customerWallet.getBalanceAmount() - happenAmount;
        if(balanceAmount < 0){
            throw new RuntimeException("用戶余額不足");
        }
        // 3、更新錢包余額 update customer_wallet set balance_amount = ? where id = ?
        boolean update = lambdaUpdate()
                .eq(CustomerWallet::getId, customerWallet.getId())
                .set(CustomerWallet::getBalanceAmount, balanceAmount)
                .update();
        if(!update){
            throw new RuntimeException("錢包更新失敗");
        }
        // 4、添加余額明細(xì)
        addWalletDetail(customerWallet.getId(),2,happenAmount,balanceAmount);
        return update;
    }

4.2、樂觀鎖實現(xiàn)更新用戶錢包示例1

使用樂觀鎖更新數(shù)據(jù)時，執(zhí)行更新語句時通過判斷version是否有變動來確認(rèn)數(shù)據(jù)是否有過變更，如果數(shù)據(jù)庫當(dāng)前version值和查詢出來的version值相等則代表數(shù)據(jù)沒有變更可以更新，因為數(shù)據(jù)庫指定ID更新某一行數(shù)據(jù)時是在數(shù)據(jù)庫層面會添加行鎖，確保只能有一個事務(wù)進(jìn)行這行數(shù)據(jù)更新，這樣就保證了數(shù)據(jù)的一致性。

    @Transactional(isolation = Isolation.READ_COMMITTED, rollbackFor = Exception.class)
    public boolean subAmount(Long customerId, Long happenAmount) {
        // 1、獲取用戶錢包
        CustomerWallet customerWallet = lambdaQuery().eq(CustomerWallet::getCustomerId, customerId).one();
        if (customerWallet == null) {
            throw new RuntimeException("用戶錢包不存在");
        }
        // 2、判斷用戶余額是否足夠
        Long balanceAmount = customerWallet.getBalanceAmount() - happenAmount;
        if(balanceAmount < 0){
            throw new RuntimeException("用戶余額不足");
        }
        // 3、進(jìn)行樂觀鎖更新 
        // 這段代碼相當(dāng)于 update customer_wallet set balance_amount = ?, version = ? where id = ? and version = ?
        boolean update = lambdaUpdate()
                .eq(CustomerWallet::getId, customerWallet.getId())
                .eq(CustomerWallet::getVersion, customerWallet.getVersion())
                .set(CustomerWallet::getBalanceAmount, balanceAmount)
                .set(CustomerWallet::getVersion, customerWallet.getVersion() + 1)
                .update();
        if(!update){
            log.info("樂觀鎖更新失敗，開始自旋");
            return subAmount(customerId,happenAmount);
        }
        // 4、添加余額明細(xì)
        addWalletDetail(customerWallet.getId(),2,happenAmount,balanceAmount);
        return update;
    }

PS：注意，在使用樂觀鎖更新數(shù)據(jù)時，事務(wù)隔離級別必須設(shè)置為READ_COMMITTED，在最后注意事項中會進(jìn)行分析。

4.3、樂觀鎖實現(xiàn)更新用戶錢包示例2

在樂觀鎖實現(xiàn)更新用戶錢包示例1中使用了一個version字段來作為樂觀鎖更新的標(biāo)記，其實對于這種更新錢包的業(yè)務(wù)想使用樂觀鎖完全沒有必要單獨(dú)加一個version字段，可以直接使用余額字段作為這個樂觀鎖的比較字段，因為我們這里擬定的是用戶余額需要足夠才能支付，那么在更新錢包時判斷一下當(dāng)前余額是否大于等于所需金額，如果滿足調(diào)整則

    @Transactional(isolation = Isolation.READ_COMMITTED, rollbackFor = Exception.class)
    public boolean subAmountV2(Long customerId, Long happenAmount) {
        // 1、獲取用戶錢包
        CustomerWallet customerWallet = lambdaQuery().eq(CustomerWallet::getCustomerId, customerId).one();
        if (customerWallet == null) {
            throw new RuntimeException("用戶錢包不存在");
        }

        // 2、直接使用余額作為樂觀鎖更新依據(jù)進(jìn)行樂觀鎖更新
        // 這段代碼相當(dāng)于 update customer_wallet set balance_amount = balance_amount + ? where id = ? and balance_amount >= ?
        boolean update = lambdaUpdate()
                .eq(CustomerWallet::getId, customerWallet.getId())
                .ge(CustomerWallet::getBalanceAmount, happenAmount)
                .setSql("balance_amount = balance_amount - "+happenAmount)
                .update();
        if(!update){
            log.info("樂觀鎖更新失敗，用戶余額不足");
            throw new RuntimeException("用戶余額不足");
        }
        // 3、添加余額明細(xì) 注意這里需要從新查詢一次數(shù)據(jù)
        CustomerWallet customerWalletNew = lambdaQuery().eq(CustomerWallet::getCustomerId, customerId).one();
        addWalletDetail(customerWallet.getId(),2,happenAmount,customerWalletNew.getBalanceAmount());
        return update;
    }

PS：注意，在使用樂觀鎖更新數(shù)據(jù)時，事務(wù)隔離級別必須設(shè)置為READ_COMMITTED，在最后注意事項中會進(jìn)行分析。

五、注意事項

在使用樂觀鎖更新數(shù)據(jù)時要注意一個事務(wù)隔離級別的問題，我這里使用的是READ COMMITTED（讀已提交），如果使用的是REPEATABLE READ（可重復(fù)讀）會存在兩個問題，分別對應(yīng)4.2 和 4.3中的示例。

• 在4.2示例中通過version值來實現(xiàn)樂觀鎖更新，如果這里使用的事務(wù)隔離級別為REPEATABLE READ（可重復(fù)讀），那么在樂觀鎖沖突更新失敗自旋時因為MVCC機(jī)制查詢到的數(shù)據(jù)會是一個副本值，就算別的事務(wù)更新成功了讀取到的version都是歷史值，這樣會導(dǎo)致死循環(huán)遞歸最后棧溢出。
• 在4.3示例中采用余額這樣的字段進(jìn)行判斷更新，因為MySQL的更新數(shù)據(jù)采用的是當(dāng)前讀，這里其實無論使用REPEATABLE READ（可重復(fù)讀）還是READ COMMITTED（讀已提交）事務(wù)隔離級別都不會存在死循環(huán)問題，但是如果鎖沖突頻繁在使用REPEATABLE READ（可重復(fù)讀）事務(wù)隔離級別時可能會出現(xiàn)鎖持有時間過長問題，因為在REPEATABLE READ事務(wù)隔離級別下，在一個事務(wù)中執(zhí)行一個更新語句，就算where id=1 and balance_amount >= 100 這樣的條件不成立，也會將這一行數(shù)據(jù)進(jìn)行鎖定，需要等待事務(wù)提交或回滾才會釋放鎖，也就是說在自旋時其它事務(wù)想要更新數(shù)據(jù)等待時間會變長影響系統(tǒng)吞吐量，而使用READ COMMITTED事務(wù)隔離級別當(dāng)where中條件不成立更新失敗時不會持有鎖，也就是說事務(wù)A在更新失敗自旋時事務(wù)B也是可以進(jìn)行更新的，而不需要等待事務(wù)A自旋更新成功后才能進(jìn)行更新，這樣能提高系統(tǒng)吞吐量。

到此這篇關(guān)于java中樂觀鎖與悲觀鎖區(qū)別及使用場景分析的文章就介紹到這了,更多相關(guān)java 樂觀鎖與悲觀鎖內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！ 

最新評論