環(huán)球熱頭條丨java中的死鎖如何優(yōu)化？mysql之鎖優(yōu)化

文章目錄

(資料圖片僅供參考)

前言語句層面死鎖如何安全地給小表加字段總結(jié)

前言

之前的文章，我們對(duì)鎖的種類，和鎖的一些用途，進(jìn)行了簡(jiǎn)單的講解。今天我們將接著上張的內(nèi)容，對(duì)鎖的優(yōu)化進(jìn)行介紹。

語句層面

首先，我們從語句層面介紹下怎么進(jìn)行鎖優(yōu)化。之前的文章我們介紹過，鎖實(shí)在sql執(zhí)行的時(shí)候才會(huì)加鎖。但是鎖的釋放，卻是在事務(wù)提交之后，才會(huì)釋放。這樣就會(huì)帶來一個(gè)問題。如下圖 假如，這是一個(gè)電影院的一個(gè)購(gòu)票業(yè)務(wù)。電影院叫b，客戶為a，a想在b買一張電影票，上圖則是一個(gè)完整的買票流程。然后這個(gè)時(shí)候，c也想從電影院買張票，那么c和a沖突的地方就是第二條語句。如果我們把第二條語句放在最后，那么a和c沖突的時(shí)間是不是就會(huì)縮短。因?yàn)殒i是在最后事務(wù)提交的時(shí)候才會(huì)釋放，那么放在最后執(zhí)行沖突語句，鎖持續(xù)的時(shí)間就是最短的。這樣就可以減少鎖的時(shí)間，減少并發(fā)沖突的時(shí)間。

死鎖

說起死鎖，相必大家都不會(huì)陌生，因?yàn)檫@個(gè)在java中也是十分的常見的。產(chǎn)生死鎖的原因就是雙方互相占有對(duì)方所需要的的互斥資源，且短時(shí)間內(nèi)，不會(huì)釋放。那么從這個(gè)描述上呢，我們基本可以有四種解決方法。但是在mysql中呢，大致有兩種解決方法。因?yàn)閙ysql中的鎖不會(huì)像java中的鎖，那么便于操作。如下圖 事務(wù)a和事務(wù)b相互需要對(duì)方的行鎖，導(dǎo)致死鎖的產(chǎn)生。這個(gè)時(shí)候大致有兩種策略。 1.直接進(jìn)入等待，直到超時(shí)，這個(gè)超時(shí)的參數(shù)可以自己設(shè)置。 2.死鎖檢測(cè)，檢測(cè)到這個(gè)死鎖，然后對(duì)其中一個(gè)事務(wù)進(jìn)行回滾，釋放出另一個(gè)事務(wù)需要的鎖，以便兩個(gè)語句都能進(jìn)行下去。 但是開啟死鎖檢測(cè)是十分的消耗性能的，比如一千個(gè)事務(wù)同時(shí)更新同一行數(shù)據(jù)，那么死鎖基本要檢測(cè)1000x1000行數(shù)據(jù)，消耗太大。 那遇到這種熱點(diǎn)表怎么辦呢，最好的辦法就是控制并發(fā)，可以用一個(gè)隊(duì)列（不管是在數(shù)據(jù)庫(kù)中實(shí)現(xiàn)，還是依靠消息中間件實(shí)現(xiàn)，都可以），讓進(jìn)來的事務(wù)進(jìn)行排隊(duì)，同一時(shí)間至多有10個(gè)，或者20個(gè)可以對(duì)這行數(shù)據(jù)進(jìn)行修改，這樣就可以很好的實(shí)現(xiàn)并發(fā)修改了。

如何安全地給小表加字段

首先我們要解決長(zhǎng)事務(wù)，事務(wù)不提交，就會(huì)一直占著 MDL 鎖。在 MySQL 的 information_schema 庫(kù)的 innodb_trx 表中，你可以查到當(dāng)前執(zhí)行中的事務(wù)。如果你要做 DDL 變更的表剛好有長(zhǎng)事務(wù)在執(zhí)行，要考慮先暫停 DDL，或者 kill 掉這個(gè)長(zhǎng)事務(wù)。但考慮一下這個(gè)場(chǎng)景。如果你要變更的表是一個(gè)熱點(diǎn)表，雖然數(shù)據(jù)量不大，但是上面的請(qǐng)求很頻繁，而你不得不加個(gè)字段，你該怎么做呢？這時(shí)候 kill 可能未必管用，因?yàn)樾碌恼?qǐng)求馬上就來了。比較理想的機(jī)制是，在 alter table 語句里面設(shè)定等待時(shí)間，如果在這個(gè)指定的等待時(shí)間里面能夠拿到 MDL 寫鎖最好，拿不到也不要阻塞后面的業(yè)務(wù)語句，先放棄。之后開發(fā)人員或者 DBA 再通過重試命令重復(fù)這個(gè)過程。

總結(jié)

今天我們繼續(xù)上篇文章，對(duì)鎖的優(yōu)化進(jìn)行了講解，但是只是在語句層面進(jìn)行大致的講解。同時(shí)也介紹的死鎖的出現(xiàn)原因，和怎么避免死鎖的方法。