今天就跟大家聊聊有关如何进行ThreadDump问题分析，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

向阳网站制作公司哪家好，找创新互联！从网页设计、网站建设、微信开发、APP开发、响应式网站设计等网站项目制作，到程序开发，运营维护。创新互联自2013年起到现在10年的时间，我们拥有了丰富的建站经验和运维经验，来保证我们的工作的顺利进行。专注于网站建设就选创新互联。

1. 概述

随着系统日益增大，代码结构日渐复杂，经过验收测试的系统可能在实际生产环境下表现的一塌糊涂，也可能非常棒。因此通过QA并不能保证系统不会发生内存泄漏，往往流量越大泄露的越快，最后导致系统崩溃。比如在某个时间点系统一直出现TimeOut、或者系统突然处理速度急剧下降等问题。对于开发人员就非常棘手了，很多人根本一头雾水，基本上就是拍脑袋瞎猜了。其实发现此类问题定位的技术主要有内存泄漏定位、线程堆栈分析等。

线程堆栈概述

线程堆栈也就是所谓的线程调用栈（都是独立的），在Java线程堆栈式JVM线程状态的一个瞬时快照，快照包含了当前时刻所有线程的运行状态，包括每一个线程的调用栈，锁的持有等信息。每个虚拟机都提供了Thread Dump的后门帮助我们导出堆栈信息。借助线程堆栈会帮助我们迅速地缩小问题的范围， 找到突破口， 命中目标 。

线程堆栈一般包含的信息：1、线程名字，ID，线程的数量 2、线程运行状态、锁的状态（锁被哪个线程持有，哪个线程在等待） 3、函数调用层级关系。包括了完整类名，方法名，源代码行数

线程堆栈信息的多少，依赖于你系统的复杂度，借助堆栈信息，可分析很多问题，如线程死锁、锁竞争、死循环、识别耗时操作等。在多线程场景下进行稳定问题分析和性能分析他是最有效的方法，多数情况甚至无需了解系统就可以进行相应分析。

当然，线程堆栈也不是万能的，因为其是瞬时快照，所以对已消失没有留下痕迹的信息，是无法追踪历史的。这种情况只能借助于监控系统和日志进行分析。如连接池中的连接被哪些线程使用了没有被释放这类问题。其实也就是说线程堆栈分析的都是非功能性的问题。

线程堆栈善于分析以下问题：1、系统无缘无故CPU过高 2、系统挂起，无响应 3、系统运行越来越慢 4、线程死锁、死循环、饿死等。 5、由于线程数量太多导致系统失败（如无法创建线程等）

输出堆栈1、unix/Linux 使用kill -3 pid 进行转储 2、可以使用VisualVM等直接查看转储 3、JDK1.5以上的可以使用Thread.getStackTrace() 控制堆栈自动打印

2. 关于线程

只有实际操作了你才能更加的理解其概念，上一个DEMO

/**
 * Created by QIANG on 2017/9/29
 */
public class ThreadTest {

    Object obj1 = new Object();
    Object obj2 = new Object();

    public void  fun1(){

        synchronized (obj1){
            fun2();
        }
    }

    public void fun2(){
        synchronized (obj2){
          while (true){
              System.out.println("我要一直跑跑跑。。。");
          }
        }
    }

    public static void main(String[] args){
        ThreadTest aa = new ThreadTest();
        aa.fun1();

    }
}

这里我是用VisualVM 打印线程堆栈，在完整的堆栈信息中我们可以看到各种系统线程，限于篇幅原因只留下我关注的信息

2017-10-19 10:46:09
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode):  
"main" #1 prio=5 os_prio=0 tid=0x0000000002737000 nid=0x5d1c runnable [0x000000000270f000]
  java.lang.Thread.State: RUNNABLE
        at java.io.FileOutputStream.writeBytes(Native Method)
        at java.io.FileOutputStream.write(FileOutputStream.java:326)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
        - locked <0x0000000081e1c728> (a java.io.BufferedOutputStream)
        at java.io.PrintStream.write(PrintStream.java:482)
        - locked <0x0000000081e1c0a0> (a java.io.PrintStream)
        at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
        at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
        at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
        - locked <0x0000000081e1c058> (a java.io.OutputStreamWriter)
        at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
        at java.io.PrintStream.write(PrintStream.java:527)
        - eliminated <0x0000000081e1c0a0> (a java.io.PrintStream)
        at java.io.PrintStream.print(PrintStream.java:669)
        at java.io.PrintStream.println(PrintStream.java:806)
        - locked <0x0000000081e1c0a0> (a java.io.PrintStream)
        at com.ecej.test.Thread.ThreadTest.fun2(ThreadTest.java:21)
        - locked <0x0000000081e0a300> (a java.lang.Object)
        at com.ecej.test.Thread.ThreadTest.fun1(ThreadTest.java:14)
        - locked <0x0000000081e1c0c0> (a java.lang.Object)
        at com.ecej.test.Thread.ThreadTest.main(ThreadTest.java:28)
  Locked ownable synchronizers:
        - None
