在 Linux 環(huán)境下進行 C++ 編程時，多線程為程序帶來了出色的并發(fā)處理能力，讓程序在應(yīng)對復(fù)雜任務(wù)時表現(xiàn)得更加高效。然而，多線程編程并非一路坦途，死鎖問題宛如隱匿在暗處的 “殺手”，隨時可能讓程序陷入僵局。死鎖一旦發(fā)生，程序就如同陷入了一個無法掙脫的循環(huán)，各個線程彼此等待對方釋放資源，卻又都不愿率先放手，最終致使整個程序停滯不前。

這種狀況不僅會使程序的功能無法正常實現(xiàn)，還可能對整個系統(tǒng)的穩(wěn)定性產(chǎn)生影響。以網(wǎng)絡(luò)服務(wù)器程序為例，倘若發(fā)生死鎖，服務(wù)器可能無法響應(yīng)新的客戶端請求，大量用戶的操作被擱置，后果不堪設(shè)想。對于 C++ 開發(fā)者而言，掌握排查死鎖的技巧至關(guān)重要。今天，我們將深入探討如何借助 Linux 系統(tǒng)下的 Shell 命令和強大的調(diào)試工具 GDB，精準(zhǔn)定位并解決死鎖問題，讓你的程序重?zé)ㄉ鷻C。 接下來，先讓我們認(rèn)識一下死鎖究竟是如何產(chǎn)生的。

Part1.死鎖 —— 多線程編程的隱藏殺手

在 Linux C++ 多線程編程的領(lǐng)域中，死鎖就像是一個隱匿在暗處的殺手，時刻威脅著程序的正常運行。多線程編程賦予了程序強大的并發(fā)處理能力，讓我們能夠充分利用多核處理器的性能，提高程序的執(zhí)行效率。然而，正如陽光背后總有陰影，多線程帶來便利的同時，也引入了死鎖這個棘手的問題。

想象一下，有一座獨木橋，只能容納一個人通過。這時，有兩個人分別從橋的兩端同時上橋，當(dāng)他們走到橋中間時，彼此都不愿意后退，就這樣僵持在那里。結(jié)果就是，誰也無法繼續(xù)前進，只能一直等待，這就是死鎖在現(xiàn)實生活中的生動寫照。在多線程編程里，當(dāng)兩個或多個線程相互等待對方釋放所占用的資源時，就會陷入類似的僵局，程序無法繼續(xù)推進，就如同這兩個僵持在獨木橋上的人一樣。

死鎖的危害不容小覷，尤其是在一些對實時性和穩(wěn)定性要求極高的系統(tǒng)中，比如服務(wù)器程序。在服務(wù)器程序里，線程通常會處理大量的并發(fā)請求，如果發(fā)生死鎖，部分線程被卡住，無法及時響應(yīng)客戶端的請求，這不僅會降低系統(tǒng)的吞吐量，嚴(yán)重時甚至可能導(dǎo)致整個服務(wù)器癱瘓，影響大量用戶的正常使用。舉個簡單的例子，假設(shè)一個在線購物平臺的服務(wù)器出現(xiàn)死鎖，那么用戶可能無法正常下單、支付，商家也無法處理訂單，這對平臺的運營和用戶體驗來說，無疑是一場災(zāi)難。

除了服務(wù)器程序，在一些需要頻繁進行資源共享和線程協(xié)作的場景中，死鎖也可能隨時出現(xiàn)。比如在一個多線程的文件處理系統(tǒng)中，多個線程可能需要同時訪問和修改同一個文件，如果對文件資源的訪問控制不當(dāng)，就很容易引發(fā)死鎖，導(dǎo)致文件處理出錯，數(shù)據(jù)丟失等嚴(yán)重后果。

所以，學(xué)會如何排查和解決死鎖問題，對于 Linux C++ 程序員來說至關(guān)重要。只有掌握了有效的排查方法，我們才能在程序出現(xiàn)死鎖時，迅速定位問題，找到解決方案，讓程序恢復(fù)正常運行，保障系統(tǒng)的穩(wěn)定性和可靠性。

Part2.探尋死鎖根源

死鎖的產(chǎn)生并非毫無緣由，它往往是由多種因素共同作用導(dǎo)致的。在多線程編程中，了解死鎖產(chǎn)生的原因，就如同找到了破解死鎖謎題的鑰匙，能夠幫助我們更好地預(yù)防和排查死鎖問題。接下來，讓我們深入剖析死鎖產(chǎn)生的常見原因，并結(jié)合具體的代碼示例進行詳細(xì)解釋。

