[[337631]]

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

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

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

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

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

死鎖的四個條件

• 禁止搶占(no preemption)：系統(tǒng)資源不能被強(qiáng)制從一個進(jìn)程(線程)中退出，已經(jīng)獲得的資源在未使用完之前不能被搶占。
• 等待和保持(hold and wait)：一個進(jìn)程(線程)因請求資源阻塞時，對已獲得的資源保持不放。
• 互斥(mutual exclusion)：資源只能同時分配給一個進(jìn)程(線程)，無法多個進(jìn)程(線程)共享。
• 循環(huán)等待(circular waiting)：一系列進(jìn)程(線程)互相持有其他進(jìn)程(線程)所需要的資源。

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

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

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

using std::cout; 
 
std::mutex mutex1; 
std::mutex mutex2; 
std::mutex mutex3; 
 
void FuncA() { 
   std::lock_guard<std::mutex> guard1(mutex1); 
   std::this_thread::sleep_for(std::chrono::seconds(1)); 
   std::lock_guard<std::mutex> guard2(mutex2); 
   std::this_thread::sleep_for(std::chrono::seconds(1)); 
} 
 
void FuncB() { 
   std::lock_guard<std::mutex> guard2(mutex2); 
   std::this_thread::sleep_for(std::chrono::seconds(1)); 
   std::lock_guard<std::mutex> guard3(mutex3); 
   std::this_thread::sleep_for(std::chrono::seconds(1)); 
} 
 
void FuncC() { 
   std::lock_guard<std::mutex> guard3(mutex3); 
   std::this_thread::sleep_for(std::chrono::seconds(1)); 
   std::lock_guard<std::mutex> guard1(mutex1); 
   std::this_thread::sleep_for(std::chrono::seconds(1)); 
} 
 
int main() { 
   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 << "hello\n"; 
   return 0; 
} 

如圖：

• 線程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ā)生死鎖的進(jìn)程id

(gdb) attach 109 
Attaching to process 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=<optimized out>) at pthread_join_common.c:89 
89      pthread_join_common.c: No such file or directory. 

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

(gdb) info threads 
Id   Target Id         Frame 
* 1    Thread 0x7fa33ff10740 (LWP 109) "out" 0x00007fa33f9e8d2d in __GI___pthread_timedjoin_ex ( 
threadid=140339109693184, thread_return=0x0, abstime=0x0, block=<optimized out>) at pthread_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進(jìn)入具體線程

(gdb) thread 2 
[Switching to thread 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: No such file or directory. 

(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 <mutex2>) at ../nptl/pthread_mutex_lock.c:78 
#2 0x00007fa340000fff in __gthread_mutex_lock(pthread_mutex_t*) () 
#3 0x00007fa3400015b2 in std::mutex::lock() () 
#4 0x00007fa3400016d8 in std::lock_guard<std::mutex>::lock_guard(std::mutex&) () 
#5 0x00007fa34000109b in FuncA() () 
#6 0x00007fa340001c07 in void std::__invoke_impl<void, void (*)()>(std::__invoke_other, void (*&&)()) () 

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

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

有。

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

(5)source加載deadlock.py腳本

(gdb) source -v deadlock.py 
Type "deadlock" to detect deadlocks. 

(6)輸入deadlock檢測死鎖

(gdb) deadlock 
[Switching to thread 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 to thread 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 to thread 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 <mutex2>) at ../nptl/pthread_mutex_lock.c:78 
[Switching to thread 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 <mutex3>) at ../nptl/pthread_mutex_lock.c:78 
[Switching to thread 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 <mutex1>) at ../nptl/pthread_mutex_lock.c:78 
Found deadlock! 
Thread 2 (LWP 122) is waiting on pthread_mutex_t (0x00007f5587404180) held by Thread 3 (LWP 123) 
Thread 3 (LWP 123) is waiting on pthread_mutex_t (0x00007f55874041c0) held by Thread 4 (LWP 124) 
Thread 4 (LWP 124) is waiting on pthread_mutex_t (0x00007f5587404140) held by Thread 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)的存在。單獨(dú)檢查死鎖的環(huán)比較容易，這里延申下還涉及到簡單環(huán)的概念，因?yàn)檎z測出來的環(huán)可能是個大環(huán)，不是權(quán)值頂點(diǎn)數(shù)最少的環(huán)，如果檢測的環(huán)的頂點(diǎn)數(shù)較多，加大定位的代價，腳本就是檢測的簡單環(huán)，這里涉及到強(qiáng)連通分量算法和簡單環(huán)算法，比較繁瑣就不過多介紹了，腳本來源于facebook的folly庫(這里推薦看下google的abseil和facebook的folly，都是好東西)，代碼較長在文中不好列出，如果有需要的話可以自行下載或者關(guān)注加我好友發(fā)給你。

如何在代碼中檢測死鎖

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

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