“樂觀鎖”這個詞以前我也沒聽過。上次在測試需求的時候,查詢資料庫發現有一個version
欄位,於是請教開發這個字幹嘛使,
人家回覆我:樂觀鎖,解決併發更新用的。當時大家都忙,我們也不敢多問。
今天就來折騰一下“樂觀鎖”。
一、什麼是樂觀鎖
樂觀鎖其實用一句話來形容其作用就是:當要更新一條記錄的時候,希望這條記錄沒有被別人更新,從而實現執行緒安全的資料更新。
結合下場景,記得那是一張庫存表,有一個欄位記錄商品庫存,涉及多個地方都有可能去更新它:
- 程式A 查詢到了這條資料,得到庫存是800,準備+200更新成1000,但是還沒更新。
- 程式B 也查詢到了這條資料,得到庫存是800,準備-200更新成600,並且提交更新了。
那麼,這時候A再提交更新之後,B就會發現明明是自己是800-200=600,怎麼最後變成了1000?
這就是因為A的事務導致了B的資料更新丟失。
文字可能讀起來比較晦澀,有請靈魂畫手:
正常情況下:
- 按先後順序是, A先更新成1000,然後B再拿1000-200,更新成800,這樣B就沒異議了。
- 或者實在要2個同時更新,那也只能有一個成功,這樣也沒異議。
二、MP來實現樂觀鎖
樂觀鎖的實現,通過增加一個欄位,比如version,來記錄每次的更新。
查詢資料的時候帶出version的值,執行更新的時候,會再去比較version,如果不一致,就更新失敗。
還是用之前的user表,增加了新的欄位version
。
1.在實體類裡增加對於的欄位,並且加上自動填充(你也可以每次手動填充)
@Data
public class User {
@TableId(type = IdType.ID_WORKER)
private Long id;
private String name;
private Integer age;
private String email;
@TableField(fill = FieldFill.INSERT) // 新增的時候填充資料
private Date createTime;
@TableField(fill = FieldFill.INSERT_UPDATE) // 新增或修改的時候填充資料
private Date updateTime;
@TableField(fill = FieldFill.INSERT)
@Version
private Integer version; // 版本號
}
@Component //此註解表示 將其交給spring去管理
public class MyMetaObjectHandler implements MetaObjectHandler {
@Override
public void insertFill(MetaObject metaObject) {
this.setFieldValByName("createTime", new Date(), metaObject);
this.setFieldValByName("updateTime", new Date(), metaObject);
this.setFieldValByName("version", 0, metaObject); //新增就設定版本值為0
}
@Override
public void updateFill(MetaObject metaObject) {
this.setFieldValByName("updateTime", new Date(), metaObject);
}
}
2. 配置外掛
為了便於管理,可以見一個包,用於存放各種配置類,順便把配置在啟動類裡的mapper掃描也換到這裡來。
package com.pingguo.mpdemo.config;
import com.baomidou.mybatisplus.extension.plugins.OptimisticLockerInterceptor;
import org.mybatis.spring.annotation.MapperScan;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
// 配置掃描mapper的路徑
@MapperScan("com.pingguo.mpdemo.mapper")
public class MpConfig {
// 樂觀鎖外掛
@Bean
public OptimisticLockerInterceptor optimisticLockerInterceptor() {
return new OptimisticLockerInterceptor();
}
}
3.測試樂觀鎖
先新增一條測試資料:
// 新增
@Test
void addUser() {
User user = new User();
user.setName("大周");
user.setAge(22);
user.setEmail("laowang@123.com");
userMapper.insert(user);
}
新增成功,可以看到version值是0。
再來試一下正常的修改:
// 測試樂觀鎖
@Test
void testOptimisticLocker() {
User user = userMapper.selectById(1342502561945915393L);
user.setName("大周2");
userMapper.updateById(user);
}
修改成功,可以看到version 變成了1。
最後,模擬下併發更新,樂觀鎖更新失敗的情況:
// 測試樂觀鎖-失敗
@Test
void testOptimisticLockerFailed() {
User user = userMapper.selectById(1342502561945915393L);
user.setName("大周3");
User user2 = userMapper.selectById(1342502561945915393L);
user2.setName("大周4");
userMapper.updateById(user2); // 這裡user2插隊到user前面,先去更新
userMapper.updateById(user); // 這裡由於user2先做了更新後,版本號不對,所以更新失敗
}
按照樂觀鎖的原理,user2是可以更新成功的,也就是name會修改為“大周4”,version會加1。user因為前後拿到的版本號不對,更新失敗。
結果符合預期,我們也可以看下mybatis的日誌,進一步瞭解一下:
可以看到上面首先是2個查詢,查詢到的version都是1。
接著,第一個執行update語句的時候,where條件中version=1,可以找到資料,於是更新成功,切更新version=2。
ps:這裡圖丟了一個我重新補的一個資料,說明下意思,忽略ID與上面的不一致。
而第二個再執行update的時候,where條件version=1,已經找不到了,因為version已經被上面的更新成了2,所以更新失敗。