本文轉(zhuǎn)載自微信公眾號「程序喵大人」，作者程序喵大人 。轉(zhuǎn)載本文請聯(lián)系程序喵大人公眾號。

在多線程開發(fā)過程中很多人應(yīng)該都會遇到死鎖問題，死鎖問題也是面試過程中經(jīng)常被問到的問題，這里介紹在c++中如何使用gdb+python腳本調(diào)試死鎖問題，以及如何在程序運行過程中檢測死鎖。

首先介紹什么是死鎖，看下維基百科中的定義：

死鎖(英語：Deadlock)，又譯為死結(jié)，計算機科學(xué)名詞。當(dāng)兩個以上的運算單元，雙方都在等待對方停止運行，以獲取系統(tǒng)資源，但是沒有一方提前退出時，就稱為死鎖。在多任務(wù)操作系統(tǒng)中，操作系統(tǒng)為了協(xié)調(diào)不同行程，能否獲取系統(tǒng)資源時，為了讓系統(tǒng)運作，必須要解決這個問題。

維基百科中介紹的是進程死鎖，多線程中也會產(chǎn)生死鎖，一樣的道理，這里不作過多介紹。

死鎖的四個條件

禁止搶占(no preemption)：系統(tǒng)資源不能被強制從一個進程(線程)中退出，已經(jīng)獲得的資源在未使用完之前不能被搶占。

等待和保持(hold and wait)：一個進程(線程)因請求資源阻塞時，對已獲得的資源保持不放。

互斥(mutual exclusion)：資源只能同時分配給一個進程(線程)，無法多個進程(線程)共享。

循環(huán)等待(circular waiting)：一系列進程(線程)互相持有其他進程(線程)所需要的資源。

只有同時滿足以上四個條件，才會產(chǎn)生死鎖，想要消除死鎖只需要破壞其中任意一個條件即可。

如何調(diào)試多線程死鎖問題

多線程出現(xiàn)死鎖的大部分原因都是因為多個線程中加鎖的順序不一致導(dǎo)致的，看如下這段會出現(xiàn)死鎖的代碼：

using?std::cout;

std::mutex?mutex1;

std::mutex?mutex2;

std::mutex?mutex3;

void?FuncA()?{

std::lock_guard<:mutex>?guard1(mutex1);

std::this_thread::sleep_for(std::chrono::seconds(1));

std::lock_guard<:mutex>?guard2(mutex2);

std::this_thread::sleep_for(std::chrono::seconds(1));

}

void?FuncB()?{

std::lock_guard<:mutex>?guard2(mutex2);

std::this_thread::sleep_for(std::chrono::seconds(1));

std::lock_guard<:mutex>?guard3(mutex3);

std::this_thread::sleep_for(std::chrono::seconds(1));

}

void?FuncC()?{

std::lock_guard<:mutex>?guard3(mutex3);

std::this_thread::sleep_for(std::chrono::seconds(1));

std::lock_guard<:mutex>?guard1(mutex1);

std::this_thread::sleep_for(std::chrono::seconds(1));

}

intmain()?{

std::thread?A(FuncA);

std::thread?B(FuncB);

std::thread?C(FuncC);

std::this_thread::sleep_for(std::chrono::seconds(5));

if?(A.joinable())?{

A.join();

}

if?(B.joinable())?{

B.join();

}

if?(C.joinable())?{

C.join();

}

cout?<

return0;

}

如圖：

線程A已經(jīng)持有mutex1，想要申請mutex2，拿到mutex2后才可以釋放mutex1和mutex2，而此時mutex2被線程B占用。

線程B已經(jīng)持有mutex2，想要申請mutex3，拿到mutex3后才可以釋放mutex2和mutex3，而此時mutex3被線程C占用。

線程C已經(jīng)持有mutex3，想要申請mutex1，拿到mutex1后才可以釋放mutex3和mutex1，而此時mutex1被線程A占用。

三個線程誰也不讓著誰，導(dǎo)致了死鎖。

傳統(tǒng)gdb調(diào)試多線程死鎖方法

(1)attach id關(guān)聯(lián)到發(fā)生死鎖的進程id

(gdb)?attach?109

Attaching?toprocess?109

[New?LWP?110]

[New?LWP?111]

[New?LWP?112]

[Thread?debugging?using?libthread_db?enabled]

Using?host?libthread_db?library?"/lib/x86_64-linux-gnu/libthread_db.so.1".

0x00007fa33f9e8d2d?in__GI___pthread_timedjoin_ex?(threadid=140339109693184,?thread_return=0x0,?abstime=0x0,

block=)atpthread_join_common.c:89

89??????pthread_join_common.c:?Nosuch?fileordirectory.

(2)info threads查看當(dāng)前進程中所有線程的信息，也可以查看到部分堆棧信息

(gdb)?info?threads

Id???Target?Id?????????Frame

*?1????Thread?0x7fa33ff10740?(LWP?109)?"out"0x00007fa33f9e8d2din__GI___pthread_timedjoin_ex?(

threadid=140339109693184,?thread_return=0x0,?abstime=0x0,?block=)atpthread_join_common.c:89

2????Thread?0x7fa33ec80700?(LWP?110)?"out"__lll_lock_wait?()at../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135

3????Thread?0x7fa33e470700?(LWP?111)?"out"__lll_lock_wait?()at../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135

4????Thread?0x7fa33dc60700?(LWP?112)?"out"__lll_lock_wait?()at../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135

這里可以看到2、3、4線程都在lock_wait狀態(tài)，基本上可以看出或許是否問題，但是不一定，這里需要多次info threads看看這些線程有沒有什么變化，多次如果都沒有變化那基本上就是發(fā)生了死鎖。

