Linux C++編程：Shell+GDB死鎖調(diào)試實(shí)戰(zhàn)
在 Linux 環(huán)境下進(jìn)行 C++ 編程時(shí)，多線程為程序帶來(lái)了出色的并發(fā)處理能力，讓程序在應(yīng)對(duì)復(fù)雜任務(wù)時(shí)表現(xiàn)得更加高效。然而，多線程編程并非一路坦途，死鎖問(wèn)題宛如隱匿在暗處的 “殺手”，隨時(shí)可能讓程序陷入僵局。死鎖一旦發(fā)生，程序就如同陷入了一個(gè)無(wú)法掙脫的循環(huán)，各個(gè)線程彼此等待對(duì)方釋放資源，卻又都不愿率先放手，最終致使整個(gè)程序停滯不前。
這種狀況不僅會(huì)使程序的功能無(wú)法正常實(shí)現(xiàn)，還可能對(duì)整個(gè)系統(tǒng)的穩(wěn)定性產(chǎn)生影響。以網(wǎng)絡(luò)服務(wù)器程序?yàn)槔?，倘若發(fā)生死鎖，服務(wù)器可能無(wú)法響應(yīng)新的客戶(hù)端請(qǐng)求，大量用戶(hù)的操作被擱置，后果不堪設(shè)想。對(duì)于 C++ 開(kāi)發(fā)者而言，掌握排查死鎖的技巧至關(guān)重要。今天，我們將深入探討如何借助 Linux 系統(tǒng)下的 Shell 命令和強(qiáng)大的調(diào)試工具 GDB，精準(zhǔn)定位并解決死鎖問(wèn)題，讓你的程序重?zé)ㄉ鷻C(jī)。 接下來(lái)，先讓我們認(rèn)識(shí)一下死鎖究竟是如何產(chǎn)生的。
Part1.死鎖 —— 多線程編程的隱藏殺手
在 Linux C++ 多線程編程的領(lǐng)域中，死鎖就像是一個(gè)隱匿在暗處的殺手，時(shí)刻威脅著程序的正常運(yùn)行。多線程編程賦予了程序強(qiáng)大的并發(fā)處理能力，讓我們能夠充分利用多核處理器的性能，提高程序的執(zhí)行效率。然而，正如陽(yáng)光背后總有陰影，多線程帶來(lái)便利的同時(shí)，也引入了死鎖這個(gè)棘手的問(wèn)題。
想象一下，有一座獨(dú)木橋，只能容納一個(gè)人通過(guò)。這時(shí)，有兩個(gè)人分別從橋的兩端同時(shí)上橋，當(dāng)他們走到橋中間時(shí)，彼此都不愿意后退，就這樣僵持在那里。結(jié)果就是，誰(shuí)也無(wú)法繼續(xù)前進(jìn)，只能一直等待，這就是死鎖在現(xiàn)實(shí)生活中的生動(dòng)寫(xiě)照。在多線程編程里，當(dāng)兩個(gè)或多個(gè)線程相互等待對(duì)方釋放所占用的資源時(shí)，就會(huì)陷入類(lèi)似的僵局，程序無(wú)法繼續(xù)推進(jìn)，就如同這兩個(gè)僵持在獨(dú)木橋上的人一樣。
死鎖的危害不容小覷，尤其是在一些對(duì)實(shí)時(shí)性和穩(wěn)定性要求極高的系統(tǒng)中，比如服務(wù)器程序。在服務(wù)器程序里，線程通常會(huì)處理大量的并發(fā)請(qǐng)求，如果發(fā)生死鎖，部分線程被卡住，無(wú)法及時(shí)響應(yīng)客戶(hù)端的請(qǐng)求，這不僅會(huì)降低系統(tǒng)的吞吐量，嚴(yán)重時(shí)甚至可能導(dǎo)致整個(gè)服務(wù)器癱瘓，影響大量用戶(hù)的正常使用。舉個(gè)簡(jiǎn)單的例子，假設(shè)一個(gè)在線購(gòu)物平臺(tái)的服務(wù)器出現(xiàn)死鎖，那么用戶(hù)可能無(wú)法正常下單、支付，商家也無(wú)法處理訂單，這對(duì)平臺(tái)的運(yùn)營(yíng)和用戶(hù)體驗(yàn)來(lái)說(shuō)，無(wú)疑是一場(chǎng)災(zāi)難。
除了服務(wù)器程序，在一些需要頻繁進(jìn)行資源共享和線程協(xié)作的場(chǎng)景中，死鎖也可能隨時(shí)出現(xiàn)。比如在一個(gè)多線程的文件處理系統(tǒng)中，多個(gè)線程可能需要同時(shí)訪問(wèn)和修改同一個(gè)文件，如果對(duì)文件資源的訪問(wèn)控制不當(dāng)，就很容易引發(fā)死鎖，導(dǎo)致文件處理出錯(cuò)，數(shù)據(jù)丟失等嚴(yán)重后果。
所以，學(xué)會(huì)如何排查和解決死鎖問(wèn)題，對(duì)于 Linux C++ 程序員來(lái)說(shuō)至關(guān)重要。只有掌握了有效的排查方法，我們才能在程序出現(xiàn)死鎖時(shí)，迅速定位問(wèn)題，找到解決方案，讓程序恢復(fù)正常運(yùn)行，保障系統(tǒng)的穩(wěn)定性和可靠性。
Part2.探尋死鎖根源
死鎖的產(chǎn)生并非毫無(wú)緣由，它往往是由多種因素共同作用導(dǎo)致的。在多線程編程中，了解死鎖產(chǎn)生的原因，就如同找到了破解死鎖謎題的鑰匙，能夠幫助我們更好地預(yù)防和排查死鎖問(wèn)題。接下來(lái)，讓我們深入剖析死鎖產(chǎn)生的常見(jiàn)原因，并結(jié)合具體的代碼示例進(jìn)行詳細(xì)解釋。
2.1 加鎖順序不當(dāng)
當(dāng)多個(gè)線程需要獲取多個(gè)鎖時(shí)，如果它們獲取鎖的順序不一致，就如同兩條交叉的軌道，很容易導(dǎo)致死鎖的發(fā)生。假設(shè)現(xiàn)在有兩個(gè)線程thread1和thread2，它們都需要獲取鎖mutex1和mutex2。thread1先獲取mutex1，然后嘗試獲取mutex2；而thread2先獲取mutex2，然后嘗試獲取mutex1。當(dāng)thread1獲取了mutex1之后，thread2獲取了mutex2，此時(shí)兩個(gè)線程就會(huì)像陷入了一個(gè)無(wú)法解開(kāi)的死結(jié)，互相等待對(duì)方釋放自己需要的鎖，從而陷入死鎖。
以下是具體的代碼示例：
#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ù)中獲取鎖的順序不同，這就像是埋下了一顆定時(shí)炸彈，為死鎖的發(fā)生創(chuàng)造了條件。當(dāng)兩個(gè)線程同時(shí)運(yùn)行時(shí)，只要它們獲取鎖的順序出現(xiàn)不一致，就極有可能出現(xiàn)死鎖的情況。
2.2 重復(fù)加鎖
如果一個(gè)線程在已經(jīng)持有某個(gè)鎖的情況下，再次嘗試獲取該鎖，而這個(gè)鎖又不支持重入（即同一個(gè)線程多次獲取同一把鎖），那么就如同自己給自己設(shè)置了障礙，必然會(huì)導(dǎo)致死鎖。例如，在 C++ 中使用std::mutex時(shí)，如果一個(gè)線程在已經(jīng)鎖定了std::mutex的情況下，再次調(diào)用lock方法，就會(huì)陷入死鎖的困境。因?yàn)樗鼰o(wú)法再次獲取已經(jīng)持有的鎖，而其他線程也無(wú)法獲取該鎖，就像一條被堵住的通道，所有線程都無(wú)法繼續(xù)前進(jìn)，從而導(dǎo)致整個(gè)程序陷入停滯。
以下是一個(gè)展示重復(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;
}在這個(gè)例子中，recursiveFunction函數(shù)是遞歸的，每次調(diào)用都會(huì)嘗試獲取myMutex鎖。當(dāng)遞歸調(diào)用時(shí)，由于myMutex不支持重入，第二次獲取鎖時(shí)就會(huì)被阻塞，導(dǎo)致死鎖的發(fā)生。就好像一個(gè)人走進(jìn)了一個(gè)只有一個(gè)入口的迷宮，并且每次進(jìn)入都把入口堵住，自己出不來(lái)，別人也進(jìn)不去。
2.3 加鎖后未解鎖
線程獲取鎖后，正常情況下應(yīng)該在使用完資源后及時(shí)解鎖，以便其他線程能夠獲取鎖并訪問(wèn)資源。然而，如果線程獲取鎖后，由于異常或邏輯錯(cuò)誤未能釋放鎖，就如同一個(gè)人占用了公共資源卻不歸還，其他線程將無(wú)法獲取該鎖，最終導(dǎo)致死鎖的發(fā)生。
下面是一個(gè)線程獲取鎖后因異常未解鎖導(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ù)在獲取鎖后，拋出了一個(gè)異常。由于異常的拋出，導(dǎo)致mutex.unlock()語(yǔ)句沒(méi)有被執(zhí)行，鎖沒(méi)有被釋放。這樣一來(lái)，其他線程如果嘗試獲取這個(gè)鎖，就會(huì)一直等待，從而引發(fā)死鎖。這就好比一個(gè)人借了別人的東西，卻因?yàn)橥话l(fā)狀況忘記歸還，使得其他人無(wú)法使用這個(gè)東西，造成了資源的浪費(fèi)和程序的錯(cuò)誤運(yùn)行。
Part3.搭建死鎖實(shí)驗(yàn)場(chǎng)：模擬死鎖場(chǎng)景
為了更直觀地感受死鎖的現(xiàn)象，我們先來(lái)搭建一個(gè)簡(jiǎn)單的死鎖實(shí)驗(yàn)場(chǎng)景。通過(guò)編寫(xiě)一段 C++ 代碼，故意制造死鎖，以便后續(xù)使用shell和gdb進(jìn)行排查。
3.1 死鎖代碼編寫(xiě)
下面是一段會(huì)引發(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)建了兩個(gè)線程thread1和thread2，以及兩個(gè)互斥鎖mutex1和mutex2。thread1Function函數(shù)中，thread1先獲取mutex1，然后休眠 1 秒，再?lài)L試獲取mutex2；而thread2Function函數(shù)中，thread2先獲取mutex2，同樣休眠 1 秒，再?lài)L試獲取mutex1。這種不同的加鎖順序，就為死鎖的發(fā)生埋下了隱患。
3.2 編譯運(yùn)行代碼
將上述代碼保存為deadlock_example.cpp文件，然后使用g++進(jìn)行編譯：
g++ -g -o deadlock_example deadlock_example.cpp -lpthread這里使用-g選項(xiàng)，是為了在可執(zhí)行文件中加入調(diào)試信息，方便后續(xù)使用gdb進(jìn)行調(diào)試。-lpthread選項(xiàng)則是鏈接線程庫(kù)，因?yàn)槲覀兪褂昧硕嗑€程編程。
編譯完成后，運(yùn)行可執(zhí)行文件：
./deadlock_example運(yùn)行后，你會(huì)發(fā)現(xiàn)程序輸出了 “Thread 1: Acquired mutex1” 和 “Thread 2: Acquired mutex2” 后就陷入了停滯，沒(méi)有繼續(xù)執(zhí)行下去。這就是死鎖發(fā)生的典型癥狀，兩個(gè)線程互相等待對(duì)方釋放鎖，導(dǎo)致程序無(wú)法繼續(xù)推進(jìn)。
Part4.Shell 初登場(chǎng)：進(jìn)程狀態(tài)洞察
在懷疑程序出現(xiàn)死鎖后，我們首先可以借助shell命令來(lái)初步觀察進(jìn)程的狀態(tài)，獲取一些關(guān)鍵信息，為后續(xù)深入排查死鎖提供線索。
4.1 使用ps aux查看進(jìn)程概況
ps aux是一個(gè)非常實(shí)用的shell命令，它可以顯示當(dāng)前系統(tǒng)中所有用戶(hù)的所有進(jìn)程的詳細(xì)信息。通過(guò)這個(gè)命令，我們可以獲取進(jìn)程的 CPU 使用率（% CPU）、內(nèi)存使用情況（% MEM）等關(guān)鍵數(shù)據(jù)。在排查死鎖時(shí)，這些信息能夠幫助我們初步判斷進(jìn)程是否陷入了異常狀態(tài)。
當(dāng)我們執(zhí)行ps aux | grep deadlock_example（假設(shè)我們之前編譯生成的可執(zhí)行文件名為deadlock_example），會(huì)得到類(lèi)似下面的輸出：
user 12345 0.0 0.1 123456 7890 pts/0 S 12:34 0:00 ./deadlock_example在這個(gè)輸出中，%CPU表示進(jìn)程占用的 CPU 百分比，%MEM表示占用內(nèi)存的百分比。如果一個(gè)進(jìn)程陷入死鎖，它通常無(wú)法正常執(zhí)行任務(wù)，CPU 利用率會(huì)非常低，甚至接近于 0。同時(shí)，由于線程被阻塞，進(jìn)程可能會(huì)保持對(duì)某些資源的占用，內(nèi)存使用情況可能不會(huì)有明顯變化，但也不會(huì)釋放已占用的內(nèi)存。所以，當(dāng)我們看到一個(gè)進(jìn)程的 CPU 利用率持續(xù)處于較低水平，且內(nèi)存占用沒(méi)有明顯的波動(dòng)時(shí)，就需要警惕死鎖的可能性了。
4.2 top -Hp深入線程分析
top命令是一個(gè)動(dòng)態(tài)實(shí)時(shí)查看進(jìn)程信息的工具，而top -Hp則是top命令的一個(gè)強(qiáng)大擴(kuò)展，它可以深入查看指定進(jìn)程內(nèi)每個(gè)線程的 CPU 和內(nèi)存占用情況。這對(duì)于我們排查死鎖非常有幫助，因?yàn)樗梨i往往發(fā)生在線程層面，通過(guò)查看線程的狀態(tài)，我們可以更精確地識(shí)別是否存在死鎖的跡象。
當(dāng)我們執(zhí)行top -Hp <pid>（<pid>為ps aux命令查找到的進(jìn)程 ID）時(shí)，會(huì)進(jìn)入一個(gè)實(shí)時(shí)更新的界面，顯示該進(jìn)程內(nèi)各個(gè)線程的詳細(xì)信息，包括線程 ID（PID）、用戶(hù)（USER）、CPU 使用率（% CPU）、內(nèi)存使用情況（% MEM）等。
在正常情況下，我們希望看到各個(gè)線程都在積極地工作，CPU 使用率有一定的波動(dòng)，表明線程在執(zhí)行任務(wù)。然而，如果發(fā)生死鎖，可能會(huì)出現(xiàn)一些異常情況。例如，部分線程的 CPU 使用率一直為 0，處于阻塞狀態(tài)，而同時(shí)又有其他線程在嘗試獲取被阻塞線程持有的資源，導(dǎo)致這些線程也無(wú)法繼續(xù)執(zhí)行，從而出現(xiàn)活躍線程與阻塞線程的矛盾。如果我們觀察到這種情況，就可以進(jìn)一步確認(rèn)死鎖的可能性，為后續(xù)使用gdb進(jìn)行更深入的調(diào)試指明方向。
Part5.GDB 大顯身手：深度調(diào)試定位死鎖
通過(guò)shell命令初步判斷程序可能出現(xiàn)死鎖后，接下來(lái)就需要借助強(qiáng)大的調(diào)試工具gdb進(jìn)行更深入的分析，精準(zhǔn)定位死鎖發(fā)生的位置。
5.1 gdb attach 附加進(jìn)程
gdb的attach命令允許我們將調(diào)試器附加到一個(gè)正在運(yùn)行的進(jìn)程上，就像是給正在行駛的汽車(chē)安裝一個(gè)實(shí)時(shí)監(jiān)測(cè)系統(tǒng)，能夠?qū)M(jìn)程內(nèi)部的運(yùn)行狀態(tài)進(jìn)行詳細(xì)的觀察和調(diào)試。在使用gdb attach之前，我們需要先獲取目標(biāo)進(jìn)程的 ID（PID），這可以通過(guò)前面提到的ps aux命令來(lái)完成。
假設(shè)我們通過(guò)ps aux | grep deadlock_example命令找到了死鎖程序的進(jìn)程 ID 為12345，接下來(lái)就可以使用gdb附加到該進(jìn)程：
gdb -p 12345執(zhí)行上述命令后，gdb會(huì)暫停目標(biāo)進(jìn)程，此時(shí)我們就可以使用gdb的各種調(diào)試命令來(lái)對(duì)進(jìn)程進(jìn)行分析了。需要注意的是，在生產(chǎn)環(huán)境中使用attach命令時(shí)要格外小心，因?yàn)楦郊硬僮骺赡軙?huì)導(dǎo)致進(jìn)程暫停一段時(shí)間，影響其正常運(yùn)行。
5.2 thread apply all bt 查看堆棧
一旦gdb成功附加到進(jìn)程，我們就可以使用thread apply all bt命令來(lái)查看所有線程的堆棧信息。堆棧信息就像是程序運(yùn)行的 “腳印”，記錄了每個(gè)線程在執(zhí)行過(guò)程中調(diào)用的函數(shù)以及函數(shù)的參數(shù)等重要信息。通過(guò)分析這些堆棧信息，我們能夠了解每個(gè)線程的執(zhí)行狀態(tài)，進(jìn)而找到死鎖發(fā)生的代碼行。
在gdb中執(zhí)行thread apply all bt命令后，會(huì)得到類(lèi)似下面的輸出：
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在這個(gè)輸出中，每一行都代表了一個(gè)函數(shù)調(diào)用，#0表示當(dāng)前線程正在執(zhí)行的函數(shù)，從#0往上依次是調(diào)用當(dāng)前函數(shù)的其他函數(shù)。通過(guò)觀察這些堆棧信息，我們可以看到線程1和線程2都卡在了__GI___pthread_mutex_lock函數(shù)處，并且它們等待的互斥鎖不同（0x555555756040和0x555555756050），這就是死鎖發(fā)生的關(guān)鍵線索。結(jié)合代碼行號(hào)（deadlock_example.cpp:9和deadlock_example.cpp:16），我們可以進(jìn)一步定位到死鎖發(fā)生的具體代碼位置。
5.3 info threads 輔助分析
除了thread apply all bt命令，info threads命令也是我們?cè)谡{(diào)試多線程程序時(shí)的得力助手。info threads命令可以列出所有線程的狀態(tài)和索引，方便我們逐個(gè)分析每個(gè)線程的情況。
在gdb中執(zhí)行info threads命令后，會(huì)得到如下輸出：
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在這個(gè)輸出中，Id列表示線程的索引，Target Id包含了線程的 LWP（輕量級(jí)進(jìn)程 ID）和線程的名稱(chēng)，F(xiàn)rame則顯示了線程當(dāng)前所處的函數(shù)位置。通過(guò)info threads命令，我們可以快速了解每個(gè)線程的大致?tīng)顟B(tài)。
如果我們對(duì)某個(gè)線程特別關(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通過(guò)這種方式，我們可以更細(xì)致地分析每個(gè)線程的執(zhí)行情況，進(jìn)一步確定引發(fā)死鎖的代碼部分。
