詳解Java線程堆棧
寫在前面: 線程堆棧應(yīng)該是多線程類應(yīng)用程序非功能問題定位的最有效手段,可以說是殺手锏。線程堆棧最擅長與分析如下類型問題:
系統(tǒng)無緣無故CPU過高。
系統(tǒng)掛起,無響應(yīng)。
系統(tǒng)運行越來越慢。
性能瓶頸(如無法充分利用CPU等)
線程死鎖、死循環(huán),餓死等。
由于線程數(shù)量太多導致系統(tǒng)失?。ㄈ鐭o法創(chuàng)建線程等)。
如何解讀線程堆棧
如下面一段Java源代碼程序:
package org.ccgogoing.study.stacktrace; /** * @Author: LuoChong400 * @Description: 測試線程 * @Date: Create in 07:27 PM 2017/12/08 */ public class MyTest { Object obj1 = new Object(); Object obj2 = new Object(); public void fun1() { synchronized (obj1) { fun2(); } } public void fun2() { synchronized (obj2) { while (true) { //為了打印堆棧,該函數(shù)堆棧分析不退出 System.out.print(""); } } } public static void main(String[] args) { MyTest aa = new MyTest(); aa.fun1(); } }
在Idea 中運行該程序,然后按下CTRL+BREAK鍵,打印出線程堆棧信息如下:
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode): "Service Thread" daemon prio=6 tid=0x000000000c53b000 nid=0xca58 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread1" daemon prio=10 tid=0x000000000c516000 nid=0xd390 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" daemon prio=10 tid=0x000000000c515000 nid=0xcbac waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Monitor Ctrl-Break" daemon prio=6 tid=0x000000000c514000 nid=0xd148 runnable [0x000000000caee000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) - locked <0x00000000d7858b50> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:184) at java.io.BufferedReader.fill(BufferedReader.java:154) at java.io.BufferedReader.readLine(BufferedReader.java:317) - locked <0x00000000d7858b50> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:382) at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:64) "Attach Listener" daemon prio=10 tid=0x000000000ad4a000 nid=0xd24c runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" daemon prio=10 tid=0x000000000c1a8800 nid=0xd200 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=8 tid=0x000000000ace6000 nid=0xcd74 in Object.wait() [0x000000000c13f000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000d7284858> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135) - locked <0x00000000d7284858> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209) "Reference Handler" daemon prio=10 tid=0x000000000ace4800 nid=0xce34 in Object.wait() [0x000000000bf4f000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000d7284470> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:503) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133) - locked <0x00000000d7284470> (a java.lang.ref.Reference$Lock) "main" prio=6 tid=0x000000000238e800 nid=0xc940 runnable [0x00000000027af000] java.lang.Thread.State: RUNNABLE at org.ccgogoing.study.stacktrace.MyTest.fun2(MyTest.java:22) - locked <0x00000000d77d50c8> (a java.lang.Object) at org.ccgogoing.study.stacktrace.MyTest.fun1(MyTest.java:15) - locked <0x00000000d77d50b8> (a java.lang.Object) at org.ccgogoing.study.stacktrace.MyTest.main(MyTest.java:29) "VM Thread" prio=10 tid=0x000000000ace1000 nid=0xd0a8 runnable "GC task thread#0 (ParallelGC)" prio=6 tid=0x00000000023a4000 nid=0xd398 runnable "GC task thread#1 (ParallelGC)" prio=6 tid=0x00000000023a5800 nid=0xcc20 runnable "GC task thread#2 (ParallelGC)" prio=6 tid=0x00000000023a7000 nid=0xb914 runnable "GC task thread#3 (ParallelGC)" prio=6 tid=0x00000000023a9000 nid=0xd088 runnable "VM Periodic Task Thread" prio=10 tid=0x000000000c53f000 nid=0xc1b4 waiting on condition JNI global references: 138 Heap PSYoungGen total 36864K, used 6376K [0x00000000d7280000, 0x00000000d9b80000, 0x0000000100000000) eden space 31744K, 20% used [0x00000000d7280000,0x00000000d78ba0d0,0x00000000d9180000) from space 5120K, 0% used [0x00000000d9680000,0x00000000d9680000,0x00000000d9b80000) to space 5120K, 0% used [0x00000000d9180000,0x00000000d9180000,0x00000000d9680000) ParOldGen total 83456K, used 0K [0x0000000085800000, 0x000000008a980000, 0x00000000d7280000) object space 83456K, 0% used [0x0000000085800000,0x0000000085800000,0x000000008a980000) PSPermGen total 21504K, used 3300K [0x0000000080600000, 0x0000000081b00000, 0x0000000085800000) object space 21504K, 15% used [0x0000000080600000,0x0000000080939290,0x0000000081b00000)
在上面這段堆棧輸出中,可以看到有很多后臺線程和main線程,其中只有main線程屬于Java用戶線程,其他幾個都是虛擬機自動創(chuàng)建的,我們分析的過程中,只關(guān)心用戶線程即可。
從上面的main線程中可以很直觀的看到當前線程的調(diào)用上下文,其中一個線程的某一層調(diào)用含義如下:
at MyTest.fun1(MyTest.java:15) | | | | | | | +-----當前正在調(diào)用的函數(shù)所在的源代碼文件的行號 | | +------------當前正在調(diào)用的函數(shù)所在的源代碼文件 | +---------------------當前正在調(diào)用的方法名 +---------------------------當前正在調(diào)用的類名
另外,堆棧中有:- locked <0x00000000d77d50b8> (a java.lang.Object)語句,表示該線程已經(jīng)占有柯鎖<0x00000000d77d50b8>,尖括號中表示鎖ID,這個事系統(tǒng)自動產(chǎn)生的,我們只需要知道每次打印的堆棧,同一個ID表示是同一個鎖即可。每一個線程堆棧的第一行含義如下:
"main" prio=1 tid=0x000000000238e800 nid=0xc940 runnable [0x00000000027af000] | | | | | | | | | | | +--線程占用內(nèi)存地址 | | | | +-----------線程的狀態(tài) | | | +----線程對應(yīng)的本地線程id號 | | +-------------------線程id | +--------------------------線程優(yōu)先級 +-------------------------------線程名稱 其中需要說明的是,線程對應(yīng)的本地線程id號,是指Java線程所對應(yīng)的虛擬機中的本地線程。由于Java是解析型語言,執(zhí)行的實體是Java虛擬機,因此Java語言中的線程是依附于虛擬機中的本地線程來運行的,實際上是本地線程在執(zhí)行Java線程代碼。
鎖的解讀
從上面的線程堆???,線程堆棧中包含的直接信息為:線程的個數(shù),每個線程調(diào)用的方法堆棧,當前鎖的狀態(tài)。線程的個數(shù)可以直接數(shù)出來;線程調(diào)用的方法堆棧,從下向上看,即表示當前的線程調(diào)用了哪個類上的哪個方法。而鎖得狀態(tài)看起來稍微有一點技巧。與鎖相關(guān)的信息如下:
當一個線程占有一個鎖的時候,線程的堆棧中會打印--locked<0x00000000d77d50c8>
當一個線程正在等待其它線程釋放該鎖,線程堆棧中會打印--waiting to lock<0x00000000d77d50c8>
當一個線程占有一個鎖,但又執(zhí)行到該鎖的wait()方法上,線程堆棧中首先打印locked,然后又會打印--waiting on
<0x00000000d77d50c8>
線程狀態(tài)的解讀
借助線程堆棧,可以分析很多類型的問題,CPU的消耗分析即是線程堆棧分析的一個重要內(nèi)容;
處于TIMED_WAITING、WAITING狀態(tài)的線程一定不消耗CPU。處于RUNNABLE的線程,要結(jié)合當前代碼的性質(zhì)判斷,是否消耗CPU。
如果是純Java運算代碼,則消耗CPU。
如果是網(wǎng)絡(luò)IO,很少消耗CPU。
如果是本地代碼,要結(jié)合本地代碼的性質(zhì)判斷(可以通過pstack、gstack獲取本地線程堆棧),如果是純運算代碼,則消耗CPU,如果被掛起,則不消耗CPU,如果是IO,則不怎么消耗CPU。
如何借助線程堆棧分析問題
線程堆棧在定位如下類型的問題上非常有幫助:
線程死鎖的分析
Java代碼導致的CPU過高分析
死循環(huán)分析
資源不足分析
性能瓶頸分析
線程死鎖分析
死鎖的概念就不做過多解釋了,不明白的可以去網(wǎng)上查查;
兩個或超過兩個線程因為環(huán)路的鎖依賴關(guān)系而形成的鎖環(huán),就形成了真正的死鎖,如下為死鎖喉打印的堆棧:
Found one Java-level deadlock: ============================= "org.ccgogoing.study.stacktrace.deadlock.TestThread2": waiting to lock monitor 0x000000000a9ad118 (object 0x00000000d77363d0, a java.lang.Object), which is held by "org.ccgogoing.study.stacktrace.deadlock.TestThread1" "org.ccgogoing.study.stacktrace.deadlock.TestThread1": waiting to lock monitor 0x000000000a9abc78 (object 0x00000000d77363e0, a java.lang.Object), which is held by "org.ccgogoing.study.stacktrace.deadlock.TestThread2" Java stack information for the threads listed above: =================================================== "org.ccgogoing.study.stacktrace.deadlock.TestThread2": at org.ccgogoing.study.stacktrace.deadlock.TestThread2.fun(TestThread2.java:35) - waiting to lock <0x00000000d77363d0> (a java.lang.Object) - locked <0x00000000d77363e0> (a java.lang.Object) at org.ccgogoing.study.stacktrace.deadlock.TestThread2.run(TestThread2.java:22) "org.ccgogoing.study.stacktrace.deadlock.TestThread1": at org.ccgogoing.study.stacktrace.deadlock.TestThread1.fun(TestThread1.java:33) - waiting to lock <0x00000000d77363e0> (a java.lang.Object) - locked <0x00000000d77363d0> (a java.lang.Object) at org.ccgogoing.study.stacktrace.deadlock.TestThread1.run(TestThread1.java:20) Found 1 deadlock.
從打印的堆棧中我們能看到"Found one Java-level deadlock:",即如果存在死鎖情況,堆棧中會直接給出死鎖的分析結(jié)果.
當一組Java線程發(fā)生死鎖的時候,那么意味著Game Over,這些線程永遠得被掛在那里了,永遠不可能繼續(xù)運行下去。當發(fā)生死鎖的線程在執(zhí)行系統(tǒng)的關(guān)鍵功能時,那么這個死鎖可能會導致整個系統(tǒng)癱瘓,要想恢復系統(tǒng),臨時也是唯一的規(guī)避方法是將系統(tǒng)重啟。然后趕快去修改導致這個死鎖的Bug。
注意:死鎖的兩個或多個線程是不消耗CPU的,有的人認為CPU100%的使用率是線程死鎖導致的,這個說法是完全錯誤的。死循環(huán),并且在循環(huán)中代碼都是CPU密集型,才有可能導致CPU的100%使用率,像socket或者數(shù)據(jù)庫等IO操作是不怎么消耗CPU的。
相關(guān)文章
mybatis-plus通用枚舉@JsonValue接收參數(shù)報錯No enum constant
最近在使用mybatis-plus時用到了通用枚舉,遇到了問題,本文主要介紹了mybatis-plus通用枚舉@JsonValue接收參數(shù)報錯No enum constant,具有一定的參考價值,感興趣的可以了解一下2023-09-09SpringCloud Zuul在何種情況下使用Hystrix及問題小結(jié)
這篇文章主要介紹了SpringCloud Zuul在何種情況下使用Hystrix 及問題小結(jié),感興趣的朋友跟隨小編一起看看吧2018-11-11spring mvc使用@InitBinder標簽對表單數(shù)據(jù)綁定的方法
這篇文章主要介紹了spring mvc使用@InitBinder標簽對表單數(shù)據(jù)綁定的方法,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2018-03-03Java Thread之Sleep()使用方法及總結(jié)
這篇文章主要介紹了Java Thread之Sleep()使用方法及總結(jié),具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2022-11-11springboot在服務(wù)器上的幾種啟動方式(小結(jié))
這篇文章主要介紹了springboot在服務(wù)器上的幾種啟動方式(小結(jié)),小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2018-09-09Java四舍五入時保留指定小數(shù)位數(shù)的五種方式
這篇文章主要介紹了Java四舍五入時保留指定小數(shù)位數(shù)的五種方式,幫助大家更好的理解和使用Java,感興趣的朋友可以了解下2020-09-09