java虚拟机堆栈-JavaVM概述及基础知识线程堆栈分析案例分析

一、如何开始

我的建议是跟随我来完成这个线程分析学习。下面是我们会覆盖到的内容。同时，我会把我工作中的实际案例分享给大家，以方便大家学习和理解。

线程堆栈概述及基础知识

线程堆栈的生成原理以及相关工具

不同JVM线程堆栈的格式的差异（Sun HotSpot、IBM JRE、Oracal JRockit）

线程堆栈日志介绍以及解析方法

线程堆栈分析和相关的技术

常见的问题模板（线程竞争、死锁、IO调用挂起、垃圾回收/OutOfMemoryError、死循环等）

线程堆栈问题实例分析

二、有问题或困难怎么办？

上百度.....

三、Java VM 概述

Java虚拟机是Java、J2EE等平台的运行基础，它是中间件或应用程序运行的地方。JVM向中间件软件（如应用服务器、Web容器）和你的Java/J2EE程序提供了下面的能力:

JVM可以在许多的操作系统 (Solaris, AIX, Windows 等等.)上运行。你可以根据你的物理服务器性能在每台物理/虚拟机上运行1到多个JVM进程。

四、JVM与中间件（应用服务器、Web容器）之间的交互

下面这张图展示了JVM、中间件和应用程序之间的高层交互模型。

图中展示的JVM、中间件（应用服务器、Web容器）和应用程序件之间的简单和典型的交互过程。如你所见，标准J2EE应用程序线程的分配是在中间件内核与JVM之间完成的。（当然也有例外，应用程序可以直接调用API来创建线程，这种做法并不常见，而且在使用的过程中也要特别的小心）

同时，请注意一些线程是由JVM创建并管理的，典型的例子就是垃圾回收线程，JVM内部使用这个线程进行垃圾回收处理。

因为大多数的线程分配都是由J2EE容器完成的，所以一个非常重要的技能要求是：能够理解和认识线程堆栈的跟踪信息(Thread Stack Trace)，并能从线程堆栈数据中识别出跟踪信息。这可以让你能够快速的知道J2EE容器执行什么类型的操作。

从线程转储堆栈分析的角度来看，你将能了解JVM各种不同的线程池之间的区别，并根据以上信息识别出操作的类型。

最后一节会介绍HotSop VM的线程转储堆栈(Thread Dump）以及转储堆栈中各种不同的线程的相关内容。

五、什么是JVM线程堆栈?

JVM线程堆栈JVM线程在特定时间的快照，它能向你提供当前所有Java线程的完整清单，堆栈中每个Java线程都显示如下信息:

线程的名称；经常被中间件厂商用来作为线程的标识，一般还会带上线程池的名称以及状态 (运行，阻塞等等.)

线程类型 & 优先级：例如，daemon prio=3 中间件程序一般以守护线程的形式创建他们的线程，这意味着这些线程是在后台运行的；它们会向它们的用户提供服务，例如：向你的Java EE应用程序

线程ID：例如，tid=0x000000011e52a800，线程ID可以通过java.lang.Thread.getId()获得，线程ID一般用从自增整数。

原生线程ID：例如，nid=0x251c，原生线程ID很关键java虚拟机堆栈，因为原生线程ID可以让你能够从操作系统获得线程所消耗的CPU时间等等这类信息。

Java线程状态和详细信息：例如: waiting for monitor entry [0xfffffffea5afb000] java.lang.Thread.State: BLOCKED (on object monitor)

可以快速的了解到线程状态极其当前阻塞的可能原因

Java线程栈跟踪信息；这是线程堆栈中最重要的数据. 也是你需要花费最多时间分析的地方。因为Java栈跟踪向提供了你所需要的90%的信息，稍后的环节我们将通过分析线程堆栈跟踪信息了解大部分问题的根本原因。

Java 堆内存分解：从HotSpot VM 1.6开始，在线程堆栈的末尾处可以看到HotSpot的内存使用情况，比如说Java的堆内存(YoungGen, OldGen)和PermGen空间。这些信息在分析频繁GC引起的问题时非常有用。你可以使用已知的线程数据或模式进行快速定位。

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)

六、线程堆栈信息大拆解

为了让大家更好的理解java虚拟机堆栈，给大家提供了下面的这张图，在这张图中将HotSpot VM上的线程堆栈信息和线程池做了详细的拆解，如下图所示：

上图中可以看出线程堆栈是由多个不同部分组成的。这些信息对问题分析都很重要，但对不同的问题模式的分析会使用不同的部分（问题模式会在后面的文章中做模拟和演示。）

现在通过这个分析样例，给大家详细解释一下HoteSpot上线程堆栈信息中的各个组成部分：

1. Full thread dump标示符:

“Full thread dump”是一个全局唯一的关键字，你可以在中间件和单机版本Java的线程堆栈信息的输出日志中找到它（比如说在UNIX下使用：kill -3

）。这是线程堆栈快照的开始部分。

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

2. Java EE 中间件,第三方以及自定义应用软件中的线程:

这个部分是整个线程堆栈的核心部分，也是通常需要花费最多分析时间的部分。堆栈中线程的个数取决你使用的中间件，第三方库（可能会有独立线程）以及你的应用程序（如果创建自定义线程，这通常不是一个很好的实践）。

在我们的示例线程堆栈中，我们使用WebLogic中间件。从Weblogic 9.2开始, Weblogic使用一个由“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)

3. HotSpot VM 线程

这是一个有Hotspot VM管理的内部线程，用于执行内部的原生操作。一般你不用太关心这个线程，除非你(通过相关的线程堆栈以及 prstat或者原生线程Id)发现它占用了很高的CPU使用率。

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

4. HotSpot GC 线程

当使用 HotSpot 进行并行GC(如今在使用多个物理核心的环境下很常见), 默认创建的HotSpot VM或者每个JVM管理一个有特定标识的GC线程时。 这些GC线程可以以并行的方式执行其周期性的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来关联OS或者Java进程，进而发现任何占用CPU时间的高操作。后面将会介绍如何识别并诊断这样的问题。

5. JNI 全局引用计数

JNI (Java 本地接口)的全局引用就是从本地代码到由Java垃圾收集器管理的Java对象的基本的对象引用。它的角色就是阻止对仍然被本地代码使用，但是技术上已经不是Java代码中的“活动的”引用对象的垃圾收集。

因此，为了侦测JNI相关的泄露而留意JNI引用也很重要。如果你的程序直接使用了JNI，或者像监听器这样的第三方工具，就容易造成本地的内存泄露。

JNI global references: 1925

6. Java 堆栈使用视图

这些数据在JDK 1.6中被重新添加，向你提供有关Hotspot堆栈的一个简短而快速的视图。我发现它在处理有过高CPU占用的GC问题时非常有用，你可以在一个单独的快照中同时看到线程堆栈以及Java堆的信息，让你可以快速的在一个特定的Java堆内存空间中分析（或者排除）出任何的关键点。正如在示例线程堆栈中那样，Java的堆OldGe超出了最大值!

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)