Java工做中常見的併發問題處理方法總結
好像挺久沒有寫博客了，趁着這段時間比較閒，特來總結一下在業務系統開發過程當中遇到的併發問題及解決辦法，但願能幫到你們 :grin:java
問題復現
1. 「設備Aの奇怪分身」
時間回到好久好久之前的一個深夜，那時我開發的多媒體廣告播放控制系統剛剛投產上線，公司開出的第一家線下生鮮店裏，幾十個大大小小的多媒體硬件設備正常聯網後，正由我一臺一臺的註冊及接入到已經上線的多媒體廣告播控系統中。redis
註冊過程簡述以下：sql
每個設備註冊到系統中後，相應的在數據庫設備表中都會新增一條記錄，來存儲這個設備的各項信息。數據庫
原本一切都有條不紊的進行着，直到設備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也成功時，表示當前線程終於獲取鎖成功，能夠安心進行後面的新增操做了，期間別的想作相同新增操做的線程由於獲取不到鎖，只能全都退場拜拜:wave:，當前線程執行完後要記得釋放鎖（從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，鎖定全表，會形成全表的數據在鎖按期都沒法被更改），因此使用悲觀鎖時查詢條件最好能明肯定位到某一行或幾行，不要引起全表鎖定
END
版權申明：內容來源網絡，版權歸原創者全部。除非沒法確認，咱們都會標明做者及出處，若有侵權煩請告知，咱們會當即刪除並表示歉意。謝謝。
本文分享自微信公衆號 - JAVA高級架構（gaojijiagou）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。