Java多線程編程也是Java面試中經常考察的內容。剛接觸Java多線程編程的朋友們,可能會不慎寫出一些會導致死鎖(deadlock)的應用出來。如何分析造成Java多線程的原因呢?很多時候我們在懷疑造成死鎖的語句設置斷點,單步調試,反而又不能重現了。這種現象很正常,因為咱們單步調試和直接運行程序,代碼執行的時序是不同的,很可能無法滿足死鎖的觸發條件。 實際上,JDK已經給Java程序員提供了強大的死鎖分析工具,能夠直接分析一個正在運行的并且處于死鎖狀態的應用,并給出具體是哪一行Java代碼引起的死鎖。 這篇文章就以一個例子來給大家演示如何使用這個JDK提供的標準工具。 這個工具叫jstack,就是JDK安裝目錄的bin文件夾下的一個執行文件。 我們首先寫一個會導致死鎖的應用出來。
這個應用思路很簡單,同時啟動兩個線程,分別鎖住了resource1和resource2,然后休眠0.1秒,接著分別嘗試去請求資源resource2和resource1。 執行應用,在控制臺打印出下列輸出后,進入死鎖狀態: Thread 1: locked resource 1 Thread 2: locked resource 2 使用命令行 jps -l -m找到處于死鎖狀態應用的進程id。從下圖得知死鎖進程為51476: 然后使用命令行jstack 51476打印這個進程的運行棧信息。 我上圖紅色高亮出的 0x00000000d6f64988 和 0x00000000d6f649b8代表了代碼中的兩個資源“ABAP” 和“Java”。 jstack打印的輸出非常清晰,顯示了具體哪行Java代碼試圖去鎖定哪一個Java資源(下圖的waiting to lock)但是沒有成功, 并且將失敗的原因,即擁有當前請求資源的線程名稱也打印了出來。 有了jstack,Java程序員不用對著冗長燒腦的多線程代碼去冥思苦想了,JDK會自動把死鎖原因打印出來,太方便了。 要獲取更多Jerry的原創技術文章,請關注公眾號"汪子熙" |
|