现在，根据我们的示例 HotSpot线程转储，在下面找到每个线程转储部分的详细说明：

＃全线程转储标识符
基本上，这是唯一的关键字，一旦生成线程转储（例如：对于UNIX，通过kill -3 <PID>），您就会在中间件/标准Java输出日志中找到该关键字。 这是“线程转储”快照数据的开始。

Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode):

＃Java EE中间件，第三方和自定义应用程序线程
这部分是线程转储的核心，通常您将在其中花费大部分分析时间。 找到的线程数将取决于您使用的中间件软件，第三方库（可能具有其自己的线程）和您的应用程序（ 如果创建任何自定义线程，通常不是最佳实践 ）。

在我们的示例线程转储中，Weblogic是所使用的中间件。 从Weblogic 9.2开始，使用具有唯一标识符“'weblogic.kernel.Default（自我调整）”的自我调整线程池。

"[STANDBY] ExecuteThread: '414' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=3 tid=0x000000010916a800 nid=0x2613 in Object.wait() [0xfffffffe9edff000]java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)- waiting on <0xffffffff27d44de0> (a weblogic.work.ExecuteThread)at java.lang.Object.wait(Object.java:485)at weblogic.work.ExecuteThread.waitForRequest(ExecuteThread.java:160)- locked <0xffffffff27d44de0> (a weblogic.work.ExecuteThread)at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)

＃HotSpot VM线程
这是由HotSpot VM管理的内部线程，以执行内部本机操作。 通常，除非看到较高的CPU（通过线程转储和prstat /本机线程ID相关性），否则您不必担心这一点。

"VM Periodic Task Thread" prio=3 tid=0x0000000101238800 nid=0x19 waiting on condition

＃HotSpot GC线程
当使用HotSpot并行GC时（在使用多物理核心硬件时，这很普遍），默认情况下或根据JVM调整一定数量的GC线程，HotSpot VM会创建。 这些GC线程允许VM以并行方式执行其定期GC清理，从而总体上减少了GC时间。 以增加CPU利用率为代价。

"GC task thread#0 (ParallelGC)" prio=3 tid=0x0000000100120000 nid=0x3 runnable
"GC task thread#1 (ParallelGC)" prio=3 tid=0x0000000100131000 nid=0x4 runnable
………………………………………………………………………………………………………………………………………………………………

这也是至关重要的数据，因为当面临与GC相关的问题（例如过多的GC，内存泄漏等）时，您将能够使用其本机id值（nid）将从OS / Java进程观察到的任何高CPU与这些线程相关联= 0x3）。 您将在以后的文章中学习如何识别和确认此问题。

＃JNI全局引用计数
JNI（Java本机接口）全局引用基本上是从本机代码到Java垃圾收集器管理的Java对象的对象引用。 其作用是防止收集本机代码仍在使用但技术上在Java代码中没有“实时”引用的对象。

监视JNI引用以检测与JNI相关的泄漏也很重要。 如果您直接使用JNI进行编程，或者使用易于发生本机内存泄漏的第三方工具（例如监视工具）进行编程，则可能会发生这种情况。

JNI global references: 1925

＃Java堆利用率视图
此数据已添加回JDK 1 .6，并为您提供了HotSpot Heap的简短快速视图。 我发现在与GC相关的问题以及HIGH CPU一起进行故障排除时，它非常有用，因为您可以在单个快照中同时获得线程转储和Java堆，从而可以确定（或排除）特定Java堆内存空间中的任何压力点以及当前当时正在执行线程计算。 正如您在示例线程转储中所看到的，Java堆OldGen已被最大化！

HeapPSYoungGen      total 466944K, used 178734K [0xffffffff45c00000, 0xffffffff70800000, 0xffffffff70800000)eden space 233472K, 76% used [0xffffffff45c00000,0xffffffff50ab7c50,0xffffffff54000000)from space 233472K, 0% used [0xffffffff62400000,0xffffffff62400000,0xffffffff70800000)to   space 233472K, 0% used [0xffffffff54000000,0xffffffff54000000,0xffffffff62400000)PSOldGen        total 1400832K, used 1400831K [0xfffffffef0400000, 0xffffffff45c00000, 0xffffffff45c00000)object space 1400832K, 99% used [0xfffffffef0400000,0xffffffff45bfffb8,0xffffffff45c00000)PSPermGen       total 262144K, used 248475K [0xfffffffed0400000, 0xfffffffee0400000, 0xfffffffef0400000)object space 262144K, 94% used [0xfffffffed0400000,0xfffffffedf6a6f08,0xfffffffee0400000)

我希望本文有助于理解HotSpot VM线程转储的基本视图。下一篇文章将为您提供与IBM VM相同的线程转储概述和细分。

请随时发表任何评论或问题。

参考： 如何分析线程转储–第1部分 ，   如何分析线程转储–第2部分：JVM概述和 如何分析线程转储–第3部分： 来自JCG合作伙伴的 HotSpot VM   “ Java EE支持模式和Java教程”博客上的Pierre-Hugues Charbonneau。