Java工作中的并發(fā)問(wèn)題處理方法有哪些

這篇文章主要介紹“Java工作中的并發(fā)問(wèn)題處理方法有哪些”，在日常操作中，相信很多人在Java工作中的并發(fā)問(wèn)題處理方法有哪些問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”Java工作中的并發(fā)問(wèn)題處理方法有哪些”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

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

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

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

注冊(cè)過(guò)程簡(jiǎn)述如下：

每一個(gè)設(shè)備注冊(cè)到系統(tǒng)中后，相應(yīng)的在數(shù)據(jù)庫(kù)設(shè)備表中都會(huì)新增一條記錄，來(lái)存儲(chǔ)這個(gè)設(shè)備的各項(xiàng)信息。

本來(lái)一切都有條不紊的進(jìn)行著，直到設(shè)備A的注冊(cè)打破了這默契的寧?kù)o……

設(shè)備A注冊(cè)完成后，我突然發(fā)現(xiàn)，數(shù)據(jù)庫(kù)設(shè)備表中，新增了 兩條 記錄，而且是 兩條一模一樣 的記錄！

我開始以為自己眼花了……

仔細(xì)一看，確確實(shí)實(shí)是新增了兩條，而且連設(shè)備唯一標(biāo)識(shí)（劃?rùn)M線，后面要考）和創(chuàng)建時(shí)間都一模一樣！

看著屏幕，我陷入了沉思……

為什么會(huì)有兩條呢？

在我的注冊(cè)邏輯里，落庫(kù)之前會(huì)先查一遍數(shù)據(jù)庫(kù)該設(shè)備是否已存在，如果存在就更新已有的，不存在才新增。

所以我百思不得其解，按這個(gè)邏輯，第二條一模一樣的數(shù)據(jù)是哪來(lái)的？

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

經(jīng)過(guò)一番排查及思考，我發(fā)現(xiàn)問(wèn)題可能就出在注冊(cè)請(qǐng)求上。

設(shè)備A在向云端發(fā)送http注冊(cè)請(qǐng)求時(shí)，可能會(huì)同時(shí)發(fā)送多個(gè)相同請(qǐng)求。

云服務(wù)器當(dāng)時(shí)部署在多臺(tái)Docker容器上，通過(guò)查看日志發(fā)現(xiàn)，有兩臺(tái)容器同時(shí)收到了來(lái)自設(shè)備A的注冊(cè)請(qǐng)求。

由此，我推測(cè)：

設(shè)備A同時(shí)發(fā)送了兩個(gè)注冊(cè)請(qǐng)求，這兩個(gè)請(qǐng)求分別在同一時(shí)間打到了云端的不同容器上，按照我的注冊(cè)邏輯，這兩個(gè)容器接收到注冊(cè)請(qǐng)求后，同時(shí)去查詢了數(shù)據(jù)庫(kù)的設(shè)備表，這時(shí)候設(shè)備表里還沒(méi)有設(shè)備A的記錄，所以兩臺(tái)容器都執(zhí)行了新增的操作，因?yàn)樗俣群芸?，所以這兩條新增記錄在 精確到秒 的創(chuàng)建時(shí)間上，并沒(méi)有體現(xiàn)出差別。

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

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

解決方法

解決并發(fā)新增

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

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

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

注意唯一索引的字段需要非空，因?yàn)樽侄沃禐榭諘r(shí)會(huì)導(dǎo)致唯一索引約束失效

2. java分布式鎖

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

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

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

分布式鎖簡(jiǎn)單問(wèn)答：

Q：鎖究竟是什么？

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

Q：什么是獲取鎖？

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

Q：鎖是怎么工作的？

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

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

當(dāng)且僅當(dāng)在Redis中存入這個(gè)Key也成功時(shí)，表示當(dāng)前線程終于獲取鎖成功，可以安心進(jìn)行后面的新增操作了，期間別的想做相同新增操作的線程因?yàn)楂@取不到鎖，只能全都退場(chǎng)拜拜:wave:，當(dāng)前線程執(zhí)行完后要記得釋放鎖（從Redis中刪除這個(gè)Key）。

注冊(cè)時(shí)使用的分布式鎖代碼如下：

