2. 程式人生 > >Linux執行緒間死鎖分析

Linux執行緒間死鎖分析

阿新 • • 發佈：2018-11-24

死鎖 (deadlocks)： 是指兩個或兩個以上的程序（執行緒）在執行過程中，因爭奪資源而造成的一種互相等待的現象，若無外力作用，它們都將無法推進下去。此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的程序（執行緒）稱為死鎖程序（執行緒）。 由於資源佔用是互斥的，當某個程序提出申請資源後，使得有關程序（執行緒）在無外力協助下，永遠分配不到必需的資源而無法繼續執行，這就產生了一種特殊現象死鎖。

一種交叉持鎖死鎖的情形，此時執行程式中兩個或多個執行緒發生永久堵塞（等待），每個執行緒都在等待被其它執行緒佔用並堵塞了的資源。例如，如果執行緒 1 鎖住了記錄 A 並等待記錄 B，而執行緒 2 鎖住了記錄 B 並等待記錄 A，這樣兩個執行緒就發生了死鎖現象。在計算機系統中 , 如果系統的資源分配策略不當，更常見的可能是程式設計師寫的程式有錯誤等，則會導致程序因競爭資源不當而產生死鎖的現象。

產生死鎖的四個必要條件

（1） 互斥條件：一個資源每次只能被一個程序（執行緒）使用。
（2） 請求與保持條件：一個程序（執行緒）因請求資源而阻塞時，對已獲得的資源保持不放。
（3） 不剝奪條件 : 此程序（執行緒）已獲得的資源，在末使用完之前，不能強行剝奪。
（4） 迴圈等待條件 : 多個程序（執行緒）之間形成一種頭尾相接的迴圈等待資源關係。

圖 1. 交叉持鎖的死鎖示意圖：

註釋：在執行 func2 和 func4 之後，子執行緒 1 獲得了鎖 A，正試圖獲得鎖 B，但是子執行緒 2 此時獲得了鎖 B，正試圖獲得鎖 A，所以子執行緒 1 和子執行緒 2 將沒有辦法得到鎖 A 和鎖 B，因為它們各自被對方佔有，永遠不會釋放，所以發生了死鎖的現象。

使用 pstack 和 gdb 工具對死鎖程式進行分析

pstack 在 Linux 平臺上的簡單介紹

pstack 是 Linux（比如 Red Hat Linux 系統、Ubuntu Linux 系統等）下一個很有用的工具，它的功能是列印輸出此程序的堆疊資訊。可以輸出所有執行緒的呼叫關係棧。

gdb 在 Linux 平臺上的簡單介紹

GDB 是 GNU 開源組織釋出的一個強大的 UNIX 下的程式除錯工具。Linux 系統中包含了 GNU 除錯程式 gdb，它是一個用來除錯 C 和 C++ 程式的偵錯程式。可以使程式開發者在程式執行時觀察程式的內部結構和記憶體的使用情況 .

gdb 所提供的一些主要功能如下所示：

1 執行程式，設定能影響程式執行的引數和環境 ;

2 控制程式在指定的條件下停止執行；

3 當程式停止時，可以檢查程式的狀態；

4 當程式 crash 時，可以檢查 core 檔案；

5 可以修改程式的錯誤，並重新執行程式；

6 可以動態監視程式中變數的值；

7 可以單步執行程式碼，觀察程式的執行狀態。

