特別感謝:慕課網jimin老師的《Java併發編程與高併發解決方案》課程,以下知識點多數來自老師的課程內容。
jimin老師課程地址:Java併發編程與高併發解決方案
什麼是死鎖?
通俗的說,死鎖就是兩個或者多個線程,相互佔用對方需要的資源,而都不進行釋放,導致彼此之間都相互等待對方釋放資源,產生了無限制等待的現象。死鎖一旦發生,如果沒有外力介入,這種等待將永遠存在,從而對程序產生嚴重影響。
用來描述死鎖的問題最有名的場景就是“哲學家就餐問題”。哲學家就餐問題可以這樣表述:假設有五位哲學家圍坐在一張圓形餐桌旁,做以下兩件事之一:吃飯或者思考。吃東西的時候他們就停止思考,思考的時候也停止吃東西。餐桌中間有一大碗意大利麪,每兩個哲學家之間有一隻餐叉。因爲只用一隻餐叉很難吃到意大利麪,所以假設哲學家必須用兩隻餐叉吃東西。他們只能使用自己左右手邊的那兩隻餐。哲學家從來不交談,這就跟危險,可能產生死鎖,每個哲學家都拿着左手的餐叉永遠等右邊的餐叉(或者相反)….
死鎖產生的必要條件
- 互斥條件:進程對鎖分配的資源進行排他性使用
- 請求和保持條件:線程已經保持了一個資源,但是又提出了其他請求,而該資源已被其他線程佔用
- 不剝奪條件:在使用時不能被剝奪,只能自己用完釋放
- 環路等待條件:資源調用是一個環形的鏈
死鎖示例
@Slf4j
public class DeadLock implements Runnable {
public int flag = 1;
//靜態對象是類的所有對象共享的
private static Object o1 = new Object(), o2 = new Object();
@Override
public void run() {
log.info("flag:{}", flag);
if (flag == 1) {
synchronized (o1) {
try {
Thread.sleep(500);
} catch (Exception e) {
e.printStackTrace();
}
synchronized (o2) {
log.info("1");
}
}
}
if (flag == 0) {
synchronized (o2) {
try {
Thread.sleep(500);
} catch (Exception e) {
e.printStackTrace();
}
synchronized (o1) {
log.info("0");
}
}
}
}
public static void main(String[] args) {
DeadLock td1 = new DeadLock();
DeadLock td2 = new DeadLock();
td1.flag = 1;
td2.flag = 0;
//td1,td2都處於可執行狀態,但JVM線程調度先執行哪個線程是不確定的。
//td2的run()可能在td1的run()之前運行
new Thread(td1).start();
new Thread(td2).start();
}
}
上述代碼出現死鎖原因:
- 當DeadLock類的對象flag==1時(td1),先鎖定o1,睡眠500毫秒
- 而td1在睡眠的時候另一個flag==0的對象(td2)線程啓動,先鎖定o2,睡眠500毫秒
- td1睡眠結束後需要鎖定o2才能繼續執行,而此時o2已被td2鎖定;
- td2睡眠結束後需要鎖定o1才能繼續執行,而此時o1已被td1鎖定;
- td1、td2相互等待,都需要得到對方鎖定的資源才能繼續執行,從而死鎖。
確認死鎖
在真實的環境中,我們發現程序無法執行,並且CPU佔用爲0,這樣就有理由懷疑產生了死鎖,但是光懷疑是不行的,我們需要一個實際的驗證方法。接下來我們使用jdk提供的工具來檢測是否真正發生了死鎖。
運行上述的代碼,並在windows系統中使用cmd進入控制檯,輸入以下命令:
jps
可見控制檯輸出:我們上邊運行的類的類名以及對應的進程ID
接下來使用命令獲取進程對應線程的堆棧信息:
jstack 9284
分析堆棧信息(提取有用的部分)
兩個線程都進行了加鎖操作(如上圖)
系統發現了一個Java-level的線程死鎖。ok,確認無疑是發生了死鎖現象。
避免死鎖
- 注意加鎖順序(這個很好理解,就像上邊的例子)
- 加鎖時限(超過時限放棄加鎖)
實現方式–使用重入鎖。關於重入鎖可以見我之前的博客:併發容器J.U.C – AQS組件 鎖:ReentrantLock、ReentrantReadWriteLock、StempedLock - 死鎖檢測(較難,就像分析上邊的線程情況)