Linux 上分析死鎖的最簡單方法
簡介
死鎖 (deallocks): 是指兩個或兩個以上的程式(執行緒)在執行過程中,因爭奪資源而造成的一種互相等待的現象,若無外力作用,它們都將無法推進下去。此時稱系統處於死鎖狀態或系統產生了死鎖,這些永遠在互相等待的程式(執行緒)稱為死鎖程式(執行緒)。 由於資源佔用是互斥的,當某個程式提出申請資源後,使得有關程式(執行緒)在無外力協助下,永遠分配不到必需的資源而無法繼續執行,這就產生了一種特殊現象死鎖。
一種交叉持鎖死鎖的情形,此時執行程式中兩個或多個執行緒發生永久堵塞(等待),每個執行緒都在等待被其它執行緒佔用並堵塞了的資源。例如,如果執行緒 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 手冊。
清單 1. 測試程式
#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; }
清單 2. 編譯測試程式
[dyu@xilinuxbldsrv purify]$ g++ -g lock.cpp -o lock -lpthread
清單 3. 查詢測試程式的程式號
[dyu@xilinuxbldsrv purify]$ ps -ef|grep lock dyu 6721 5751 0 15:21 pts/3 00:00:00 ./lock
清單 4. 對死鎖程式第一次執行 pstack(pstack –程式號)的輸出結果
[dyu@xilinuxbldsrv purify]$ pstack 6721 Thread 5 (Thread 0x41e37940 (LWP 6722)): #0 0x0000003d1a80d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x0000003d1a808e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x0000003d1a808cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0000000000400a9b in func1() () #4 0x0000000000400ad7 in thread1(void*) () #5 0x0000003d1a80673d in start_thread () from /lib64/libpthread.so.0 #6 0x0000003d19cd40cd in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x42838940 (LWP 6723)): #0 0x0000003d1a80d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x0000003d1a808e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x0000003d1a808cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0000000000400a17 in func2() () #4 0x0000000000400a53 in thread2(void*) () #5 0x0000003d1a80673d in start_thread () from /lib64/libpthread.so.0 #6 0x0000003d19cd40cd in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x43239940 (LWP 6724)): #0 0x0000003d19c9a541 in nanosleep () from /lib64/libc.so.6 #1 0x0000003d19c9a364 in sleep () from /lib64/libc.so.6 #2 0x00000000004009bc in thread3(void*) () #3 0x0000003d1a80673d in start_thread () from /lib64/libpthread.so.0 #4 0x0000003d19cd40cd in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x43c3a940 (LWP 6725)): #0 0x0000003d19c9a541 in nanosleep () from /lib64/libc.so.6 #1 0x0000003d19c9a364 in sleep () from /lib64/libc.so.6 #2 0x0000000000400976 in thread4(void*) () #3 0x0000003d1a80673d in start_thread () from /lib64/libpthread.so.0 #4 0x0000003d19cd40cd in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x2b984ecabd90 (LWP 6721)): #0 0x0000003d1a807b35 in pthread_join () from /lib64/libpthread.so.0 #1 0x0000000000400900 in main ()
清單 5. 對死鎖程式第二次執行 pstack(pstack –程式號)的輸出結果
[dyu@xilinuxbldsrv purify]$ pstack 6721 Thread 5 (Thread 0x40bd6940 (LWP 6722)): #0 0x0000003d1a80d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x0000003d1a808e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x0000003d1a808cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0000000000400a87 in func1() () #4 0x0000000000400ac3 in thread1(void*) () #5 0x0000003d1a80673d in start_thread () from /lib64/libpthread.so.0 #6 0x0000003d19cd40cd in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x415d7940 (LWP 6723)): #0 0x0000003d1a80d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x0000003d1a808e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x0000003d1a808cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0000000000400a03 in func2() () #4 0x0000000000400a3f in thread2(void*) () #5 0x0000003d1a80673d in start_thread () from /lib64/libpthread.so.0 #6 0x0000003d19cd40cd in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x41fd8940 (LWP 6724)): #0 0x0000003d19c7aec2 in memset () from /lib64/libc.so.6 #1 0x00000000004009be in thread3(void*) () #2 0x0000003d1a80673d in start_thread () from /lib64/libpthread.so.0 #3 0x0000003d19cd40cd in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x429d9940 (LWP 6725)): #0 0x0000003d19c7ae0d in memset () from /lib64/libc.so.6 #1 0x0000000000400982 in thread4(void*) () #2 0x0000003d1a80673d in start_thread () from /lib64/libpthread.so.0 #3 0x0000003d19cd40cd in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x2af906fd9d90 (LWP 6721)): #0 0x0000003d1a807b35 in pthread_join () from /lib64/libpthread.so.0 #1 0x0000000000400900 in main ()
連續多次檢視這個程式的函式呼叫關係堆疊進行分析:當程式吊死時,多次使用 pstack 檢視程式的函式呼叫堆疊,死鎖執行緒將一直處於等鎖的狀態,對比多次的函式呼叫堆疊輸出結果,確定哪兩個執行緒(或者幾個執行緒)一直沒有變化且一直處於等鎖的狀態(可能存在兩個執行緒 一直沒有變化)。
輸出分析:
根據上面的輸出對比可以發現,執行緒 1 和執行緒 2 由第一次 pstack 輸出的處在 sleep 函式變化為第二次 pstack 輸出的處在 memset 函式。但是執行緒 4 和執行緒 5 一直處在等鎖狀態(pthread_mutex_lock),在連續兩次的 pstack 資訊輸出中沒有變化,所以我們可以推測執行緒 4 和執行緒 5 發生了死鎖。
Gdb into thread
輸出:
清單 6. 然後通過 gdb attach 到死鎖程式
(gdb) info thread 5 Thread 0x41e37940 (LWP 6722) 0x0000003d1a80d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 4 Thread 0x42838940 (LWP 6723) 0x0000003d1a80d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 3 Thread 0x43239940 (LWP 6724) 0x0000003d19c9a541 in nanosleep () from /lib64/libc.so.6 2 Thread 0x43c3a940 (LWP 6725) 0x0000003d19c9a541 in nanosleep () from /lib64/libc.so.6 * 1 Thread 0x2b984ecabd90 (LWP 6721) 0x0000003d1a807b35 in pthread_join () from /lib64/libpthread.so.0
清單 7. 切換到執行緒 5 的輸出
(gdb) thread 5 [Switching to thread 5 (Thread 0x41e37940 (LWP 6722))]#0 0x0000003d1a80d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 (gdb) where #0 0x0000003d1a80d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x0000003d1a808e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x0000003d1a808cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0000000000400a9b in func1 () at lock.cpp:18 #4 0x0000000000400ad7 in thread1 (arg=0x0) at lock.cpp:43 #5 0x0000003d1a80673d in start_thread () from /lib64/libpthread.so.0 #6 0x0000003d19cd40cd in clone () from /lib64/libc.so.6
清單 8. 執行緒 4 和執行緒 5 的輸出
(gdb) f 3 #3 0x0000000000400a9b in func1 () at lock.cpp:18 18 pthread_mutex_lock(&mutex2); (gdb) thread 4 [Switching to thread 4 (Thread 0x42838940 (LWP 6723))]#0 0x0000003d1a80d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 (gdb) f 3 #3 0x0000000000400a17 in func2 () at lock.cpp:31 31 pthread_mutex_lock(&mutex1); (gdb) p mutex1 $1 = {__data = {__lock = 2, __count = 0, __owner = 6722, __nusers = 1, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\002\000\000\000\000\000\000\000B\032\000\000\001", '\000' <repeats 26 times>, __align = 2} (gdb) p mutex3 $2 = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0} (gdb) p mutex2 $3 = {__data = {__lock = 2, __count = 0, __owner = 6723, __nusers = 1, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\002\000\000\000\000\000\000\000C\032\000\000\001", '\000' <repeats 26 times>, __align = 2} (gdb)
從上面可以發現,執行緒 4 正試圖獲得鎖 mutex1,但是鎖 mutex1 已經被 LWP 為 6722 的執行緒得到(__owner = 6722),執行緒 5 正試圖獲得鎖 mutex2,但是鎖 mutex2 已經被 LWP 為 6723 的 得到(__owner = 6723),從 pstack 的輸出可以發現,LWP 6722 與執行緒 5 是對應的,LWP 6723 與執行緒 4 是對應的。所以我們可以得出, 執行緒 4 和執行緒 5 發生了交叉持鎖的死鎖現象。檢視執行緒的原始碼發現,執行緒 4 和執行緒 5 同時使用 mutex1 和 mutex2,且申請順序不合理。
總結
本文簡單介紹了一種在 Linux 平臺下分析死鎖問題的方法,對一些死鎖問題的分析有一定作用。希望對大家有幫助。理解了死鎖的原因,尤其是產生死鎖的四個必要條件,就可以最大可能地避免、預防和解除死鎖。所以,在系統設計、程式排程等方面注意如何不讓這四個必要條件成立,如何確定資源的合理分配演算法,避免程式永久佔據系統資源。此外,也要防止程式在處於等待狀態的情況下佔用資源 , 在系統執行過程中,對程式發出的每一個系統能夠滿足的資源申請進行動態檢查,並根據檢查結果決定是否分配資源,若分配後系統可能發生死鎖,則不予分配,否則予以分配。因此,對資源的分配要給予合理的規劃,使用有序資源分配法和銀行家演算法等是避免死鎖的有效方法。
相關文章
- 使用WinDbg對Windows Live Toolbar死鎖的簡單分析Windows
- 簡單介紹MySQL列印死鎖日誌的方法MySql
- Linux 增加swap 的最簡單方法Linux
- 死鎖分析
- MySQL:一個死鎖分析 (未分析出來的死鎖)MySql
- SQLServer的死鎖分析(1):頁鎖SQLServer
- 死鎖案例分析
- HashMap死鎖分析HashMap
- Linux 死鎖檢測模組 Lockdep 簡介Linux
- GreatSQL 死鎖案例分析SQL
- 故障分析 | MySQL死鎖案例分析MySql
- MySQL 死鎖問題分析MySql
- ORACLE 死鎖分析過程Oracle
- Sqlserver分析死鎖問題SQLServer
- 線上死鎖問題分析
- MySQL 死鎖日誌分析MySql
- 精算業務死鎖的具體分析
- Lumen/Laravel 使用 alipay 最簡單的方法Laravel
- 最簡單mysql的使用方法(轉)MySql
- linux上安裝Docker(非常簡單的安裝方法)LinuxDocker
- MySQL鎖等待與死鎖問題分析MySql
- 解決Oracle死鎖的快捷方法Oracle
- ORACLE中殺死鎖程式的方法Oracle
- 減少SQL Server死鎖的方法SQLServer
- oracle 死鎖表解決方法Oracle
- SQ死鎖及死鎖的解決
- MySQL批量更新死鎖案例分析MySql
- Oracle死鎖原因產生分析Oracle
- 單一會話引發的死鎖會話
- PDF轉文字檔案的最簡單方法
- 包含(處理)HTML的最簡單方法包括HTML
- linux中記憶體洩漏的檢測(一)最簡單的方法Linux記憶體
- 淺談 Linux 的死鎖檢測Linux
- 簡單分析synchronized不會鎖洩漏的原因synchronized
- oracle死鎖的檢視及kill方法Oracle
- 分析行連結的簡單方法
- stm32是世界上最簡單的
- MySQL死鎖系列-常見加鎖場景分析MySql