"VM Thread" os_prio=2 tid=0x0000000017928800 nid=0x3160 runnable 
"VM Periodic Task Thread" os_prio=2 tid=0x000000001a2d8000 nid=0x3dac waiting on condition

线程堆栈是从下往上看，借助这些信息当前系统做了什么就一目了然了。从main线程堆栈看出， - locked <0x0000000081e1c0c0> (a java.lang.Object) 这句代表该线程已经占有锁，锁ID为0x0000000081e1c0c0，这个ID是系统自动生成的，只需要知道每次打印堆栈同一ID表示同一个锁就行了。

分析下堆栈第一行信息"main" （线程名字）#1 prio=5（线程优先级） os_prio=0 tid=0x0000000002737000（线程ID） nid=0x5d1c（线程对应本地线程ID） runnable（线程状态） [0x000000000270f000]（线程占用内存地址）

nid=0x5d1c（线程对应本地线程ID） 这个大家看的有点懵逼，因为java我们开启一个线程就必然对应JVM中一个本地线程，也就是说本地线程数和java线程堆栈线程数相同。 在linux下我们可以使用以下方式：

1. 使用ps -ef | grep java 获得Java进程ID。

2. 使用pstack 获得Java虚拟机的本地线程的堆栈6。

如获得Thread 8 (Thread 4067802000 (LWP 3356))，其中Thread 4067802000 (LWP 3356)都是表示为本地线程ID。这里LWP 就对应了ThreadDump中的nid(native thread id ),只是nid用的是16进制表示的。分析得知，java线程和本地线程是同一个东西，本地线程才是真正的线程实体。

继续分析标识，其中“runable”表示当前线程处于运行状态。这个runable标识只能表示在JVM中此线程处于运行状态，熟悉线程的同学一定知道，此状态不代表真的在消耗PU。处于Runable的线程只能说明该线程没有被阻塞在java的wait\sleep上，也没有等待在锁上。但如果该线程调用了本地方法，而本地方法处于等待状态，那JVM是不知道本地代码中发生了什么，尽管当前线程实际处于阻塞状态，但实际显示出来的还是runable状态，这种情况不消耗CPU。看个例子：

java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method)

在实际中socket的本地方法大多数时间是阻塞的，除非缓冲区有数据。因此我们在分析哪个线程在消耗大量CPU时， 不能以这个"runnable"字样作为判断该线程是否消耗CPU的依据。 我们常在线程堆栈中发现".init"或者".clinit"字样的函数， 比如下面得信息 at java.util.logging.LogManager.(LogManager.java:156)

“.”表示当前正在执行类的初始化。“”正在执行对象得构造函数。下面说下两种初始化：

类初始化:编译器把类的变量初始化语句和类型得静态初始化器都收集到cllinit方法内，只能由JVM调用并保证线程安全。再初始化前必须保证其超类已经被初始化。

并非所有的类都会拥有一个() 方法， 在以下条件中该类不会拥有() 方法： • 该类既没有声明任何类变量， 也没有静态初始化语句； • 该类声明了类变量， 但没有明确使用类变量初始化语句或静态初始化语句初始化； • 该类仅包含静态final 变量的类变量初始化语句， 并且类变量初始化语句是编译时常量表达式

说白话一点就是类是初始化静态变量的，final static 直接进常量池了，不在此步骤。这一阶段其实就是类加载的最后一阶段。对象的初始化是代表了此对象生命周期的开始，只是调用了构造方法包括其里面的内容。

3. 关于锁

在进行堆栈解读前再了解下锁的基本常识，大家都知道wait()\sleep()的重大区别吧。相同点就是都释放CPU，不同点就是wait()释放锁而sleep()不释放。

