據說再高的高手在寫多線程程序的時候都難確保不會產生死鎖，死鎖的調試也就成為一個比較常見的問題，假設有下面這樣一個問題：
一個正在生產環境下運行的進程死鎖了，或者你只是在跑一個程序，並沒有在調試器里面打開它，然后發現沒有響應，日志輸出也停止了。由於你是一個有經驗的程序員，會想到“我剛剛加上了新的鎖策略，不一定穩定，這可能是死鎖了“。但是你不想就這么殺掉進程，因為多線程的 bug 不容易重現，遇上一次死鎖可能要憑運氣，錯過了這次，它下次死鎖可能會出現在你演示給老板看的時候……怎么辦？
對於這樣的問題可以借助Core Dump來調試。
什么是Core Dump?
Core的意思是內存, Dump的意思是扔出來, 堆出來.開發和使用Unix程序時, 有時程序莫名其妙的down了, 卻沒有任何的提示(有時候會提示core dumped). 這時候可以查看一下有沒有形如core.進程號的文件生成運行過程中發生異常, 程序異常退出時, 由操作系統把程序當前的內存狀況存儲在一個core文件中, 叫core dump.這個文件便是操作系統把程序down掉時的內存內容扔出來生成的, 它可以做為調試程序的參考.
Core Dump又叫核心轉儲, 當程序沒有core文件生成怎么辦呢?
有時候程序down了, 但是core文件卻沒有生成，core文件的生成跟你當前系統的環境設置有關系, 可以用下面的語句設置一下, 然后再運行程序便會生成core文件.
ulimit -c unlimited
core文件生成的位置一般於運行程序的路徑相同, 文件名一般為core.進程號，在我的ubuntu12.04lts下生產的文件名為core。
介紹了core dump之后，來看看如何在多線程調試中使用core dump。
使用 kill 命令產生 core dump文件：
kill -11 pid
這不還是殺掉進程嘛？沒錯，但是你用信號11殺掉它，會讓進程產生一個 Segmentation Fault，從而（如果你沒禁用 core dump 的話），導致一個 core dump。隨后你得到一個 core 文件，里面包含了死鎖的時候，進程的內存鏡像，也就包括了正在糾結纏綿，生離死別從而產生死鎖的那兩個，沒准是幾個，線程們的，棧。
現在知道該怎么辦了吧？用 gdb 打開這個 core 文件，然后
thread apply all bt
gdb 會打出所有線程的棧，如果你發現有那么幾個棧停在 pthread_wait 或者類似調用上，大致就可以得出結論：就是它們幾個兒女情長，耽誤了整個進程。
下面我來舉一個簡單的例子（為了代碼盡量簡單，使用了C++11的thread library）
#include <iostream> #include <thread> #include <mutex> #include <chrono> using namespace std; mutex m1,m2; void func_2() { m2.lock(); cout<< "about to dead_lock"<<endl; m1.lock(); } void func_1() { m1.lock(); chrono::milliseconds dura( 1000 );// delay to trigger dead_lock this_thread::sleep_for( dura ); m2.lock(); } int main() { thread t1(func_1); thread t2(func_2); t1.join(); t2.join(); return 0; }
編譯代碼
$> g++ -Wall -std=c++11 dead_lock_demo.cpp -o dead_lock_demo -g -pthread
運行程序，發現程序打印出“about to dead_lock” 就不動了，現在我們使用gdb來調試。注意gdb的版本要高於7.0，之前使用過gdb6.3調試多線程是不行的。
在這之前需要先產生core dump文件：
$> ps -aux | grep dead_lock_demo
找出 dead_lock_demo 線程號，然后：
$> kill -11 pid
此時會生成core dump 文件，在我的系統上名字就是 core
然后調試：
$> gdb dead_lock_demo core
$> thread apply all bt
下面來看一下實際的過程：
從上圖可以看出兩個線程都阻塞在wait上，而且還給出了在哪一行代碼中，很容易就定位到產生死鎖的位置。