多線程中如何使用gdb精確定位死鎖問題
在多線程開發(fā)過程中很多人應該都會遇到死鎖問題，死鎖問題也是面試過程中經(jīng)常被問到的問題，這里介紹在c++中如何使用gdb+python腳本調(diào)試死鎖問題，以及如何在程序運行過程中檢測死鎖。
首先介紹什么是死鎖，看下維基百科中的定義：
死鎖（英語：Deadlock），又譯為死結(jié)，計算機科學名詞。當兩個以上的運算單元，雙方都在等待對方停止運行，以獲取系統(tǒng)資源，但是沒有一方提前退出時，就稱為死鎖。在多任務操作系統(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)死鎖的大部分原因都是因為多個線程中加鎖的順序不一致導致的，看如下這段會出現(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占用。
三個線程誰也不讓著誰，導致了死鎖。
傳統(tǒng)gdb調(diào)試多線程死鎖方法
（1）attach id關聯(lián)到發(fā)生死鎖的進程id
(gdb) attach 109Attaching to process 109[][][][]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:8989 pthread_join_common.c: No such file or directory.
（2）info threads查看當前進程中所有線程的信息，也可以查看到部分堆棧信息
(gdb) info threadsId 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:892 Thread 0x7fa33ec80700 (LWP 110) "out" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:1353 Thread 0x7fa33e470700 (LWP 111) "out" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:1354 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[]135 ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory.
（4）bt查看當前線程堆棧信息
(gdb) bt0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:1351 0x00007fa33f9ea023 in __GI___pthread_mutex_lock (mutex=0x7fa340204180 <mutex2>) at ../nptl/pthread_mutex_lock.c:782 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卻可以打印出被哪個線程持有，之后再重復步驟3和4，就可以確定哪幾個線程以及哪幾把鎖發(fā)生的死鎖，而針對于std::mutex，gdb沒法打印具體的mutex的信息，不能看出來mutex是被哪個線程持有，只能依次進入線程查看堆棧信息。
然而針對于c++11的std::mutex有沒有什么好辦法定位死鎖呢？
有。
可以算作第五步，繼續(xù)：
（5）source加載deadlock.py腳本
(gdb) source -v deadlock.pyType "deadlock" to detect deadlocks.
（6）輸入deadlock檢測死鎖
(gdb) deadlock[]135 in ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S[]135 in ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S[]135 in ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S[][]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)，就可以查看相應線程的堆棧信息查看到哪幾把鎖正在等待。
死鎖檢測腳本的原理：
還是拿上面圖舉例：
線程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，都是好東西），代碼較長在文中不好列出，如果有需要的話可以自行下載或者關注加我好友發(fā)給你。
如何在代碼中檢測死鎖
和上面介紹的原理相同，在線程加鎖過程中始終維護一張圖，記錄線程之間的關系
A->B, B->C, C->A
然后在圖中檢出簡單環(huán)，找到哪幾個線程處在死鎖狀態(tài)，做好狀態(tài)記錄，就可以完備確認是具體是哪幾個線程哪幾把鎖發(fā)生的死鎖，代碼同樣比較長，可以關注加我好友哦~
REVIEW
免責聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
