好像挺久沒有寫博客了，趁著這段時間比較閑，特來總結(jié)一下在業(yè)務(wù)系統(tǒng)開發(fā)過程中遇到的并發(fā)問題及解決辦法，希望能幫到大家 😁

問題復(fù)現(xiàn)

1. “設(shè)備Aの奇怪分身”

時間回到很久很久以前的一個深夜，那時我開發(fā)的多媒體廣告播放控制系統(tǒng)剛剛投產(chǎn)上線，公司開出的第一家線下生鮮店里，幾十個大大小小的多媒體硬件設(shè)備正常聯(lián)網(wǎng)后，正由我一臺一臺的注冊及接入到已經(jīng)上線的多媒體廣告播控系統(tǒng)中。
注冊過程簡述如下：

每一個設(shè)備注冊到系統(tǒng)中后，相應(yīng)的在數(shù)據(jù)庫設(shè)備表中都會新增一條記錄，來存儲這個設(shè)備的各項信息。
本來一切都有條不紊的進行著，直到設(shè)備A的注冊打破了這默契的寧靜……
設(shè)備A注冊完成后，我突然發(fā)現(xiàn)，數(shù)據(jù)庫設(shè)備表中，新增了兩條記錄，而且是兩條一模一樣的記錄！
我開始以為自己眼花了……
仔細一看，確確實實是新增了兩條，而且連設(shè)備唯一標識（劃橫線，后面要考）和創(chuàng)建時間都一模一樣！
看著屏幕，我陷入了沉思……
為什么會有兩條呢？
在我的注冊邏輯里，落庫之前會先查一遍數(shù)據(jù)庫該設(shè)備是否已存在，如果存在就更新已有的，不存在才新增。
所以我百思不得其解，按這個邏輯，第二條一模一樣的數(shù)據(jù)是哪來的？

2. 真相背后的并發(fā)請求

經(jīng)過一番排查及思考，我發(fā)現(xiàn)問題可能就出在注冊請求上。
設(shè)備A在向云端發(fā)送http注冊請求時，可能會同時發(fā)送多個相同請求。
云服務(wù)器當時部署在多臺Docker容器上，通過查看日志發(fā)現(xiàn)，有兩臺容器同時收到了來自設(shè)備A的注冊請求。
由此，我推測：
設(shè)備A同時發(fā)送了兩個注冊請求，這兩個請求分別在同一時間打到了云端的不同容器上，按照我的注冊邏輯，這兩個容器接收到注冊請求后，同時去查詢了數(shù)據(jù)庫的設(shè)備表，這時候設(shè)備表里還沒有設(shè)備A的記錄，所以兩臺容器都執(zhí)行了新增的操作，因為速度很快，所以這兩條新增記錄在精確到秒的創(chuàng)建時間上，并沒有體現(xiàn)出差別。

3. 并發(fā)新增的延伸

既然并發(fā)的新增操作會產(chǎn)生問題，那么并發(fā)的更新操作是否會有問題呢？

解決方法

解決并發(fā)新增

• 1. 數(shù)據(jù)庫唯一索引（UNIQUE INDEX）

在數(shù)據(jù)庫建表的時候，通過對具有唯一性的字段（比如上述的設(shè)備唯一標識）創(chuàng)建唯一索引，或?qū)M合起來后就具備唯一性的幾個字段創(chuàng)建聯(lián)合唯一索引。

這樣在并發(fā)新增時，只要有一個新增成功，其他的新增操作都會因為數(shù)據(jù)庫拋出的異常（java.sql.SQLIntegrityConstraintViolationException）而失敗，我們只需要處理好新增失敗的情況就行了。

注意唯一索引的字段需要非空，因為字段值為空時會導(dǎo)致唯一索引約束失效

• 2. java分布式鎖
  

通過在程序中引入分布式鎖，在進行新增操作前需要先獲取分布式鎖，獲取成功才能繼續(xù)，否則新增失敗。

這樣也能解決并發(fā)插入帶來的數(shù)據(jù)重復(fù)問題，只是引入分布式鎖的同時也增加了系統(tǒng)的復(fù)雜性，如果要落庫的數(shù)據(jù)上有唯一性字段的話，還是推薦采用唯一索引的方法。

在構(gòu)建分布式鎖的過程中，我們需要用到Redis，這里以設(shè)備注冊時使用的分布式鎖為例。