gdb 程式除錯的物件是可執行檔案或者程序，而不是程式的原始碼檔案。然而，並不是所有的可執行檔案都可以用 gdb 除錯。如果要讓產生的可執行檔案可以用來除錯，需在執行 g++（gcc）指令編譯程式時，加上 -g 引數，指定程式在編譯時包含除錯資訊。除錯資訊包含程式裡的每個變數的型別和在可執行檔案裡的地址對映以及原始碼的行號。gdb 利用這些資訊使原始碼和機器碼相關聯。gdb 的基本命令較多，不做詳細介紹，大家如果需要進一步瞭解，請參見 gdb 手冊。

 #include <unistd.h> 
 #include <pthread.h> 
 #include <string.h> 

 pthread_mutex_t mutex1 = PTHREAD_MUTEX_INITIALIZER; 
 pthread_mutex_t mutex2 = PTHREAD_MUTEX_INITIALIZER; 
 pthread_mutex_t mutex3 = PTHREAD_MUTEX_INITIALIZER; 
 pthread_mutex_t mutex4 = PTHREAD_MUTEX_INITIALIZER; 

 static int sequence1 = 0; 
 static int sequence2 = 0; 

 int func1() 
 { 
    pthread_mutex_lock(&mutex1); 
    ++sequence1; 
    sleep(1); 
    pthread_mutex_lock(&mutex2); 
    ++sequence2; 
    pthread_mutex_unlock(&mutex2); 
    pthread_mutex_unlock(&mutex1); 

    return sequence1; 
 } 

 int func2() 
 { 
    pthread_mutex_lock(&mutex2); 
    ++sequence2; 
    sleep(1); 
    pthread_mutex_lock(&mutex1); 
    ++sequence1; 
    pthread_mutex_unlock(&mutex1); 
    pthread_mutex_unlock(&mutex2); 

    return sequence2; 
 } 

 void* thread1(void* arg) 
 { 
    while (1) 
    { 
        int iRetValue = func1(); 

        if (iRetValue == 100000) 
        { 
            pthread_exit(NULL); 
        } 
    } 
 } 

 void* thread2(void* arg) 
 { 
    while (1) 
    { 
        int iRetValue = func2(); 

        if (iRetValue == 100000) 
        { 
            pthread_exit(NULL); 
        } 
    } 
 } 

 void* thread3(void* arg) 
 { 
    while (1) 
    { 
        sleep(1); 
        char szBuf[128]; 
        memset(szBuf, 0, sizeof(szBuf)); 
        strcpy(szBuf, "thread3"); 
    } 
 } 

 void* thread4(void* arg) 
 { 
    while (1) 
    { 
        sleep(1); 
        char szBuf[128]; 
        memset(szBuf, 0, sizeof(szBuf)); 
        strcpy(szBuf, "thread3"); 
    } 
 } 

 int main() 
 { 
    pthread_t tid[4]; 
    if (pthread_create(&tid[0], NULL, &thread1, NULL) != 0) 
    { 
        _exit(1); 
    } 
    if (pthread_create(&tid[1], NULL, &thread2, NULL) != 0) 
    { 
        _exit(1); 
    } 
    if (pthread_create(&tid[2], NULL, &thread3, NULL) != 0) 
    { 
        _exit(1); 
    } 
    if (pthread_create(&tid[3], NULL, &thread4, NULL) != 0) 
    { 
        _exit(1); 
    } 

    sleep(5); 
    //pthread_cancel(tid[0]); 

    pthread_join(tid[0], NULL); 
    pthread_join(tid[1], NULL); 
    pthread_join(tid[2], NULL); 
    pthread_join(tid[3], NULL); 

    pthread_mutex_destroy(&mutex1); 
    pthread_mutex_destroy(&mutex2); 
    pthread_mutex_destroy(&mutex3); 
    pthread_mutex_destroy(&mutex4); 

    return 0; 
 }

執行編譯命令

g++ -g lock.cpp -o lock -lpthread
-g選項必須有

gdb除錯可執行檔案定位死鎖

a) gdb attach到目標程式

gdb attach 12814

b) 檢視該程序內的執行緒資訊
(gdb) info thread
  Id   Target Id         Frame 
* 1    Thread 0x7f77767ac700 (LWP 12814) "lock" 0x00007f777639998d in pthread_join (threadid=140151057311488, thread_return=0x0)
    at pthread_join.c:90
  2    Thread 0x7f7775fc6700 (LWP 12815) "lock" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
  3    Thread 0x7f77757c5700 (LWP 12816) "lock" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
  4    Thread 0x7f7774fc4700 (LWP 12817) "lock" 0x00007f777609330d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
  5    Thread 0x7f77747c3700 (LWP 12818) "lock" 0x00007f777609330d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
(gdb)
c) 檢視當前執行緒棧空間
(gdb) bt
#0  0x00007f777639998d in pthread_join (threadid=140151057311488, thread_return=0x0) at pthread_join.c:90
#1  0x0000000000400b86 in main () at lock.cpp:110

可以知道主執行緒在等待子執行緒結束

c) 切換到執行緒2，並檢視其堆疊
(gdb) thread 2
[Switching to thread 2 (Thread 0x7f7775fc6700 (LWP 12815))]
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
135     ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory.
(gdb) bt
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007f777639adbd in __GI___pthread_mutex_lock (mutex=0x6020e0 <mutex2>) at ../nptl/pthread_mutex_lock.c:80
#2  0x0000000000400907 in func1 () at lock.cpp:18
#3  0x000000000040099f in thread1 (arg=0x0) at lock.cpp:43
#4  0x00007f77763986ba in start_thread (arg=0x7f7775fc6700) at pthread_create.c:333
#5  0x00007f77760ce41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb)

可以知道執行緒2在lock.cpp的第18行申請mutex2的互斥鎖。並阻塞在這兒了，我們進一步看看這個互斥鎖當前是被誰持有的。