2.1 加鎖順序不當(dāng)

當(dāng)多個線程需要獲取多個鎖時，如果它們獲取鎖的順序不一致，就如同兩條交叉的軌道，很容易導(dǎo)致死鎖的發(fā)生。假設(shè)現(xiàn)在有兩個線程thread1和thread2，它們都需要獲取鎖mutex1和mutex2。thread1先獲取mutex1，然后嘗試獲取mutex2；而thread2先獲取mutex2，然后嘗試獲取mutex1。當(dāng)thread1獲取了mutex1之后，thread2獲取了mutex2，此時兩個線程就會像陷入了一個無法解開的死結(jié)，互相等待對方釋放自己需要的鎖，從而陷入死鎖。

以下是具體的代碼示例：

#include <iostream>
#include <thread>
#include <mutex>

std::mutex mutex1;
std::mutex mutex2;

void thread1Function() {
    mutex1.lock();
    std::cout << "Thread 1: Acquired mutex1" << std::endl;
    std::this_thread::sleep_for(std::chrono::seconds(1));
    mutex2.lock();
    std::cout << "Thread 1: Acquired mutex2" << std::endl;
    mutex2.unlock();
    mutex1.unlock();
}

void thread2Function() {
    mutex2.lock();
    std::cout << "Thread 2: Acquired mutex2" << std::endl;
    std::this_thread::sleep_for(std::chrono::seconds(1));
    mutex1.lock();
    std::cout << "Thread 2: Acquired mutex1" << std::endl;
    mutex1.unlock();
    mutex2.unlock();
}

int main() {
    std::thread thread1(thread1Function);
    std::thread thread2(thread2Function);

    thread1.join();
    thread2.join();

    return 0;
}

在這段代碼中，thread1Function和thread2Function函數(shù)中獲取鎖的順序不同，這就像是埋下了一顆定時炸彈，為死鎖的發(fā)生創(chuàng)造了條件。當(dāng)兩個線程同時運行時，只要它們獲取鎖的順序出現(xiàn)不一致，就極有可能出現(xiàn)死鎖的情況。

2.2 重復(fù)加鎖

如果一個線程在已經(jīng)持有某個鎖的情況下，再次嘗試獲取該鎖，而這個鎖又不支持重入（即同一個線程多次獲取同一把鎖），那么就如同自己給自己設(shè)置了障礙，必然會導(dǎo)致死鎖。例如，在 C++ 中使用std::mutex時，如果一個線程在已經(jīng)鎖定了std::mutex的情況下，再次調(diào)用lock方法，就會陷入死鎖的困境。因為它無法再次獲取已經(jīng)持有的鎖，而其他線程也無法獲取該鎖，就像一條被堵住的通道，所有線程都無法繼續(xù)前進，從而導(dǎo)致整個程序陷入停滯。

以下是一個展示重復(fù)加鎖引發(fā)死鎖的代碼示例：

#include <iostream>
#include <thread>
#include <mutex>

std::mutex myMutex;

void recursiveFunction(int count) {
    myMutex.lock();
    std::cout << "Entering recursiveFunction, count: " << count << std::endl;
    if (count > 0) {
        recursiveFunction(count - 1);
    }
    myMutex.unlock();
    std::cout << "Exiting recursiveFunction, count: " << count << std::endl;
}

int main() {
    std::thread myThread(recursiveFunction, 3);
    myThread.join();
    return 0;
}

在這個例子中，recursiveFunction函數(shù)是遞歸的，每次調(diào)用都會嘗試獲取myMutex鎖。當(dāng)遞歸調(diào)用時，由于myMutex不支持重入，第二次獲取鎖時就會被阻塞，導(dǎo)致死鎖的發(fā)生。就好像一個人走進了一個只有一個入口的迷宮，并且每次進入都把入口堵住，自己出不來，別人也進不去。

2.3 加鎖后未解鎖

線程獲取鎖后，正常情況下應(yīng)該在使用完資源后及時解鎖，以便其他線程能夠獲取鎖并訪問資源。然而，如果線程獲取鎖后，由于異常或邏輯錯誤未能釋放鎖，就如同一個人占用了公共資源卻不歸還，其他線程將無法獲取該鎖，最終導(dǎo)致死鎖的發(fā)生。