(3)thread id進入具體線程

(gdb)?thread?2

[Switching?tothread?2?(Thread?0x7fa33ec80700?(LWP?110))]

#0?__lll_lock_wait?()?at../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135

135?????../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:?Nosuch?fileordirectory.

(4)bt查看當(dāng)前線程堆棧信息

(gdb)?bt

#0?__lll_lock_wait?()?at../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135

#1?0x00007fa33f9ea023?in__GI___pthread_mutex_lock?(mutex=0x7fa340204180?)at../nptl/pthread_mutex_lock.c:78

#2?0x00007fa340000fff?in__gthread_mutex_lock(pthread_mutex_t*)?()

#3?0x00007fa3400015b2?instd::mutex::lock()?()

#4?0x00007fa3400016d8?instd::lock_guard<:mutex>::lock_guard(std::mutex&)?()

#5?0x00007fa34000109b?inFuncA()?()

#6?0x00007fa340001c07?invoid?std::__invoke_impl(std::__invoke_other,?void?(*&&)())?()

調(diào)試到這里基本已經(jīng)差不多了，針對pthread_mutex_t卻可以打印出被哪個線程持有，之后再重復(fù)步驟3和4，就可以確定哪幾個線程以及哪幾把鎖發(fā)生的死鎖，而針對于std::mutex，gdb沒法打印具體的mutex的信息，不能看出來mutex是被哪個線程持有，只能依次進入線程查看堆棧信息。

然而針對于c++11的std::mutex有沒有什么好辦法定位死鎖呢?

有。

可以算作第五步，繼續(xù)：

(5)source加載deadlock.py腳本

(gdb)?source?-v?deadlock.py

Type?"deadlock"todetect?deadlocks.

(6)輸入deadlock檢測死鎖

(gdb)?deadlock

[Switching?tothread?3?(Thread?0x7f5585670700?(LWP?123))]

#0?__lll_lock_wait?()?at../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135

135?????in../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S

[Switching?tothread?4?(Thread?0x7f5584e60700?(LWP?124))]

#0?__lll_lock_wait?()?at../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135

135?????in../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S

[Switching?tothread?2?(Thread?0x7f5585e80700?(LWP?122))]

#0?__lll_lock_wait?()?at../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135

135?????in../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S

#1?0x00007f5586bea023?in__GI___pthread_mutex_lock?(mutex=0x7f5587404180?)at../nptl/pthread_mutex_lock.c:78

[Switching?tothread?3?(Thread?0x7f5585670700?(LWP?123))]

#0?__lll_lock_wait?()?at../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135

#1?0x00007f5586bea023?in__GI___pthread_mutex_lock?(mutex=0x7f55874041c0?)at../nptl/pthread_mutex_lock.c:78

[Switching?tothread?4?(Thread?0x7f5584e60700?(LWP?124))]

#0?__lll_lock_wait?()?at../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135

#1?0x00007f5586bea023?in__GI___pthread_mutex_lock?(mutex=0x7f5587404140?)at../nptl/pthread_mutex_lock.c:78

Found?deadlock!

Thread?2?(LWP?122)?iswaitingonpthread_mutex_t?(0x00007f5587404180)?heldbyThread?3?(LWP?123)

Thread?3?(LWP?123)?iswaitingonpthread_mutex_t?(0x00007f55874041c0)?heldbyThread?4?(LWP?124)

Thread?4?(LWP?124)?iswaitingonpthread_mutex_t?(0x00007f5587404140)?heldbyThread?2?(LWP?122)

直接看結(jié)果，腳本檢測出了死鎖，并指明了具體的哪幾個線程造成的死鎖，根據(jù)輸出信息可以明顯看出來線程鎖形成的環(huán)造成了死鎖，找到了具體是哪幾個線程構(gòu)成的死鎖環(huán)，就可以查看相應(yīng)線程的堆棧信息查看到哪幾把鎖正在等待。

死鎖檢測腳本的原理：

還是拿上面圖舉例：

線程A已經(jīng)持有mutex1，想要申請mutex2，拿到mutex2后才可以釋放mutex1和mutex2，而此時mutex2被線程B占用。

線程B已經(jīng)持有mutex2，想要申請mutex3，拿到mutex3后才可以釋放mutex2和mutex3，而此時mutex3被線程C占用。

線程C已經(jīng)持有mutex3，想要申請mutex1，拿到mutex1后才可以釋放mutex3和mutex1，而此時mutex1被線程A占用。

如圖，三個線程形成了一個環(huán)，死鎖檢測就是檢查線程之間是否有環(huán)的存在。單獨檢查死鎖的環(huán)比較容易，這里延申下還涉及到簡單環(huán)的概念，因為正常檢測出來的環(huán)可能是個大環(huán)，不是權(quán)值頂點數(shù)最少的環(huán)，如果檢測的環(huán)的頂點數(shù)較多，加大定位的代價，腳本就是檢測的簡單環(huán)，這里涉及到強連通分量算法和簡單環(huán)算法，比較繁瑣就不過多介紹了，腳本來源于facebook的folly庫(這里推薦看下google的abseil和facebook的folly，都是好東西)，代碼較長在文中不好列出，如果有需要的話可以自行下載或者關(guān)注加我好友發(fā)給你。

如何在代碼中檢測死鎖

和上面介紹的原理相同，在線程加鎖過程中始終維護一張圖，記錄線程之間的關(guān)系

A->B, B->C, C->A

【編輯推薦】

【責(zé)任編輯：武曉燕 TEL：(010)68476606】

點贊 0

與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的linux系统如何查看是否是线程死锁,多线程中如何使用gdb精确定位死锁问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。