详解Java线程堆栈
程序员文章站
2023-12-13 09:28:28
写在前面： 线程堆栈应该是多线程类应用程序非功能问题定位的最有效手段，可以说是杀手锏。线程堆栈最擅长与分析如下类型问题：
系统无缘无故cpu过高。
系统挂起，无响应...
写在前面： 线程堆栈应该是多线程类应用程序非功能问题定位的最有效手段，可以说是杀手锏。线程堆栈最擅长与分析如下类型问题：
系统无缘无故cpu过高。
系统挂起，无响应。
系统运行越来越慢。
性能瓶颈（如无法充分利用cpu等）
线程死锁、死循环，饿死等。
由于线程数量太多导致系统失败（如无法创建线程等）。
如何解读线程堆栈
如下面一段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) { //为了打印堆栈，该函数堆栈分析不退出
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用户线程，其他几个都是虚拟机自动创建的，我们分析的过程中，只关心用户线程即可。
从上面的main线程中可以很直观的看到当前线程的调用上下文，其中一个线程的某一层调用含义如下：
at mytest.fun1(mytest.java:15) | | | | | | | +-----当前正在调用的函数所在的源代码文件的行号 | | +------------当前正在调用的函数所在的源代码文件 | +---------------------当前正在调用的方法名 +---------------------------当前正在调用的类名
另外，堆栈中有：- locked <0x00000000d77d50b8> (a java.lang.object)语句，表示该线程已经占有柯锁<0x00000000d77d50b8>,尖括号中表示锁id，这个事系统自动产生的，我们只需要知道每次打印的堆栈，同一个id表示是同一个锁即可。每一个线程堆栈的第一行含义如下：
"main" prio=1 tid=0x000000000238e800 nid=0xc940 runnable [0x00000000027af000] | | | | | | | | | | | +--线程占用内存地址 | | | | +-----------线程的状态 | | | +----线程对应的本地线程id号 | | +-------------------线程id | +--------------------------线程优先级 +-------------------------------线程名称 其中需要说明的是，线程对应的本地线程id号，是指java线程所对应的虚拟机中的本地线程。由于java是解析型语言，执行的实体是java虚拟机，因此java语言中的线程是依附于虚拟机中的本地线程来运行的，实际上是本地线程在执行java线程代码。
锁的解读
从上面的线程堆栈看，线程堆栈中包含的直接信息为：线程的个数，每个线程调用的方法堆栈，当前锁的状态。线程的个数可以直接数出来；线程调用的方法堆栈，从下向上看，即表示当前的线程调用了哪个类上的哪个方法。而锁得状态看起来稍微有一点技巧。与锁相关的信息如下：
当一个线程占有一个锁的时候，线程的堆栈中会打印--locked<0x00000000d77d50c8>
当一个线程正在等待其它线程释放该锁，线程堆栈中会打印--waiting to lock<0x00000000d77d50c8>
当一个线程占有一个锁，但又执行到该锁的wait()方法上，线程堆栈中首先打印locked，然后又会打印--waiting on
<0x00000000d77d50c8>
线程状态的解读
借助线程堆栈，可以分析很多类型的问题，cpu的消耗分析即是线程堆栈分析的一个重要内容；
处于timed_waiting、waiting状态的线程一定不消耗cpu。处于runnable的线程，要结合当前代码的性质判断，是否消耗cpu。
如果是纯java运算代码，则消耗cpu。
如果是网络io，很少消耗cpu。
如果是本地代码，要结合本地代码的性质判断（可以通过pstack、gstack获取本地线程堆栈），如果是纯运算代码，则消耗cpu，如果被挂起，则不消耗cpu，如果是io，则不怎么消耗cpu。
如何借助线程堆栈分析问题
线程堆栈在定位如下类型的问题上非常有帮助：
线程死锁的分析
java代码导致的cpu过高分析
死循环分析
资源不足分析
性能瓶颈分析
线程死锁分析
死锁的概念就不做过多解释了，不明白的可以去网上查查；
两个或超过两个线程因为环路的锁依赖关系而形成的锁环，就形成了真正的死锁，如下为死锁喉打印的堆栈：
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:",即如果存在死锁情况,堆栈中会直接给出死锁的分析结果.
当一组java线程发生死锁的时候,那么意味着game over,这些线程永远得被挂在那里了,永远不可能继续运行下去。当发生死锁的线程在执行系统的关键功能时，那么这个死锁可能会导致整个系统瘫痪，要想恢复系统，临时也是唯一的规避方法是将系统重启。然后赶快去修改导致这个死锁的bug。
注意：死锁的两个或多个线程是不消耗cpu的，有的人认为cpu100%的使用率是线程死锁导致的，这个说法是完全错误的。死循环，并且在循环中代码都是cpu密集型，才有可能导致cpu的100%使用率，像socket或者数据库等io操作是不怎么消耗cpu的。