(gdb) p mutex2
$1 = {__data = {__lock = 2, __count = 0, __owner = 12816, __nusers = 1, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, 
      __next = 0x0}}, __size = "\002\000\000\000\000\000\000\000\020\062\000\000\001", '\000' <repeats 26 times>, __align = 2}
(gdb)

從這兒我們可以知道，mutex2這個鎖之前已經被執行緒12816(執行緒3)持有了，我們切換到這個執行緒去看看。

(gdb) thread 3
[Switching to thread 3 (Thread 0x7f77757c5700 (LWP 12816))]
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
135     in ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S
(gdb) bt
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007f777639adbd in __GI___pthread_mutex_lock (mutex=0x6020a0 <mutex1>) at ../nptl/pthread_mutex_lock.c:80
#2  0x0000000000400963 in func2 () at lock.cpp:31
#3  0x00000000004009c6 in thread2 (arg=0x0) at lock.cpp:56
#4  0x00007f77763986ba in start_thread (arg=0x7f77757c5700) at pthread_create.c:333
#5  0x00007f77760ce41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb)

我們發現執行緒3在lock.cpp的第31行嘗試申請mutex1的互斥鎖，並陷入了阻塞。同理我們看看這個互斥鎖的ower是誰

(gdb) p mutex1
$2 = {__data = {__lock = 2, __count = 0, __owner = 12815, __nusers = 1, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, 
      __next = 0x0}}, __size = "\002\000\000\000\000\000\000\000\017\062\000\000\001", '\000' <repeats 26 times>, __align = 2}
(gdb)

OK，mutex1這個互斥鎖被12815(執行緒2)持有了。

因此我們可以得到結論了，執行緒2在等待執行緒3釋放鎖資源，於此同時，執行緒3也在等待執行緒2釋放鎖資源，從而程序出現卡死現象。

相關推薦

Linux執行緒間死鎖分析

死鎖 (deadlocks)： 是指兩個或兩個以上的程序（執行緒）在執行過程中，因爭奪資源而造成的一種互相等待的現象，若無外力作用，它們都將無法推進下去。此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的程序（執行緒）稱為死鎖程序（執行緒）。 由於資源佔用是互斥的，當某個程序提出申

linux執行緒間同步(通訊)的幾種方法——互斥鎖、條件變數、訊號量、讀寫鎖

