MySQL悲觀鎖與樂觀鎖的實現(xiàn)方案

更新時間：2021年11月02日 12:43:12 作者：程序員小潘

我們知道Mysql并發(fā)事務會引起更新丟失問題,解決辦法是鎖,所以本文將對鎖（樂觀鎖、悲觀鎖）進行分析,這篇文章主要給大家介紹了關于MySQL悲觀鎖與樂觀鎖方案的相關資料,需要的朋友可以參考下

前言

悲觀鎖和樂觀鎖是用來解決并發(fā)問題的兩種思想，在不同的平臺有著各自的實現(xiàn)。例如在Java中，synchronized就可以認為是悲觀鎖的實現(xiàn)(不嚴謹，有鎖升級的過程，升級到重量級鎖才算)，Atomic***原子類可以認為是樂觀鎖的實現(xiàn)。

悲觀鎖

具有強烈的獨占和排他特性，在整個處理過程中將數(shù)據(jù)處于鎖定狀態(tài)，一般是通過系統(tǒng)的互斥量來實現(xiàn)。當其他線程想要獲取鎖時會被阻塞，直到持有鎖的線程釋放鎖。

樂觀鎖

對數(shù)據(jù)的修改和訪問持樂觀態(tài)度，假設不會發(fā)生沖突，只有當數(shù)據(jù)提交更新時才會對數(shù)據(jù)沖突與否進行檢測，如果沒有沖突則順利提交更新，否則快速失敗，返回一個錯誤給用戶，讓用戶選擇接下來該如何去做，一般來說失敗后會繼續(xù)重試，直到提交更新成功為止。

MySQL本身就支持鎖機制，例如我們有一個「先查再寫」的需求，我們希望整個流程是一個原子操作，中間不能被打斷，這時候就可以通過給查詢的數(shù)據(jù)行加「排他鎖」來實現(xiàn)。只要當前事務不釋放鎖，其他事務要想獲得排他鎖，MySQL就會將其阻塞，直到當前事務釋放鎖。這種MySQL底層的排他鎖就稱作「悲觀鎖」。

MySQL本身不提供樂觀鎖的功能，需要開發(fā)者自己實現(xiàn)。普遍的做法是在表中加一個version列，用來標記數(shù)據(jù)行的版本，當我們需要更新數(shù)據(jù)時，必須比對version版本，version一致說明這個期間數(shù)據(jù)沒有被其他事務修改過，否則說明數(shù)據(jù)已經被其他事務修改，需要自旋重試了。

實戰(zhàn)

假設數(shù)據(jù)庫有兩張表：商品表和訂單表。

用戶下單后需要執(zhí)行兩個操作：

商品表減去庫存。
訂單表創(chuàng)建一條記錄。

初始數(shù)據(jù)：ID為1的商品有100的庫存，訂單表數(shù)據(jù)為空。

客戶端啟動10個線程并發(fā)下單，分別在無鎖、悲觀鎖、樂觀鎖的場景下有哪些表現(xiàn)。

如下是創(chuàng)建表的sql語句：

-- 商品表
CREATE TABLE `goods` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `goods_name` varchar(50) NOT NULL,
  `price` decimal(10,2) NOT NULL,
  `stock` int(11) DEFAULT '0',
  `version` int(10) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8

-- 訂單表
CREATE TABLE `t_order` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `goods_id` bigint(20) NOT NULL,
  `order_time` datetime NOT NULL,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8

1、無鎖

不做任何處理。

// 下單
private boolean order(){
    Goods goods = goodsMapper.selectById(1L);
    boolean success = false;
    if (goods.getStock() > 0) {
        goods.setStock(goods.getStock() - 1);
        // 更新庫存
        goodsMapper.updateById(goods);
        // 創(chuàng)建訂單
        orderMapper.save(goods.getId());
        success = true;
    }
    return success;
}

控制臺輸出結果：

2、悲觀鎖

查詢商品時加FOR UPDATE，給數(shù)據(jù)行加排他鎖，這樣其他線程再查詢時就會被阻塞，直到當前線程的事務提交并釋放鎖，其他線程才能繼續(xù)下單。這種方式并發(fā)性能不高。

sql語句

@Select("SELECT * FROM goods WHERE id = #{id} FOR UPDATE")
Goods selectForUpdate(Long id);

控制臺輸出結果：

注意：FOR UPDATE必須在事務中才有效，查詢和更新必須在同一個事務中！??！

3、樂觀鎖

實現(xiàn)思路是：每次更新時校驗版本號，如果版本號一致說明期間數(shù)據(jù)沒有被其他線程改過，當前線程可以正常提交更新，否則說明數(shù)據(jù)已經被其他線程改過了，當前線程需要自旋重試，直到業(yè)務成功為止。

更新數(shù)據(jù)的同時版本號必須自增?。?！

@Update("UPDATE goods SET stock = #{stock},version = version+1 WHERE id = #{id} AND version = #{version}")
int updateByVersion(Long id, Integer stock, Integer version);

業(yè)務代碼

boolean order(){
    Goods goods = goodsMapper.selectById(1L);
    boolean success = false;
    if (goods.getStock() > 0) {
        goods.setStock(goods.getStock() - 1);
        // 更新庫存，帶上版本號
        int result = goodsMapper.updateByVersion(goods.getId(), goods.getStock(), goods.getVersion());
        if (result <= 0) {
            // 更新失敗，說明期間數(shù)據(jù)已經被其他線程修改，需要遞歸重試
            return order();
        }
        // 創(chuàng)建訂單
        orderMapper.save(goods.getId());
        success = true;
    }
    return success;
}

控制臺輸出結果：