在多線程開發過程當中不少人應該都會遇到死鎖問題，死鎖問題也是面試過程當中常常被問到的問題，這裏介紹在c++中如何使用gdb+python腳本調試死鎖問題，以及如何在程序運行過程當中檢測死鎖。python
首先介紹什麼是死鎖，看下維基百科中的定義：linux
死鎖（英語：Deadlock），又譯爲死結，計算機科學名詞。當兩個以上的運算單元，雙方都在等待對方中止運行，以獲取系統資源，可是沒有一方提早退出時，就稱爲死鎖。在多任務操做系統中，操做系統爲了協調不一樣行程，可否獲取系統資源時，爲了讓系統運做，必需要解決這個問題。c++
維基百科中介紹的是進程死鎖，多線程中也會產生死鎖，同樣的道理，這裏不做過多介紹。面試
死鎖的四個條件算法
禁止搶佔（no preemption）：系統資源不能被強制從一個進程（線程）中退出，已經得到的資源在未使用完以前不能被搶佔。shell
等待和保持（hold and wait）：一個進程（線程）因請求資源阻塞時，對已得到的資源保持不放。設計模式
互斥（mutual exclusion）：資源只能同時分配給一個進程（線程），沒法多個進程（線程）共享。bash
循環等待（circular waiting）：一系列進程（線程）互相持有其餘進程（線程）所須要的資源。微信
只有同時知足以上四個條件，纔會產生死鎖，想要消除死鎖只須要破壞其中任意一個條件便可。多線程
如何調試多線程死鎖問題
多線程出現死鎖的大部分緣由都是由於多個線程中加鎖的順序不一致致使的，看以下這段會出現死鎖的代碼：
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已經持有mutex1，想要申請mutex2，拿到mutex2後才能夠釋放mutex1和mutex2，而此時mutex2被線程B佔用。
線程B已經持有mutex2，想要申請mutex3，拿到mutex3後才能夠釋放mutex2和mutex3，而此時mutex3被線程C佔用。
線程C已經持有mutex3，想要申請mutex1，拿到mutex1後才能夠釋放mutex3和mutex1，而此時mutex1被線程A佔用。
三個線程誰也不讓着誰，致使了死鎖。
傳統gdb調試多線程死鎖方法
（1）attach id關聯到發生死鎖的進程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
這裏能夠看到二、三、4線程都在lock_wait狀態，基本上能夠看出或許是否問題，可是不必定，這裏須要屢次info threads看看這些線程有沒有什麼變化，屢次若是都沒有變化那基本上就是發生了死鎖。
（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 (*&&)()) ()
調試到這裏基本已經差很少了，針對pthread_mutex_t卻能夠打印出被哪一個線程持有，以後再重複步驟3和4，就能夠肯定哪幾個線程以及哪幾把鎖發生的死鎖，而針對於std::mutex，gdb無法打印具體的mutex的信息，不能看出來mutex是被哪一個線程持有，只能依次進入線程查看堆棧信息。
然而針對於c++11的std::mutex有沒有什麼好辦法定位死鎖呢？
有。
能夠算做第五步，繼續：
（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)
直接看結果，腳本檢測出了死鎖，並指明瞭具體的哪幾個線程形成的死鎖，根據輸出信息能夠明顯看出來線程鎖造成的環形成了死鎖，找到了具體是哪幾個線程構成的死鎖環，就能夠查看相應線程的堆棧信息查看到哪幾把鎖正在等待。
死鎖檢測腳本的原理：
仍是拿上面圖舉例：
線程A已經持有mutex1，想要申請mutex2，拿到mutex2後才能夠釋放mutex1和mutex2，而此時mutex2被線程B佔用。
線程B已經持有mutex2，想要申請mutex3，拿到mutex3後才能夠釋放mutex2和mutex3，而此時mutex3被線程C佔用。
線程C已經持有mutex3，想要申請mutex1，拿到mutex1後才能夠釋放mutex3和mutex1，而此時mutex1被線程A佔用。
如圖，三個線程造成了一個環，死鎖檢測就是檢查線程之間是否有環的存在。單獨檢查死鎖的環比較容易，這裏延申下還涉及到簡單環的概念，由於正常檢測出來的環多是個大環，不是權值頂點數最少的環，若是檢測的環的頂點數較多，加大定位的代價，腳本就是檢測的簡單環，這裏涉及到強連通份量算法和簡單環算法，比較繁瑣就不過多介紹了，腳原本源於facebook的folly庫（這裏推薦看下google的abseil和facebook的folly，都是好東西），代碼較長在文中很差列出，若是有須要的話能夠自行下載或者關注加我好友發給你。
如何在代碼中檢測死鎖
和上面介紹的原理相同，在線程加鎖過程當中始終維護一張圖，記錄線程之間的關係
A->B, B->C, C->A
而後在圖中檢出簡單環，找到哪幾個線程處在死鎖狀態，作好狀態記錄，就能夠完備確認是具體是哪幾個線程哪幾把鎖發生的死鎖，代碼一樣比較長，能夠關注加我好友哦~
REVIEW
本文分享自微信公衆號 - 程序喵大人（dmjjzl1）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。