Java工作中常見的併發問題處理方法總結
好像挺久沒有寫部落格了，趁著這段時間比較閒，特來總結一下在業務系統開發過程中遇到的併發問題及解決辦法，希望能幫到大家 ?
問題復現
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，鎖定全表，會造成全表的資料在鎖定期都無法被更改），所以使用悲觀鎖時查詢條件最好能明確定位到某一行或幾行，不要引發全表鎖定