下面是一個線程獲取鎖后因異常未解鎖導(dǎo)致死鎖的代碼示例：

#include <iostream>
#include <thread>
#include <mutex>

std::mutex mutex;

void someFunction() {
    mutex.lock();
    std::cout << "Locked the mutex" << std::endl;
    throw std::runtime_error("Something went wrong");
    mutex.unlock();
    std::cout << "Unlocked the mutex" << std::endl;
}

int main() {
    std::thread thread(someFunction);
    thread.join();
    return 0;
}

在這段代碼中，someFunction函數(shù)在獲取鎖后，拋出了一個異常。由于異常的拋出，導(dǎo)致mutex.unlock()語句沒有被執(zhí)行，鎖沒有被釋放。這樣一來，其他線程如果嘗試獲取這個鎖，就會一直等待，從而引發(fā)死鎖。這就好比一個人借了別人的東西，卻因為突發(fā)狀況忘記歸還，使得其他人無法使用這個東西，造成了資源的浪費和程序的錯誤運行。

Part3.搭建死鎖實驗場：模擬死鎖場景

為了更直觀地感受死鎖的現(xiàn)象，我們先來搭建一個簡單的死鎖實驗場景。通過編寫一段 C++ 代碼，故意制造死鎖，以便后續(xù)使用shell和gdb進行排查。

3.1 死鎖代碼編寫

下面是一段會引發(fā)死鎖的 C++ 代碼：

#include <iostream>
#include <thread>
#include <mutex>

std::mutex mutex1;
std::mutex mutex2;

void thread1Function() {
    mutex1.lock();
    std::cout << "Thread 1: Acquired mutex1" << std::endl;
    std::this_thread::sleep_for(std::chrono::seconds(1));
    mutex2.lock();
    std::cout << "Thread 1: Acquired mutex2" << std::endl;
    mutex2.unlock();
    mutex1.unlock();
}

void thread2Function() {
    mutex2.lock();
    std::cout << "Thread 2: Acquired mutex2" << std::endl;
    std::this_thread::sleep_for(std::chrono::seconds(1));
    mutex1.lock();
    std::cout << "Thread 2: Acquired mutex1" << std::endl;
    mutex1.unlock();
    mutex2.unlock();
}

int main() {
    std::thread thread1(thread1Function);
    std::thread thread2(thread2Function);

    thread1.join();
    thread2.join();

    return 0;
}

在這段代碼中，我們創(chuàng)建了兩個線程thread1和thread2，以及兩個互斥鎖mutex1和mutex2。thread1Function函數(shù)中，thread1先獲取mutex1，然后休眠 1 秒，再嘗試獲取mutex2；而thread2Function函數(shù)中，thread2先獲取mutex2，同樣休眠 1 秒，再嘗試獲取mutex1。這種不同的加鎖順序，就為死鎖的發(fā)生埋下了隱患。

3.2 編譯運行代碼

將上述代碼保存為deadlock_example.cpp文件，然后使用g++進行編譯：

g++ -g -o deadlock_example deadlock_example.cpp -lpthread

這里使用-g選項，是為了在可執(zhí)行文件中加入調(diào)試信息，方便后續(xù)使用gdb進行調(diào)試。-lpthread選項則是鏈接線程庫，因為我們使用了多線程編程。

編譯完成后，運行可執(zhí)行文件：

./deadlock_example

運行后，你會發(fā)現(xiàn)程序輸出了 “Thread 1: Acquired mutex1” 和 “Thread 2: Acquired mutex2” 后就陷入了停滯，沒有繼續(xù)執(zhí)行下去。這就是死鎖發(fā)生的典型癥狀，兩個線程互相等待對方釋放鎖，導(dǎo)致程序無法繼續(xù)推進。

Part4.Shell 初登場：進程狀態(tài)洞察

在懷疑程序出現(xiàn)死鎖后，我們首先可以借助shell命令來初步觀察進程的狀態(tài)，獲取一些關(guān)鍵信息，為后續(xù)深入排查死鎖提供線索。

4.1 使用ps aux查看進程概況