public class LockUtil {      // 對(duì)redis底層set/get方法進(jìn)行了簡(jiǎn)單封裝的工具類      @Autowired      private RedisService redisService;      // 生成鎖的固定前綴，從配置文件讀取值      @Value("${redis.register.prefix}")      private String REDIS_REGISTER_KEY_PREFIX;      // 鎖過(guò)期時(shí)間：即獲取鎖后線程能進(jìn)行操作的最長(zhǎng)時(shí)間，超過(guò)該時(shí)間后鎖自動(dòng)被釋放（失效），別人可以重新開始獲取鎖進(jìn)行對(duì)應(yīng)操作      // 設(shè)定鎖過(guò)期時(shí)間是為了防止某線程成功獲取鎖后在執(zhí)行任務(wù)過(guò)程中發(fā)生意外掛掉了造成鎖永遠(yuǎn)無(wú)法被釋放      @Value("${redis.register.timeout}")      private Long REDIS_REGISTER_TIMEOUT;      /**       * 獲取設(shè)備注冊(cè)時(shí)的分布式鎖       * @param deviceMacAddress 設(shè)備的Mac地址       * @return       */      public boolean getRegisterLock(String deviceMacAddress) {          if (StringUtils.isEmpty(deviceMacAddress)) {              return false;          }          // 獲取設(shè)備對(duì)應(yīng)鎖的字符串（Key）          String redisKey = getRegisterLockKey(deviceMacAddress);          // 開始嘗試獲取鎖          // 如果當(dāng)前任務(wù)鎖key已存在，則表示當(dāng)前時(shí)間內(nèi)有其他線程正在對(duì)該設(shè)備執(zhí)行任務(wù)，當(dāng)前線程可以退下了          if (redisService.exists(redisKey)){              return false;          }          // 開始嘗試加鎖，注意此處需使用SETNX指令（因?yàn)榭赡艽嬖诙鄠€(gè)線程同時(shí)到達(dá)這一步開始加鎖，使用SETNX來(lái)確保有且僅有一個(gè)設(shè)置成功返回）          boolean setLock = redisService.setNX(redisKey, null);          // 開始嘗試設(shè)置鎖過(guò)期時(shí)間，到了過(guò)期時(shí)間線程還沒(méi)有釋放鎖的話，由保存鎖的Redis來(lái)確保鎖最終被釋放，以免出現(xiàn)死鎖          // 鎖過(guò)期時(shí)間的設(shè)置上，可以評(píng)估線程執(zhí)行任務(wù)的正常用時(shí)，在正常用時(shí)的基礎(chǔ)上稍微再大一點(diǎn)          boolean setExpire = redisService.expire(redisKey, REDIS_REGISTER_TIMEOUT);          // 設(shè)置鎖和設(shè)置過(guò)期時(shí)間均成功時(shí)才認(rèn)為當(dāng)前線程獲取鎖成功，否則認(rèn)為獲取鎖失敗          if (setLock && setExpire) {              return true;          }          // 當(dāng)發(fā)生設(shè)置鎖成功，但設(shè)置過(guò)期時(shí)間失敗的情況時(shí)，手動(dòng)清除剛剛設(shè)置的鎖Key          redisService.del(redisKey);          return false;      }      /**       * 刪除設(shè)備注冊(cè)時(shí)的分布式鎖       * @param deviceMacAddress 設(shè)備的Mac地址       */      public void delRegisterLock(String deviceMacAddress) {          redisService.del(getRegisterLockKey(deviceMacAddress));      }      /**       * 獲取設(shè)備注冊(cè)時(shí)分布式鎖的key       * @param deviceMacAddress 設(shè)備mac地址（每個(gè)設(shè)備的mac地址都是唯一的）       * @return      */      private String getRegisterLockKey(String deviceMacAddress) {          return REDIS_REGISTER_KEY_PREFIX + "_" + deviceMacAddress;      } }

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

public ReturnObj registry(@RequestBody String device){          Devices deviceInfo = JSON.parseObject(device, Devices.class);          // 開始注冊(cè)前加鎖          boolean registerLock = lockUtil.getRegisterLock(deviceInfo.getMacAddress());          if (!registerLock) {              log.info("獲取設(shè)備注冊(cè)鎖失敗，當(dāng)前注冊(cè)請(qǐng)求失??！");              return ReturnObj.createBussinessErrorResult();          }          // 加鎖成功，開始注冊(cè)設(shè)備          ReturnObj result = registerDevice(deviceInfo);          // 注冊(cè)設(shè)備完成，刪除鎖          lockUtil.delRegisterLock(deviceInfo.getMacAddress());          return result;      }

解決并發(fā)更新

1. 并發(fā)更新真的會(huì)引發(fā)問(wèn)題嗎？

當(dāng)發(fā)生同時(shí)更新或一前一后更新的情況對(duì)業(yè)務(wù)并無(wú)影響的時(shí)候，那就無(wú)需進(jìn)行任何處理，免得徒勞增加系統(tǒng)復(fù)雜度。

2. 樂(lè)觀鎖

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

判斷SQL示例：

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

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

悲觀鎖

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

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

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

到此，關(guān)于“Java工作中的并發(fā)問(wèn)題處理方法有哪些”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！