详解Java线程堆栈
写在前面:线程堆栈应该是多线程类应用程序非功能问题定位的最有效手段,可以说是杀手锏。线程堆栈最擅长与分析如下类型问题:
系统无缘无故CPU过高。
系统挂起,无响应。
系统运行越来越慢。
性能瓶颈(如无法充分利用CPU等)
线程死锁、死循环,饿死等。
由于线程数量太多导致系统失败(如无法创建线程等)。
如何解读线程堆栈
如下面一段Java源代码程序:
packageorg.ccgogoing.study.stacktrace; /** *@Author:LuoChong400 *@Description:测试线程 *@Date:Createin07:27PM2017/12/08 */ publicclassMyTest{ Objectobj1=newObject(); Objectobj2=newObject(); publicvoidfun1(){ synchronized(obj1){ fun2(); } } publicvoidfun2(){ synchronized(obj2){ while(true){//为了打印堆栈,该函数堆栈分析不退出 System.out.print(""); } } } publicstaticvoidmain(String[]args){ MyTestaa=newMyTest(); aa.fun1(); } }
在Idea中运行该程序,然后按下CTRL+BREAK键,打印出线程堆栈信息如下:
FullthreaddumpJavaHotSpot(TM)64-BitServerVM(24.79-b02mixedmode): "ServiceThread"daemonprio=6tid=0x000000000c53b000nid=0xca58runnable[0x0000000000000000] java.lang.Thread.State:RUNNABLE "C2CompilerThread1"daemonprio=10tid=0x000000000c516000nid=0xd390waitingoncondition[0x0000000000000000] java.lang.Thread.State:RUNNABLE "C2CompilerThread0"daemonprio=10tid=0x000000000c515000nid=0xcbacwaitingoncondition[0x0000000000000000] java.lang.Thread.State:RUNNABLE "MonitorCtrl-Break"daemonprio=6tid=0x000000000c514000nid=0xd148runnable[0x000000000caee000] java.lang.Thread.State:RUNNABLE atjava.net.SocketInputStream.socketRead0(NativeMethod) atjava.net.SocketInputStream.read(SocketInputStream.java:152) atjava.net.SocketInputStream.read(SocketInputStream.java:122) atsun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) atsun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) atsun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) -locked<0x00000000d7858b50>(ajava.io.InputStreamReader) atjava.io.InputStreamReader.read(InputStreamReader.java:184) atjava.io.BufferedReader.fill(BufferedReader.java:154) atjava.io.BufferedReader.readLine(BufferedReader.java:317) -locked<0x00000000d7858b50>(ajava.io.InputStreamReader) atjava.io.BufferedReader.readLine(BufferedReader.java:382) atcom.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:64) "AttachListener"daemonprio=10tid=0x000000000ad4a000nid=0xd24crunnable[0x0000000000000000] java.lang.Thread.State:RUNNABLE "SignalDispatcher"daemonprio=10tid=0x000000000c1a8800nid=0xd200waitingoncondition[0x0000000000000000] java.lang.Thread.State:RUNNABLE "Finalizer"daemonprio=8tid=0x000000000ace6000nid=0xcd74inObject.wait()[0x000000000c13f000] java.lang.Thread.State:WAITING(onobjectmonitor) atjava.lang.Object.wait(NativeMethod) -waitingon<0x00000000d7284858>(ajava.lang.ref.ReferenceQueue$Lock) atjava.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135) -locked<0x00000000d7284858>(ajava.lang.ref.ReferenceQueue$Lock) atjava.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151) atjava.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209) "ReferenceHandler"daemonprio=10tid=0x000000000ace4800nid=0xce34inObject.wait()[0x000000000bf4f000] java.lang.Thread.State:WAITING(onobjectmonitor) atjava.lang.Object.wait(NativeMethod) -waitingon<0x00000000d7284470>(ajava.lang.ref.Reference$Lock) atjava.lang.Object.wait(Object.java:503) atjava.lang.ref.Reference$ReferenceHandler.run(Reference.java:133) -locked<0x00000000d7284470>(ajava.lang.ref.Reference$Lock) "main"prio=6tid=0x000000000238e800nid=0xc940runnable[0x00000000027af000] java.lang.Thread.State:RUNNABLE atorg.ccgogoing.study.stacktrace.MyTest.fun2(MyTest.java:22) -locked<0x00000000d77d50c8>(ajava.lang.Object) atorg.ccgogoing.study.stacktrace.MyTest.fun1(MyTest.java:15) -locked<0x00000000d77d50b8>(ajava.lang.Object) atorg.ccgogoing.study.stacktrace.MyTest.main(MyTest.java:29) "VMThread"prio=10tid=0x000000000ace1000nid=0xd0a8runnable "GCtaskthread#0(ParallelGC)"prio=6tid=0x00000000023a4000nid=0xd398runnable "GCtaskthread#1(ParallelGC)"prio=6tid=0x00000000023a5800nid=0xcc20runnable "GCtaskthread#2(ParallelGC)"prio=6tid=0x00000000023a7000nid=0xb914runnable "GCtaskthread#3(ParallelGC)"prio=6tid=0x00000000023a9000nid=0xd088runnable "VMPeriodicTaskThread"prio=10tid=0x000000000c53f000nid=0xc1b4waitingoncondition JNIglobalreferences:138 Heap PSYoungGentotal36864K,used6376K[0x00000000d7280000,0x00000000d9b80000,0x0000000100000000) edenspace31744K,20%used[0x00000000d7280000,0x00000000d78ba0d0,0x00000000d9180000) fromspace5120K,0%used[0x00000000d9680000,0x00000000d9680000,0x00000000d9b80000) tospace5120K,0%used[0x00000000d9180000,0x00000000d9180000,0x00000000d9680000) ParOldGentotal83456K,used0K[0x0000000085800000,0x000000008a980000,0x00000000d7280000) objectspace83456K,0%used[0x0000000085800000,0x0000000085800000,0x000000008a980000) PSPermGentotal21504K,used3300K[0x0000000080600000,0x0000000081b00000,0x0000000085800000) objectspace21504K,15%used[0x0000000080600000,0x0000000080939290,0x0000000081b00000)
在上面这段堆栈输出中,可以看到有很多后台线程和main线程,其中只有main线程属于Java用户线程,其他几个都是虚拟机自动创建的,我们分析的过程中,只关心用户线程即可。
从上面的main线程中可以很直观的看到当前线程的调用上下文,其中一个线程的某一层调用含义如下:
atMyTest.fun1(MyTest.java:15) |||| |||+-----当前正在调用的函数所在的源代码文件的行号 ||+------------当前正在调用的函数所在的源代码文件 |+---------------------当前正在调用的方法名 +---------------------------当前正在调用的类名
另外,堆栈中有:-locked<0x00000000d77d50b8>(ajava.lang.Object)语句,表示该线程已经占有柯锁<0x00000000d77d50b8>,尖括号中表示锁ID,这个事系统自动产生的,我们只需要知道每次打印的堆栈,同一个ID表示是同一个锁即可。每一个线程堆栈的第一行含义如下:
"main"prio=1tid=0x000000000238e800nid=0xc940runnable[0x00000000027af000] |||||| |||||+--线程占用内存地址 ||||+-----------线程的状态 |||+----线程对应的本地线程id号 ||+-------------------线程id |+--------------------------线程优先级 +-------------------------------线程名称 其中需要说明的是,线程对应的本地线程id号,是指Java线程所对应的虚拟机中的本地线程。由于Java是解析型语言,执行的实体是Java虚拟机,因此Java语言中的线程是依附于虚拟机中的本地线程来运行的,实际上是本地线程在执行Java线程代码。
锁的解读
从上面的线程堆栈看,线程堆栈中包含的直接信息为:线程的个数,每个线程调用的方法堆栈,当前锁的状态。线程的个数可以直接数出来;线程调用的方法堆栈,从下向上看,即表示当前的线程调用了哪个类上的哪个方法。而锁得状态看起来稍微有一点技巧。与锁相关的信息如下:
当一个线程占有一个锁的时候,线程的堆栈中会打印--locked<0x00000000d77d50c8>
当一个线程正在等待其它线程释放该锁,线程堆栈中会打印--waitingtolock<0x00000000d77d50c8>
当一个线程占有一个锁,但又执行到该锁的wait()方法上,线程堆栈中首先打印locked,然后又会打印--waitingon
<0x00000000d77d50c8>
线程状态的解读
借助线程堆栈,可以分析很多类型的问题,CPU的消耗分析即是线程堆栈分析的一个重要内容;
处于TIMED_WAITING、WAITING状态的线程一定不消耗CPU。处于RUNNABLE的线程,要结合当前代码的性质判断,是否消耗CPU。
如果是纯Java运算代码,则消耗CPU。
如果是网络IO,很少消耗CPU。
如果是本地代码,要结合本地代码的性质判断(可以通过pstack、gstack获取本地线程堆栈),如果是纯运算代码,则消耗CPU,如果被挂起,则不消耗CPU,如果是IO,则不怎么消耗CPU。
如何借助线程堆栈分析问题
线程堆栈在定位如下类型的问题上非常有帮助:
线程死锁的分析
Java代码导致的CPU过高分析
死循环分析
资源不足分析
性能瓶颈分析
线程死锁分析
死锁的概念就不做过多解释了,不明白的可以去网上查查;
两个或超过两个线程因为环路的锁依赖关系而形成的锁环,就形成了真正的死锁,如下为死锁喉打印的堆栈:
FoundoneJava-leveldeadlock: ============================= "org.ccgogoing.study.stacktrace.deadlock.TestThread2": waitingtolockmonitor0x000000000a9ad118(object0x00000000d77363d0,ajava.lang.Object), whichisheldby"org.ccgogoing.study.stacktrace.deadlock.TestThread1" "org.ccgogoing.study.stacktrace.deadlock.TestThread1": waitingtolockmonitor0x000000000a9abc78(object0x00000000d77363e0,ajava.lang.Object), whichisheldby"org.ccgogoing.study.stacktrace.deadlock.TestThread2" Javastackinformationforthethreadslistedabove: =================================================== "org.ccgogoing.study.stacktrace.deadlock.TestThread2": atorg.ccgogoing.study.stacktrace.deadlock.TestThread2.fun(TestThread2.java:35) -waitingtolock<0x00000000d77363d0>(ajava.lang.Object) -locked<0x00000000d77363e0>(ajava.lang.Object) atorg.ccgogoing.study.stacktrace.deadlock.TestThread2.run(TestThread2.java:22) "org.ccgogoing.study.stacktrace.deadlock.TestThread1": atorg.ccgogoing.study.stacktrace.deadlock.TestThread1.fun(TestThread1.java:33) -waitingtolock<0x00000000d77363e0>(ajava.lang.Object) -locked<0x00000000d77363d0>(ajava.lang.Object) atorg.ccgogoing.study.stacktrace.deadlock.TestThread1.run(TestThread1.java:20) Found1deadlock.
从打印的堆栈中我们能看到"FoundoneJava-leveldeadlock:",即如果存在死锁情况,堆栈中会直接给出死锁的分析结果.
当一组Java线程发生死锁的时候,那么意味着GameOver,这些线程永远得被挂在那里了,永远不可能继续运行下去。当发生死锁的线程在执行系统的关键功能时,那么这个死锁可能会导致整个系统瘫痪,要想恢复系统,临时也是唯一的规避方法是将系统重启。然后赶快去修改导致这个死锁的Bug。
注意:死锁的两个或多个线程是不消耗CPU的,有的人认为CPU100%的使用率是线程死锁导致的,这个说法是完全错误的。死循环,并且在循环中代码都是CPU密集型,才有可能导致CPU的100%使用率,像socket或者数据库等IO操作是不怎么消耗CPU的。