Linux下提供了多種方式來處理執行緒同步，最常用的是互斥鎖、條件變數、訊號量和讀寫鎖。  下面是思維導圖：  一、互斥鎖（mutex）  　　鎖機制是同一時刻只允許一個執行緒執行一個關鍵部分的程式碼。 1 . 初始化鎖 int pthread_mutex_init(p

Java 多執行緒實現死鎖場景

簡述： 《Java 程式設計思想》  P718 ~ P722 模擬死鎖的場景， 三個人 三根筷子，每個人需要拿到身邊的兩根筷子才能開始吃飯 出現死鎖的場景是，三個人都拿到了右邊的筷子，但是由於筷子都被搶佔，均無法獲得左邊的筷子 Chopstick.java

多執行緒之死鎖

* 死鎖:常見情景之一:同步的巢狀 * @author 羅摩銜那 * */ class Ticketeds implements Runnable { private int num=100; Object obj=new Object(); boolean flag=tr

Java多執行緒： 死鎖

                         

Java多執行緒2.1.多執行緒之死鎖

多執行緒之死鎖 1、鎖物件Lock 雖然我們可以理解同步程式碼塊和同步方法的鎖物件問題，但是我們並沒有直接看到在哪裡加上了鎖，在哪裡釋放了鎖。 為了更清晰的表達如何加鎖和釋放鎖，JDK5以後提

多執行緒：死鎖，樂觀鎖，悲觀鎖

死鎖： 兩個或者多個程序競爭統一資源而形成的僵持的局面，若無外力作用，將無法推進。 本質原因： 1）系統資源有限 2）程序推進順序不合理 死鎖的條件： （1）互斥。某個資源在一段時間只能有一個程序佔有，只有當使用該資源的程序釋放後，其他程序才能佔有該資源。 （2

Java多執行緒12：多執行緒的死鎖

Java執行緒死鎖是一個經典的多執行緒問題，因為不同的執行緒都在等待根本不可能被釋放的鎖，從而導致所有的任務都無法繼續完成。在多執行緒技術中，“死鎖”是必須避免的，因為這會造成執行緒的“假死”。 pac

Thread實現多執行緒、死鎖、同步鎖

1、實現一個類MyThread繼承Thread並重寫run()方法 啟動執行緒方法：例項化MyThread物件，並呼叫start()方法 多個執行緒之間交替執行（搶時間片） 主執行緒（main方法）有優先執行的許可權，但並不絕對 2、實現一個類MyThread實現Runna

從零開始學多執行緒之死鎖(八)

死鎖 每個人手裡都有其他人需要的資源,自己又不會放下手上的資源,這麼一直等待下去,就會發生死鎖. 當一個執行緒永遠佔有一個鎖,而其他執行緒嘗試去獲得這個鎖,那麼它們將永遠被阻塞. 當執行緒A佔有鎖L時,想要獲得鎖M,同時執行緒B持有M,並嘗試得到L,兩個執行緒將永遠等待下去,這種情況是死鎖最簡單的形式(或稱致

Java 執行緒的死鎖問題

Java 執行緒的死鎖問題 1.死鎖 2.解決方法 3.產生死鎖的一個demo 1.死鎖 不同的執行緒分別佔用對方需要的同步資源不放棄，都在等待對方放棄自己需要的同步資源，就形成了執行

Python學習【第24篇】：死鎖，遞迴鎖，訊號量，Event事件，執行緒Queue python併發程式設計之多執行緒2------------死鎖與遞迴鎖，訊號量等

python併發程式設計之多執行緒2------------死鎖與遞迴鎖，訊號量等 一、死鎖現象與遞迴鎖 程序也是有死鎖的 所謂死鎖： 是指兩個或兩個以上

19、多執行緒的死鎖

在多執行緒系列文章第一篇中我們講解到了死鎖的概念。 由上圖可知，死鎖就是多個執行緒都在等待對方釋放自己所需要的鎖。 我們知道機器不像我們人這麼的謙讓，他們都是搶佔資源跑任務的。所以“你若不釋放，我打死也不會釋放。” 下面的例子演示了死鎖。 package com.demo3;

執行緒的死鎖與執行緒的通訊

產生背景 不同執行緒分別佔用對方需要的同步資源部放棄,都在等待對方放棄自己需要的同步資源,形成了執行緒的死鎖 解決方法 專門的演算法,原則 儘量減少同步資源的定義 案例 package com.zyd.thread; public class TestDeadLoc

（十五）java併發程式設計--執行緒的死鎖(deadlock)

執行緒在作業系統使用不同的資源,一般以以下方式使用這些資源。 1）請求一個資源。 2）使用這個資源。 3）釋放資源。 1、什麼是死鎖？ 死鎖的情況是，一些執行緒被阻塞，每個執行緒都擁有一個資源，並且等待另外一個程序以獲取另外的一個資源。 想了想

（十六）java併發程式設計--執行緒的死鎖解決方案(生產者和消費者幾種實現方式)

上一篇中,主要了解了什麼時候死鎖，並且提出死鎖的一個解決方案，多個鎖要按照一定的順序來。 本片主要是利用生產者消費者模式解決執行緒的死鎖。 多執行緒生產者和消費者一個典型的多執行緒程式。一個生產者生產提供消費的東西，但是生產速度和消費速度是不同的。這就需要讓

多執行緒排查死鎖的命令

1、使用JVM自帶的命令 1）首先通過 jps 命令檢視需要檢視的Java程序的vmid，如圖，我們要檢視的程序ThreadState的vmid號是5132； C:\Users\Tom>jps 10716 Jps 6708 RemoteMavenServer 5132 ThreadSt

併發多執行緒之死鎖-----哲學家吃飯問題

該例子說明了4點出現死鎖需要同時滿足的條件： 互斥條件：任務使用的資源至少有一個是不能共享的。這裡，一根chopstick(筷子)一次就只能讓一個philosopher(哲學家)使用。 至少有一個任務它必須持有一個資源且正在等待獲取另一個當前被別的任務持有的

java併發-執行緒飢餓死鎖測試

   執行緒飢餓死鎖      《Java併發程式設計實踐》中對執行緒飢餓死鎖的解釋是這樣的：在使用執行緒池執行任務時，如果任務依賴於其他任務，那麼就可能產生死鎖問題。在單執行緒的Executor中，若果一個任務將另一個任務提交到同一個Executor，並且等待這個被提交的

Linux執行緒間資料交換——管道篇

1 管道     最近在做一個有關AD資料採集的專案，有一個採集執行緒，一個數據處理執行緒。為了實現執行緒之間的資料傳輸，我選擇使用管道。然而管道又分為兩種：PIPE和FIFO。參考資料[7]中對這兩種管道進行了對比：PIPE只能在具有公共祖先的程序之間使用，而FIFO則沒