JVM 线程堆栈分析过程详解

　　Heap
　　PSYoungGen 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上的线程堆栈信息和线程池做了详细的拆解，如下图所示：

　　上图中可以看出线程堆栈是由多个不同部分组成的。这些信息对问题分析都很重要，但对不同的问题模式的分析会使用不同的部分（问题模式会在后面的文章中做模拟和演示。）
　　现在通过这个分析样例，给大家详细解释一下HoteSpot上线程堆栈信息中的各个组成部分：
　　#Full thread dump标示符
　　“Full thread dump”是一个全局的关键字，你可以在中间件和单机版本Java的线程堆栈信息的输出日志中找到它（比如说在UNIX下使用：kill-3<PID>）。这是线程堆栈快照的开始部分。
　　Full thread dump Java HotSpot(TM)64-Bit Server VM(20.0-b11 mixed mode):
　　#Java EE中间件，第三方以及自定义应用软件中的线程
　　这个部分是整个线程堆栈的核心部分，也是通常需要花费多分析时间的部分。堆栈中线程的个数取决你使用的中间件，第三方库（可能会有独立线程）以及你的应用程序（如果创建自定义线程，这通常不是一个很好的实践）。
　　在我们的示例线程堆栈中，WebLogic是我们所使用的中间件。从Weblogic 9.2开始，会使用一个用“’weblogic.kernel.Default(self-tuning)”标识的能自行管理的线程池
　　"[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管理的内部线程，用于执行内部的原生操作。一般你不用对此操太多心，除非你(通过相关的线程堆栈以及prstat或者原生线程Id)发现很高的CPU占用率.
　　"VM Periodic Task Thread"prio=3 tid=0x0000000101238800 nid=0x19 waiting on condition
　　#HotSpot GC线程
　　当使用HotSpot进行并行GC(如今在使用多个物理核心的环境下很常见)，默认创建的HotSpot VM或者每个JVM管理一个有特定标识的GC线程时.这些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值关联的操作系统或者Java线程，进而发现任何对CPI时间的高占用.未来的文章你将会了解到如何识别并诊断这样的问题.
　　#JNI全局引用计数
　　JNI(Java本地接口)的全局引用是从本地代码到由Java垃圾收集器管理的Java对象的基本的对象引用.它的角色是阻止对仍然在被本地代码使用，但是技术上已经不是Java代码中的“活动的”引用了的对象的垃圾收集.
　　同时为了侦测JNI相关的泄露而留意JNI引用也很重要.如果你的程序直接使用了JNI，或者像监听器这样的第三方工具，容易造成本地的内存泄露.
　　JNI global references:1925
　　#Java堆栈使用视图
　　这些数据被添加回了JDK 1.6，向你提供有关Hotspot堆栈的一个简短而快速的视图.我发现它在当我处理带有过高CPU占用的GC相关的问题时非常有用，你可以在一个单独的快照中同时看到线程堆栈以及Java堆的信息，让你当时可以在一个特定的Java堆内存空间中解析（或者排除）出任何的关键点.你如在我们的示例线程堆栈中所见，Java的堆OldGen超出了大值!
　　Heap
　　PSYoungGen 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)