ps aux是一個非常實用的shell命令，它可以顯示當(dāng)前系統(tǒng)中所有用戶的所有進程的詳細(xì)信息。通過這個命令，我們可以獲取進程的 CPU 使用率（% CPU）、內(nèi)存使用情況（% MEM）等關(guān)鍵數(shù)據(jù)。在排查死鎖時，這些信息能夠幫助我們初步判斷進程是否陷入了異常狀態(tài)。

當(dāng)我們執(zhí)行ps aux | grep deadlock_example（假設(shè)我們之前編譯生成的可執(zhí)行文件名為deadlock_example），會得到類似下面的輸出：

user     12345  0.0  0.1  123456 7890 pts/0    S    12:34   0:00 ./deadlock_example

在這個輸出中，%CPU表示進程占用的 CPU 百分比，%MEM表示占用內(nèi)存的百分比。如果一個進程陷入死鎖，它通常無法正常執(zhí)行任務(wù)，CPU 利用率會非常低，甚至接近于 0。同時，由于線程被阻塞，進程可能會保持對某些資源的占用，內(nèi)存使用情況可能不會有明顯變化，但也不會釋放已占用的內(nèi)存。所以，當(dāng)我們看到一個進程的 CPU 利用率持續(xù)處于較低水平，且內(nèi)存占用沒有明顯的波動時，就需要警惕死鎖的可能性了。

4.2 top -Hp深入線程分析

top命令是一個動態(tài)實時查看進程信息的工具，而top -Hp則是top命令的一個強大擴展，它可以深入查看指定進程內(nèi)每個線程的 CPU 和內(nèi)存占用情況。這對于我們排查死鎖非常有幫助，因為死鎖往往發(fā)生在線程層面，通過查看線程的狀態(tài)，我們可以更精確地識別是否存在死鎖的跡象。

當(dāng)我們執(zhí)行top -Hp <pid>（<pid>為ps aux命令查找到的進程 ID）時，會進入一個實時更新的界面，顯示該進程內(nèi)各個線程的詳細(xì)信息，包括線程 ID（PID）、用戶（USER）、CPU 使用率（% CPU）、內(nèi)存使用情況（% MEM）等。

在正常情況下，我們希望看到各個線程都在積極地工作，CPU 使用率有一定的波動，表明線程在執(zhí)行任務(wù)。然而，如果發(fā)生死鎖，可能會出現(xiàn)一些異常情況。例如，部分線程的 CPU 使用率一直為 0，處于阻塞狀態(tài)，而同時又有其他線程在嘗試獲取被阻塞線程持有的資源，導(dǎo)致這些線程也無法繼續(xù)執(zhí)行，從而出現(xiàn)活躍線程與阻塞線程的矛盾。如果我們觀察到這種情況，就可以進一步確認(rèn)死鎖的可能性，為后續(xù)使用gdb進行更深入的調(diào)試指明方向。

Part5.GDB 大顯身手：深度調(diào)試定位死鎖

通過shell命令初步判斷程序可能出現(xiàn)死鎖后，接下來就需要借助強大的調(diào)試工具gdb進行更深入的分析，精準(zhǔn)定位死鎖發(fā)生的位置。

5.1 gdb attach 附加進程

gdb的attach命令允許我們將調(diào)試器附加到一個正在運行的進程上，就像是給正在行駛的汽車安裝一個實時監(jiān)測系統(tǒng)，能夠?qū)M程內(nèi)部的運行狀態(tài)進行詳細(xì)的觀察和調(diào)試。在使用gdb attach之前，我們需要先獲取目標(biāo)進程的 ID（PID），這可以通過前面提到的ps aux命令來完成。

假設(shè)我們通過ps aux | grep deadlock_example命令找到了死鎖程序的進程 ID 為12345，接下來就可以使用gdb附加到該進程：

gdb -p 12345

執(zhí)行上述命令后，gdb會暫停目標(biāo)進程，此時我們就可以使用gdb的各種調(diào)試命令來對進程進行分析了。需要注意的是，在生產(chǎn)環(huán)境中使用attach命令時要格外小心，因為附加操作可能會導(dǎo)致進程暫停一段時間，影響其正常運行。

5.2 thread apply all bt 查看堆棧

一旦gdb成功附加到進程，我們就可以使用thread apply all bt命令來查看所有線程的堆棧信息。堆棧信息就像是程序運行的 “腳印”，記錄了每個線程在執(zhí)行過程中調(diào)用的函數(shù)以及函數(shù)的參數(shù)等重要信息。通過分析這些堆棧信息，我們能夠了解每個線程的執(zhí)行狀態(tài)，進而找到死鎖發(fā)生的代碼行。