分布式鎖簡單問答：

Q：鎖究竟是什么？

A：鎖實質(zhì)上是存儲在Redis中，基于特定規(guī)則生成的一個字符串（示例里是固定前綴+設(shè)備唯一標識），相當于每個設(shè)備注冊的時候都有自己對應(yīng)的一把鎖，因為鎖只有一把，即使該設(shè)備有多個相同的注冊請求同時到來，也只有其中獲取到那把鎖的那一個請求能成功走下去。

Q：什么是獲取鎖？

A：同一個設(shè)備，基于相同的規(guī)則生成的字符串（后文以Key代稱該字符串）總是相同的，在執(zhí)行新增操作前，先去Redis中查詢這個Key是否存在，如果已存在，就意味著獲取鎖失?。蝗绻淮嬖?，就將這個Key現(xiàn)存到Redis中，如果存儲成功，表示獲取鎖成功，如果存儲失敗，還是意味著獲取鎖失敗。

Q：鎖是怎么工作的？

A：前面說過，同一個設(shè)備，基于相同的規(guī)則生成的字符串（Key）總是相同的，在當前線程執(zhí)行新增操作前，先在Redis中查詢這個Key是否存在，如果已存在，表示此時已經(jīng)有別的線程成功獲取了鎖，正在做當前線程想要做的新增操作，則當前線程不需要進行后續(xù)操作了（是的，你是多余的）

當這個Key不存在時，表示現(xiàn)在還沒有其他線程獲得鎖，則當前線程可以繼續(xù)進行下一步操作——在Redis中趕緊存入這個Key，當這個Key存儲失敗時，意味著有別的線程搶先存入了Key成功獲取了鎖，當前線程晚了一步，想做的工作被別人搶先做了（當前線程可以退下了）

當且僅當在Redis中存入這個Key也成功時，表示當前線程終于獲取鎖成功，可以安心進行后面的新增操作了，期間別的想做相同新增操作的線程因為獲取不到鎖，只能全都退場拜拜👋，當前線程執(zhí)行完后要記得釋放鎖（從Redis中刪除這個Key）。

注冊時使用的分布式鎖代碼如下：

public class LockUtil {

  // 對redis底層set/get方法進行了簡單封裝的工具類
  @Autowired
  private RedisService redisService;

  // 生成鎖的固定前綴，從配置文件讀取值
  @Value("${redis.register.prefix}")
  private String REDIS_REGISTER_KEY_PREFIX;

  // 鎖過期時間：即獲取鎖后線程能進行操作的最長時間，超過該時間后鎖自動被釋放（失效），別人可以重新開始獲取鎖進行對應(yīng)操作
  // 設(shè)定鎖過期時間是為了防止某線程成功獲取鎖后在執(zhí)行任務(wù)過程中發(fā)生意外掛掉了造成鎖永遠無法被釋放
  @Value("${redis.register.timeout}")
  private Long REDIS_REGISTER_TIMEOUT;

  /**
   * 獲取設(shè)備注冊時的分布式鎖
   * @param deviceMacAddress 設(shè)備的Mac地址
   * @return
   */
  public boolean getRegisterLock(String deviceMacAddress) {
    if (StringUtils.isEmpty(deviceMacAddress)) {
      return false;
    }

    // 獲取設(shè)備對應(yīng)鎖的字符串（Key）
    String redisKey = getRegisterLockKey(deviceMacAddress);

    // 開始嘗試獲取鎖
    // 如果當前任務(wù)鎖key已存在，則表示當前時間內(nèi)有其他線程正在對該設(shè)備執(zhí)行任務(wù)，當前線程可以退下了
    if (redisService.exists(redisKey)){
      return false;
    }

    // 開始嘗試加鎖，注意此處需使用SETNX指令（因為可能存在多個線程同時到達這一步開始加鎖，使用SETNX來確保有且僅有一個設(shè)置成功返回）
    boolean setLock = redisService.setNX(redisKey, null);

    // 開始嘗試設(shè)置鎖過期時間，到了過期時間線程還沒有釋放鎖的話，由保存鎖的Redis來確保鎖最終被釋放，以免出現(xiàn)死鎖
    // 鎖過期時間的設(shè)置上，可以評估線程執(zhí)行任務(wù)的正常用時，在正常用時的基礎(chǔ)上稍微再大一點
    boolean setExpire = redisService.expire(redisKey, REDIS_REGISTER_TIMEOUT);

    // 設(shè)置鎖和設(shè)置過期時間均成功時才認為當前線程獲取鎖成功，否則認為獲取鎖失敗
    if (setLock && setExpire) {
      return true;
    }

    // 當發(fā)生設(shè)置鎖成功，但設(shè)置過期時間失敗的情況時，手動清除剛剛設(shè)置的鎖Key
    redisService.del(redisKey);
    return false;
  }

