多線程編程是現(xiàn)代軟件開發(fā)中的一項重要技術(shù)，但隨之而來的挑戰(zhàn)之一是多線程死鎖。多線程死鎖是程序中的一種常見問題，它會導(dǎo)致線程相互等待，陷入無法繼續(xù)執(zhí)行的狀態(tài)。這里，我們將探討多線程死鎖的概念、原理，同時我們通過一個例子來介紹如何使用GDB（GNU Debugger）這一工具來排查和解決多線程死鎖問題。

多線程死鎖的概念

多線程死鎖是多線程編程中的一種關(guān)鍵問題。它發(fā)生在多個線程試圖獲取一組資源（通常是鎖或資源對象）時，導(dǎo)致彼此相互等待的情況。具體來說，當(dāng)線程1持有資源A并等待資源B，而線程2持有資源B并等待資源A時，就可能發(fā)生死鎖。

多線程死鎖原理

為了更好地理解多線程死鎖的原理，讓我們考慮一個簡單的示例。假設(shè)有兩個資源A和B，以及兩個線程（Thread 1和Thread 2）。線程1需要獲取資源A和B，線程2需要獲取資源B和A。如果線程1獲取了資源A，而線程2獲取了資源B，它們都無法繼續(xù)，因為它們都需要對方持有的資源才能繼續(xù)。這就是典型的死鎖情況。

多線程死鎖通常發(fā)生在以下情況下：

• 線程同時持有一個資源并等待另一個資源。
• 資源分配不當(dāng)，線程沒有按照相同的順序獲取資源。

多線程死鎖之所以會發(fā)生，是因為線程之間的相互依賴和等待。當(dāng)多個線程需要共享資源時，它們可能會按不同的順序獲取這些資源，導(dǎo)致資源互斥問題，最終引發(fā)死鎖。

排查多線程死鎖

GDB是一個強大的調(diào)試工具，可以用來排查多線程死鎖問題。下面通過一個例子來說下如何使用gdb調(diào)試死鎖問題，這也是前段時間我碰鎖問題新學(xué)到的技能。

簡單的代碼如下：

#include <stdio.h>
#include <pthread.h>
#include <stdlib.h>
#include <unistd.h>
#include <time.h>

pthread_mutex_t mutex1 = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_t mutex2 = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t exit_condition = PTHREAD_COND_INITIALIZER;
int should_exit = 0;

void *thread1_function(void *arg) {
    while (1) {
        printf("Thread 1: Attempting to acquire mutex1...\n");
        pthread_mutex_lock(&mutex1);
        printf("Thread 1: Acquired mutex1.\n");

        printf("Thread 1: Attempting to acquire mutex2...\n");
        pthread_mutex_lock(&mutex2);
        printf("Thread 1: Acquired mutex2.\n");

        // 在此處檢查是否應(yīng)該退出
        if (should_exit) {
            pthread_mutex_unlock(&mutex2);
            pthread_mutex_unlock(&mutex1);
      break;
        }

        pthread_mutex_unlock(&mutex1);
        pthread_mutex_unlock(&mutex2);
    }
    printf("Thread 1 exit done!\n");
    pthread_exit(NULL);
}

void *thread2_function(void *arg) {
    sleep(5); // 讓線程2休眠10秒鐘

    printf("Thread 2: Attempting to acquire mutex2...\n");
    pthread_mutex_lock(&mutex2);
    printf("Thread 2: Acquired mutex2.\n");

    printf("Thread 2: Notifying Thread 1 to exit...\n");
    should_exit = 1;
    pthread_cond_signal(&exit_condition);

    //通過不釋放該鎖制造死鎖
    pthread_mutex_unlock(&mutex2);

    printf("Thread 2 exit done!\n");
    //exit執(zhí)行后不會再執(zhí)行該函數(shù)后面部分
    pthread_exit(NULL);
}

int main() {
    pthread_t thread1, thread2;

    pthread_create(&thread1, NULL, thread1_function, NULL);
    pthread_create(&thread2, NULL, thread2_function, NULL);

    pthread_join(thread1, NULL);
    pthread_join(thread2, NULL);

    return 0;
}

代碼很簡單，通過創(chuàng)建兩個線程，線程1睡眠5s為mutex2加鎖并通知線程1進行退出，之后線程2退出，線程1是個while循環(huán)，不停的對mutex1進行加解鎖，并加鎖后檢測是否退出，退出則對mutex2進行加鎖打印，然后釋放mutex1、mutex2進行退出。

使用：gcc thread.c -g -lpthread -o thread編譯，因為要gdb調(diào)試所以需要帶上-g參數(shù)，正?，F(xiàn)象會執(zhí)行結(jié)束打印如下：

現(xiàn)在我們屏蔽掉線程2釋放mutex2進行死鎖調(diào)試：

void *thread2_function(void *arg) {
    sleep(5); // 讓線程2休眠10秒鐘

    printf("Thread 2: Attempting to acquire mutex2...\n");
    pthread_mutex_lock(&mutex2);
    printf("Thread 2: Acquired mutex2.\n");

    printf("Thread 2: Notifying Thread 1 to exit...\n");
    should_exit = 1;
    pthread_cond_signal(&exit_condition);

    //通過不釋放該鎖制造死鎖
    //pthread_mutex_unlock(&mutex2);

    printf("Thread 2 exit done!\n");
    //exit執(zhí)行后不會再執(zhí)行該函數(shù)后面部分
    pthread_exit(NULL);
}

實際環(huán)境中我們并不知道死鎖發(fā)生，所以我們通過gdb先運行一次直到程序無法正常退出時，執(zhí)行bt查看堆棧：

這里因為加了打印所以很快可以看到mutex2上鎖那里卡住，實際環(huán)境會有很多線程運行，我們并不直到哪里會有問題，此時只能通過bt查看堆棧我們發(fā)現(xiàn)卡在函數(shù)__futex_abstimed_wait_common64，運行到./nptl/futex-internal.c文件第57行。

這里我們只需要知道該函數(shù)__futex_abstimed_wait_common64是Linux內(nèi)核中用于處理互斥鎖等待超時的一個內(nèi)部函數(shù)即可。

此時可以斷定代碼存在死鎖問題了，我們繼續(xù)排查。

我們繼續(xù)看bt信息，發(fā)現(xiàn)該等待是從#4  0x00005555555553c8 in main () at thread.c:59調(diào)入的，因為前面是#4，所以使用f 4進入該函數(shù)。

我們發(fā)現(xiàn)是main里調(diào)入，同時在執(zhí)行thread1的pthread_join，所以前面的__futex_abstimed_wait_common64并不是我們真正要找的問題，其實thread1已經(jīng)來到了join的位置，等待結(jié)束了。我們繼續(xù)執(zhí)行thread apply all bt把所有線程堆棧打出來看下：

根據(jù)前面分析thread 1已經(jīng)正常退出了，我們這里看到thread 2卡在futex_wait，根據(jù)上下文非常明顯是在等待futex lock，再往下看我們發(fā)現(xiàn)鎖mutex2，這里就是thread2在等待mutex2，那么mutex2被誰lock住沒釋放呢？我們通過p mutex2來查看owner即可知道該鎖被誰擁有。

這里有個問題，是因為該代碼恰巧thread 1退出等待join了，所以這里的23890是個內(nèi)核線程，在持有著mutex2，實際環(huán)境中我們會看到owner大概會是info threads中的LWP，于是就可以定位到該鎖被誰持有沒有釋放了，再分析代碼即可。

我把thread 1再改下，不直接退出而是一直while(1)的形態(tài)來測試，此時再通過上述來查找mutex2被誰持有即可直觀看到：