从上边例子的堆栈信息可以看出锁的重要信息： 1、当一个线程占有一个锁时，线程堆栈会打印 - locked <0x0000000081e06858> (a java.io.InputStreamReader) 2、当一个线程正在等待其它线程释放该锁， 线程堆栈中会打印—waiting to lock <0x0000000081e06858> 3、当一个线程占有一个锁， 但又执行到该锁的wait()上， 线程堆栈中首先打印locked,然后又会打印—waiting on <0x0000000081e06858>

从解读中可以看出锁有三个重要的特征字：locked,waiting to lock,waiting on,了解这三个特征字， 就能够对锁进行分析了 。大多数是有一个 -—waiting to lock就必然有一个locked,当然有时候你也会找不到locked，因为一个线程释放锁和另一个线程被唤醒有一个空窗期，这时候转储就会发生此种情况。

4. 关于状态

借助堆栈可以分析很多类型问题，CPU消耗分析是堆栈的一个重要内容，先看下java的线程流转图（图来源于网络）

下面说下堆栈中的线程状态

RUNABLE 从JVM来说，此状态就是线程正在运行，但是咧，实际上他不一定消耗CPU，有可能是正在进行网络IO，此时线程大多数是被挂起的，只有当数据到达后，线程才会重新被唤醒，挂起发生在本地代码（Native）中,JVM其实根本就不知道（可不是调用wait/sleep）。

来个例子，下面的堆栈表示了当前程序正在从网络读取数据。

Thread-39" daemon prio=1 tid=0x08646590 nid=0x666d runnable [5beb7000..5beb88b8]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)

下面这个堆栈表示了线程实实在在的在消耗CPU

"Thread-444" prio=1 tid=0xa4853568 nid=0x7ade runnable [0xafcf7000..0xafcf8680]
java.lang.Thread.State: RUNNABLE
at org.apache.commons.collections.ReferenceMap.getEntry(Unknown Source)
at org.apache.commons.collections.ReferenceMap.get(Unknown Source)

TIMED_WAITING(on object monitor) 表示当前线程被挂起一段时间，正在执行obj.wait(int time)方法

"JMX server connection timeout 16" #16 daemon prio=5 os_prio=0 tid=0x000000001a59f000 nid=0x5a74 in Object.wait() [0x000000001b7df000]
  java.lang.Thread.State: TIMED_WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x0000000081f218e0> (a [I)
        at com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(ServerCommunicatorAdmin.java:168)
        - locked <0x0000000081f218e0> (a [I)
        at java.lang.Thread.run(Thread.java:748)

TIMED_WAITING(sleeping) 表示当前线程被挂起一段时间,即正在执行Thread.sleep(intt ime)方法

"Comm thread" daemon prio=10 tid=0x00002aaad4107400 nid=0x649f waiting on condition
[0x000000004133b000..0x000000004133ba00]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at org.apache.hadoop.mapred.Task$1.run(Task.java:282)
at java.lang.Thread.run(Thread.java:619)

TIMED_WAITING(parking) 当前线程被挂起一段时间,即正在执行Thread.sleep(int time)方法 ，就是执行本地方法的sleep

"RMI TCP" daemon prio=6 tid=0x0ae3b800 nid=0x958 waiting on condition [0x17eff000..0x17effa94]
java.lang.Thread.State: TIMED_WAITING (parking ）

WAINTING(on object monitor) 当前线程被挂起， 即正在执行obj.wait()方法 (无参数的wait()方法)

"IPC Client" daemon prio=10 tid=0x00002aaad4129800 nid=0x649d in Object.wait() [0x039000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)

SO,处于TIMED_WAITING、 WAINTING状态的线程一定不消耗CPU. 处于RUNNABLE的线程， 要结合当前线程代码的性质判断， 是否消耗CPU. • 如果是纯Java运算代码， 则消耗CPU. • 如果是网络IO,很少消耗CPU. • 如果是本地代码， 结合本地代码的性质判断(可以通过pstack/gstack获取本地线程堆栈)，如果是纯运算代码， 则消耗CPU, 如果被挂起， 则不消耗CPU,如果是IO,则不怎么消耗CPU。

看完上述内容，你们对如何进行ThreadDump问题分析有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注创新互联行业资讯频道，感谢大家的支持。

当前名称：如何进行ThreadDump问题分析
转载注明：http://kswjz.com/article/pgodos.html