Java工作中常見的並發問題處理方法總結

Posted on by

問題復現

1. “設備Aの奇怪分身”

時間回到很久很久以前的一個深夜，那時我開發的多媒體廣告播放控制系統剛剛投產上線，公司開出的第一傢線下生鮮店裡，幾十個大大小小的多媒體硬件設備正常聯網後，正由我一臺一臺的註冊及接入到已經上線的多媒體廣告播控系統中。
註冊過程簡述如下：

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

2. 真相背後的並發請求

經過一番排查及思考，我發現問題可能就出在註冊請求上。
設備A在向雲端發送http註冊請求時，可能會同時發送多個相同請求。
雲服務器當時部署在多臺Docker容器上，通過查看日志發現，有兩臺容器同時收到瞭來自設備A的註冊請求。
由此，我推測：
設備A同時發送瞭兩個註冊請求，這兩個請求分別在同一時間打到瞭雲端的不同容器上，按照我的註冊邏輯，這兩個容器接收到註冊請求後，同時去查詢瞭數據庫的設備表，這時候設備表裡還沒有設備A的記錄，所以兩臺容器都執行瞭新增的操作，因為速度很快，所以這兩條新增記錄在精確到秒的創建時間上，並沒有體現出差別。

3. 並發新增的延伸

既然並發的新增操作會產生問題，那麼並發的更新操作是否會有問題呢？

解決方法

解決並發新增

1. 數據庫唯一索引（UNIQUE INDEX）

在數據庫建表的時候，通過對具有唯一性的字段（比如上述的設備唯一標識）創建唯一索引，或對組合起來後就具備唯一性的幾個字段創建聯合唯一索引。

這樣在並發新增時，隻要有一個新增成功，其他的新增操作都會因為數據庫拋出的異常（java.sql.SQLIntegrityConstraintViolationException）而失敗，我們隻需要處理好新增失敗的情況就行瞭。

註意唯一索引的字段需要非空，因為字段值為空時會導致唯一索引約束失效

2. java分佈式鎖

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

這樣也能解決並發插入帶來的數據重復問題，隻是引入分佈式鎖的同時也增加瞭系統的復雜性，如果要落庫的數據上有唯一性字段的話，還是推薦采用唯一索引的方法。

在構建分佈式鎖的過程中，我們需要用到Redis，這裡以設備註冊時使用的分佈式鎖為例。

分佈式鎖簡單問答：

Q：鎖究竟是什麼？

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

Q：什麼是獲取鎖？

A：同一個設備，基於相同的規則生成的字符串（後文以Key代稱該字符串）總是相同的，在執行新增操作前，先去Redis中查詢這個Key是否存在，如果已存在，就意味著獲取鎖失敗；如果不存在，就將這個Key現存到Redis中，如果存儲成功，表示獲取鎖成功，如果存儲失敗，還是意味著獲取鎖失敗。

Q：鎖是怎麼工作的？

A：前面說過，同一個設備，基於相同的規則生成的字符串（Key）總是相同的，在當前線程執行新增操作前，先在Redis中查詢這個Key是否存在，如果已存在，表示此時已經有別的線程成功獲取瞭鎖，正在做當前線程想要做的新增操作，則當前線程不需要進行後續操作瞭（是的，你是多餘的）

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

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

註冊時使用的分佈式鎖代碼如下：

public class LockUtil {

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

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

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

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

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

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

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

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

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

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

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

 /**
 * 獲取設備註冊時分佈式鎖的key
 * @param deviceMacAddress 設備mac地址（每個設備的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("獲取設備註冊鎖失敗，當前註冊請求失敗！");
  return ReturnObj.createBussinessErrorResult();
 }

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

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

 return result;
 }

解決並發更新

1. 並發更新真的會引發問題嗎？

當發生同時更新或一前一後更新的情況對業務並無影響的時候，那就無需進行任何處理，免得徒勞增加系統復雜度。

2. 樂觀鎖

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

判斷SQL示例：

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

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

悲觀鎖

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

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

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

到此這篇關於Java工作中常見的並發問題處理方法總結的文章就介紹到這瞭,更多相關Java工作中並發問題內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：