在gdb中執(zhí)行thread apply all bt命令后，會得到類似下面的輸出：

Thread 1 (Thread 0x7ffff7fde700 (LWP 12345)):
#0  0x00007ffff7b31b97 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007ffff7b2db98 in _L_lock_898 () from /lib64/libpthread.so.0
#2  0x00007ffff7b2d9d0 in __GI___pthread_mutex_lock (mutex=0x555555756040) at pthread_mutex_lock.c:64
#3  0x00005555555556d2 in thread1Function () at deadlock_example.cpp:9
#4  0x00007ffff7b27a0d in start_thread (arg=0x7ffff7fde700) at pthread_create.c:311
#5  0x00007ffff7a0c41f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 2 (Thread 0x7ffff77dd700 (LWP 12346)):
#0  0x00007ffff7b31b97 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007ffff7b2db98 in _L_lock_898 () from /lib64/libpthread.so.0
#2  0x00007ffff7b2d9d0 in __GI___pthread_mutex_lock (mutex=0x555555756050) at pthread_mutex_lock.c:64
#3  0x0000555555555772 in thread2Function () at deadlock_example.cpp:16
#4  0x00007ffff7b27a0d in start_thread (arg=0x7ffff77dd700) at pthread_create.c:311
#5  0x00007ffff7a0c41f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

在這個輸出中，每一行都代表了一個函數(shù)調(diào)用，#0表示當(dāng)前線程正在執(zhí)行的函數(shù)，從#0往上依次是調(diào)用當(dāng)前函數(shù)的其他函數(shù)。通過觀察這些堆棧信息，我們可以看到線程1和線程2都卡在了__GI___pthread_mutex_lock函數(shù)處，并且它們等待的互斥鎖不同（0x555555756040和0x555555756050），這就是死鎖發(fā)生的關(guān)鍵線索。結(jié)合代碼行號（deadlock_example.cpp:9和deadlock_example.cpp:16），我們可以進一步定位到死鎖發(fā)生的具體代碼位置。

5.3 info threads 輔助分析

除了thread apply all bt命令，info threads命令也是我們在調(diào)試多線程程序時的得力助手。info threads命令可以列出所有線程的狀態(tài)和索引，方便我們逐個分析每個線程的情況。

在gdb中執(zhí)行info threads命令后，會得到如下輸出：

Id   Target Id         Frame
  2    Thread 0x7ffff77dd700 (LWP 12346) "deadlock_example" 0x00007ffff7b31b97 in __lll_lock_wait () from /lib64/libpthread.so.0
* 1    Thread 0x7ffff7fde700 (LWP 12345) "deadlock_example" 0x00007ffff7b31b97 in __lll_lock_wait () from /lib64/libpthread.so.0

在這個輸出中，Id列表示線程的索引，Target Id包含了線程的 LWP（輕量級進程 ID）和線程的名稱，F(xiàn)rame則顯示了線程當(dāng)前所處的函數(shù)位置。通過info threads命令，我們可以快速了解每個線程的大致狀態(tài)。

如果我們對某個線程特別關(guān)注，可以使用thread <線程ID>命令切換到該線程，然后再使用bt命令查看其具體的堆棧信息。例如，要查看線程2的堆棧信息，可以執(zhí)行以下操作：

(gdb) thread 2
[Switching to thread 2 (Thread 0x7ffff77dd700 (LWP 12346))]
#0  0x00007ffff7b31b97 in __lll_lock_wait () from /lib64/libpthread.so.0
(gdb) bt
#0  0x00007ffff7b31b97 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007ffff7b2db98 in _L_lock_898 () from /lib64/libpthread.so.0
#2  0x00007ffff7b2d9d0 in __GI___pthread_mutex_lock (mutex=0x555555756050) at pthread_mutex_lock.c:64
#3  0x0000555555555772 in thread2Function () at deadlock_example.cpp:16
#4  0x00007ffff7b27a0d in start_thread (arg=0x7ffff77dd700) at pthread_create.c:311
#5  0x00007ffff7a0c41f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

通過這種方式，我們可以更細(xì)致地分析每個線程的執(zhí)行情況，進一步確定引發(fā)死鎖的代碼部分。