  /**
   * 刪除設(shè)備注冊時的分布式鎖
   * @param deviceMacAddress 設(shè)備的Mac地址
   */
  public void delRegisterLock(String deviceMacAddress) {
    redisService.del(getRegisterLockKey(deviceMacAddress));
  }

  /**
   * 獲取設(shè)備注冊時分布式鎖的key
   * @param deviceMacAddress 設(shè)備mac地址（每個設(shè)備的mac地址都是唯一的）
   * @return
   */
  private String getRegisterLockKey(String deviceMacAddress) {
    return REDIS_REGISTER_KEY_PREFIX + "_" + deviceMacAddress;
  }
}

在正常的注冊邏輯中使用鎖的示例如下：

  public ReturnObj registry(@RequestBody String device){
    Devices deviceInfo = JSON.parseObject(device, Devices.class);

    // 開始注冊前加鎖
    boolean registerLock = lockUtil.getRegisterLock(deviceInfo.getMacAddress());
    if (!registerLock) {
      log.info("獲取設(shè)備注冊鎖失敗，當前注冊請求失?。?);
      return ReturnObj.createBussinessErrorResult();
    }

    // 加鎖成功，開始注冊設(shè)備
    ReturnObj result = registerDevice(deviceInfo);

    // 注冊設(shè)備完成，刪除鎖
    lockUtil.delRegisterLock(deviceInfo.getMacAddress());

    return result;
  }

解決并發(fā)更新

1. 并發(fā)更新真的會引發(fā)問題嗎？
當發(fā)生同時更新或一前一后更新的情況對業(yè)務(wù)并無影響的時候，那就無需進行任何處理，免得徒勞增加系統(tǒng)復(fù)雜度。

2. 樂觀鎖
通過樂觀鎖的方式可以避免重復(fù)更新，即：在數(shù)據(jù)庫表中加入一個“版本號”（version）的字段，在做更新操作前先查詢記錄，記下查詢出的版本號，之后在實際更新操作的時候判斷此前查詢出的版本號是否與當前數(shù)據(jù)庫中該條記錄的版本號一致，如果一致，說明在當前線程從查詢到更新這段時間里，沒有其他線程更新這條記錄；如果不一致，說明再此期間已經(jīng)有其他線程更改了這條記錄，當前線程的更新操作已經(jīng)不安全了，只能放棄。

判斷SQL示例：

update a_table set name=test1, age=12, version=version+1 where id = 3 and version = 1

樂觀鎖通過版本號的方式，在最后更新的關(guān)頭才判斷自己之前從數(shù)據(jù)庫讀取的數(shù)據(jù)有沒有被別人修改，其效率高于悲觀鎖，因為在當前線程查詢和最后更新前的這段時間里，其他線程可以照常讀取這同一條記錄，且可以搶先更新。

悲觀鎖

悲觀鎖與樂觀鎖恰好相反，在當前線程查詢這條待更新的數(shù)據(jù)時，就鎖住了這條數(shù)據(jù)，不允許在自己更新完成前有其他線程修改數(shù)據(jù)。

通過使用 select … for update 來告訴數(shù)據(jù)庫“我馬上要更新這條數(shù)據(jù)，把它給我鎖起來”。

注意：FOR UPDATE 僅適用于InnoDB，且必須在事務(wù)中才能生效，當查詢條件有明確主鍵且有此記錄時為行鎖定（row lock，只鎖定根據(jù)查詢條件定位到的這一行數(shù)據(jù)），查詢條件無主鍵或主鍵不明確時為表鎖定（table lock，鎖定全表，會造成全表的數(shù)據(jù)在鎖定期都無法被更改），所以使用悲觀鎖時查詢條件最好能明確定位到某一行或幾行，不要引發(fā)全表鎖定

以上就是Java 常見的并發(fā)問題處理方法總結(jié)的詳細內(nèi)容，更多關(guān)于Java 并發(fā)問題的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論