JVM 问题排查

也可以通过查看gc日志来观察问题

如果CPU使用率不高，但程序性能低下，则可考虑对线程进行分析，看看各个主要的线程都在做什么，是否有锁争用或IO阻塞问题

为了方便分析，最好给每个线程或者线程池命名

如果JVM发现有死锁存在，会在日志中出现Found one Java-level deadlock

在等待一个条件的发生，来把自己唤醒，或者调用了sleep方法

此时线程状态：

WAITING(parking)： 一直等待那个条件发生

TIMED_WAITING(parking或sleeping)： 定时等待，即使条件不发生，时间到了也可以自己唤醒

如果发现大量线程处于此状态，并且从线程的堆栈上查看到是正在执行网络读写，这可能是一个网络瓶颈问题或者第三方响应慢的问题

线程所需要的资源长时间等待却一直无法获取，被标识为阻塞状态，可以理解为等待资源超时的线程。线程堆栈中一般存在Waiting to Lock

每个 Monitor在某个时刻，只能被一个线程拥有，该线程就是Active Thread，而其它线程都是Waiting Thread，分别在两个队列 Entry Set和Wait Set里面等候。 在Entry Set中等待的线程状态是Waiting for monitor entry，而在Wait Set中等待的线程状态是in Objectwait()。 当被调用notify或notifyAll时，只有在Wait Set中的线程会被唤醒

Waiting for monitor entry：等待进入一个临界区 ，所以它在Entry Set队列中等待。此时线程状态一般都是Blocked，如果存在大量线程在此状态，可能是一个全局锁阻塞住了大量线程。随着时间流逝，waiting for monitor entry的线程越来越多，没有减少的趋势，可能意味着某些线程在临界区里呆的时间太长了，以至于越来越多新线程迟迟无法进入临界区

当线程获得了Monitor，如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被 synchronized 的对象）的 wait() 方法，放弃了Monitor，进入Wait Set队列。此时线程状态大致为以下几种：TIMED_WAITING (on object monitor)和 WAITING (on object monitor)

有时候线程状态是Runnable，但却是在等待IO

性能分析之– JAVA Thread Dump 分析综述

三个实例演示 Java Thread Dump 日志分析

BEA JRockit Java虚拟机（JVM）所带来的不仅仅是性能的提升 本文探讨了JRockit R 版本可用的一些管理和使用方面的特性 概述了JRockit Mission Control分析工具套件 JRockit Management Console的试验性headless模式以及使用Ctrl Break Handler JRCMD 堆视图和code coverage与JVM进行交互

简介JRockit JVM不只是快 它还和JRockit Mission Control一起 组成一套执行运行时分析和内存泄漏检测的分析工具 JRockit Management Console包含在JRockit JDK中 本文将探讨JRockit Management Console的一种试验性的headless模式 它可以用于与来自命令行的基于JRockitJMX的管理代理进行交互 Ctrl Break Handler提供了一种向JRockit发送各种高级命令的方法 甚至是在它启动后 这些命令甚至可以远程调用 我在后文中会提及 最后 我探讨了试验性的code coverage JRockit开箱即用地提供了该特性

关于BEA JRockit的更多信息 参见dev dev网站的JRockit Product Center

首先我将快速概述一下JRockit JVM可用的已确定的管理工具 然后我会转向缺少文档的试验性管理特性

JRockit Mission ControlJRockit R 版本引入了JRockit Mission Control工具套件 它包含的工具可以进行监控 管理 分析和消除Java应用程序内存泄漏 而不会引起通常与此类工具相关联的性能开销 Mission Control的低性能开销是因为使用了作为JRockit常规适应性动态调优的一部分而收集的数据 这还可以消除工具使用字节码装置修改系统执行特性时发生Heisenberg异常的问题 JRockit Mission Control功能可以根据需要随时可用 低性能开销也只在运行工具时有效 这些特征使得JRockit Mission Control成为专门用于生产中系统的工具

JRockit Mission Control中包含以下工具

JRockit Management ConsoleJRockit Management Console用于监控和管理多个JRockit实例 它捕获并显示关于垃圾收集器（GC）暂停 内存和CPU使用的实时数据 以及部署在JVM内部MBean服务器上的所有JMX MBean的信息 JVM管理包括对CPU相似性 垃圾收集策略和内存池大小的动态控制 JRockit Runtime AnalyzerJRockit Runtime Analyzer（JRA）是一个随需应变的 动态记录器 它生成关于JVM和正在运行的应用程序的详细记录 然后可以使用JRA应用程序对记录下来的配置文件进行离线分析 所记录的数据包括对方法和锁定的分析 还有垃圾收集统计信息 优化决策以及对象统计信息 JRockit Memory Leak DetectorJRockit Memory Leak Detector工具用来发现和查找内存泄漏原因 Memory Leak Detector的趋势分析器可以发现非常缓慢的泄漏 显示详细的堆统计信息（包括指向泄漏对象和分配位置的引用类型和实例） 并快速找出泄漏原因 Memory Leak Detector使用先进的图形化表现技术 以便更容易定位和理解有时比较复杂的信息

关于JRockit Mission Control的更多信息 可以阅读文章An Introduction to JRockit Mission Control 或者访问dev dev网站的JRockit Mission Control

JRockit Management Console的Headless模式（试验性）

JRockit Management Console是监控JRockit运行的工具 它包括两部分 一个运行在JVM进程中的JMX代理 一个使用图形化用户界面的独立客户端（关于它以及其它方面的更详细的信息 请参见An Introduction to JRockit Mission Control） 其中 用户界面可以绘出部署在所连接的Java虚拟机中的任何MBean的数值属性的图形 图形密集的应用程序对资源的消耗可能会相当厉害 JRockit Management Console也不例外 可以引入text only（纯文本）模式 以便使用Management Console的通知功能和数据收集工具而不会导致整个GUI的开销

headless控制台引入了大量新的命令行参数 这同样适用于控制台的GUI版本 参数包括

参数 描述 headless 以headless模式启动控制台（不会加载与GUI相关的类） settings <settings file> 使用指定配置文舳H绻讷UI模式启动 并且该文件不存在 那么它将在关闭Management Console时创建 connectall 连接配置文件中所有可用连接（即原先使用GUI添加的） connect <connection > <connection > < > 使用GUI连接配置文件中可用的指定连接 autoconnect 自动连接到运行在启用JRockit发现协议（JRockit Discovery Protocol JDP）的管理服务器上的任何JRockit uptime <time in seconds> 将控制台运行一段指定的时间 然后自动关闭它 useraction <name> <delay in seconds> <period (optional)> 经过指定的时延后运行指定的用户动作 如果不指定period 动作将只执行一次 如果指定 动作将每过<period>秒就执行一次 version 打印Management Console的版本信息 并退出 locale <language> <country (optional)> 使用特定的地区启动控制台 比如 locale ja JP将以日语启动控制台（JRockit R 可用）

这里给出一个以headless模式启动Management Console的例子 读取指定配置文件 尝试连接所有已指定的JRockit 使用JRockit发现协议（JDP 下文讨论）积极查找新的JRockit 秒后将以每分钟一次的间隔向所有连接的JRockit发送Ctrl Break命令 一小时之后自动关闭 以前加入指定连接的所有通知规则（不管是通过使用GUI还是通过直接编辑配置文件添加的）将生效

java jar ManagementConsole jar headless settings C:\Headless\consolesettings xml connectall autoconnect uptime useraction ctrlbreak

用户动作是可以与JRockit Management Console上的一组连接进行交互的插件类 同样使用控制台配置文件来存储配置数据 用户动作显示在JRockit控制台图形用户界面的Plugins菜单下 headless模式中也可用 随控制台提供了两个默认用户动作 jrarecording用户动作 对连接的JRockit启动JRA记录 ctrlbreak用户动作 向连接的JRockit发送Ctrl Break命令（参见本文中关于Ctrl Break Handler和JRockit运行时分析器的小节） 要指定特定用户动作的参数 可以使用GUI进行配置 也可以编辑Management Console配置文件 后者可以在<user home>/ManagementConsole/ManagementConsole/consolesettings <version> xml文件中找到

编写自己的用户动作很容易 首先创建一个AbstractUserAction的子类 该示例演示了如何创建一个从所有连接的JRockit获取线程堆栈转储的用户动作

package example useractions; import java io IOException; import java util List; import nsole rjmx CommonRJMXNames; import nsole rjmx RJMXConnectorModel; import nsole useractions AbstractUserAction; / This is a simple user action getting stackdumps from the selected JRockits and printing them on stdout @author Marcus Hirt / public class MyUserAction extends AbstractUserAction { public void executeAction(List connections) { for (RJMXConnectorModel connection : connections) { if (connection isConnected()) { try { System out println(CommonRJMXNames getThreadMXBean(connection) getThreadStackDump()); } catch (IOException e) { e printStackTrace(); } } } } }

接下来 需要在consolesettings xml文件中配置部属描述符 以便用户动作对于控制台可用 可以在配置文件中发现user_actions元素 它已经填充了一些user_action元素 示例动作的部署描述符应当以相同的样式输入 描述符看起来会是这样

<user_action> <user_action_class> example useractions MyUserAction</user_action_class> <user_action_name>stackdump</user_action_name> <user_action_menu_name>Stack Dump on stdout</user_action_menu_name> <user_action_description>Gets a stack dump from the selected JRockit(s) and dumps it on stdout </user_action_description> </user_action>

这也使得用户动作在Plugins菜单下的用户界面中可见

当控制台启动或退出时 如果有设置/状态需要从配置文件加载/保存 只需重写exportToXml()/importFromXml()方法 如示例中所示

/ @see nsole util XmlEnabled #exportToXml( w c dom Element) / public void exportToXml(Element parentNode) { super exportToXml(parentNode); XmlToolkit setSetting(parentNode MY_PROPERTY m_myVal); } / @see nsole util XmlEnabled #initializeFromXml( w c dom Element) / public void initializeFromXml(Element parentNode) { super initializeFromXml(parentNode); m_myVal = XmlToolkit getSetting(parentNode MY_PROPERTY DEFAULT_MY_VALUE)); }

注意 用户动作的名称是使用launcher启动参数时将引用的用户动作名称 菜单名是会在GUI菜单中显示的名称 更多的信息请参见user action docs和JLMEXT docs 注意 这只是一个试验性的功能 提供的文档还相当简单 编写定制的通知动作和约束的方式与此类似 更多信息请参见Management Console User Guide

JRockit发现协议（JDP）JDP（JRockit发现协议）是个简单且有效的协议 用于允许JRockit管理服务器向Management Console组播它的存在 下面的两个表分别列出了在服务器端和客户端控制JDP行为的系统属性

管理服务器的JDP属性 系统属性 描述 默认值 jrockit managementserver autodiscovery 启用JRockit发现协议 False jrockit managementserver discovery period 在两个ping之间需要等待多久（以毫秒为单位） jrockit managementl 活跃的跃点数 jrockit managementserver discovery address 所使用的组播地址 jrockit managementserver discovery port 所使用的组播端口

Management Console的JDP属性 系统属性 描述 默认值 nsole preferences jdp port 用于JRockit发现协议的端口 nsole preferences jdp address 所使用的组播地址

这里给出了在服务器端启用JDP的情况下 启动JRockit需要最少参数的示例

java Xmanagement Djrockit managementserver autodiscovery=true<your program>

Ctrl Break Handler

您是否曾经希望在JVM启动后可以使用一种轻松的方式与其交互？假如说您忘记添加 Xmanagement选项来启动管理服务器 或者您想改变运行系统中GC的冗余级别 这些现在很容易通过重新配置Ctrl Break Handler来完成 而且它不只是打印堆栈跟踪

用法

创建一个名为ctrlhandler act的文件 向ctrlhandler act文件添加命令（参见下文命令列表） 以 stop 结束文件 这是结束文件分析的保留命令 按下ctrl break 每一个命令都将以出现的顺序执行

JRockit首先会在当前工作目录查找该文件 如果未找到 JRockit将在JVM目录中查找 如果仍然没有的话 JRockit将回退以生成一个常规的线程堆栈转储 JRockit将在每次按下ctrl break时读取act文件 因此用户可以在方便时重新配置该文件 而同时JRockit仍在运行

这里给出一个示例act文件 它首先打印时间戳 然后是用于启动JRockit的命令行 最后是一个线程堆栈转储 它还包括可以用于act文件的有用命令的列表

# Example ctrlhandler act file timestamp mand_line print_threads stop # set_filename filename=<file> [append=true] # Sets the file that all handlers following this mand will # use for printing You can have several set_filename mands # in a file It takes o arguments: filename and an optional # append to specify if you want to append to the file # or overwrite it Default is to overwrite the file # timestamp # Prints a timestamp # print_threads # The normal thread dump # verbosity [args=<ponents>] [filename=<file>] # Changes the verbosity level normally specified with Xverbose # version # Prints JRockit version information # mand_line # Prints the mand line used to start JRockit # print_object_summary # Prints heap usage statistics (how much heap is used per class) # together with a delta on how much this has changed since # the last invocation of this ctrl break handler # print_memusage # Prints a memory usage report of how JRockit is using # the memory # heap_diagnostics # Prints a detailed report of the heap including ascii graphics # over the heap layout # print_class_summary # Prints all loaded classes # print_utf pool # Print all UTF strings # jrarecording [filename=<file>] [time=<time>] [nativesamples=true] # Starts a JRA recording # run_optfile [filename=<file>] # See OptFile # start_management_server # Starts the new JMX based management agent # kill_management_server # Stops the management agent # start_rmp_server # Starts the old management server (actually the listening # socket that in turn starts servers whenever a connection # is established) # kill_rmp_server # Stops the old management server (actually shuts down the # listening socket) The only reason it isn t named # kill_rmp_server is that stop is a reserved keyword # that stops the parsing of the act file ;) # help [ctrl break handler] # Prints all available ctrl break handlers if no argument # is specified or help for the specified ctrl break handler # memleakserver [port=<port>] # Toggles the memleakserver If it hasn t been started # it will be started If it has already started it will be # shut down The default port is # verbose_referents action=[heap|full|nursery|start|stop] # Print verbose reference information # Parameters: # action=[heap|full|nursery|start|stop] # heap trigger a heap collection and output reference # information # full trigger a full heap collection (clears softly # reached soft referents) # nursery trigger a nursery collection (heap collection # if running without nursery) # start start writing reference information to default # verbose stream # stop stop writing reference information # print_exceptions # exceptions=[true|all|false] stacktraces=[true|all|false] # Enable printing of Java exceptions thrown in the VM # Parameters: # exceptions print exceptions # stacktraces print exceptions with stacktraces # At least one of the parameters is required # Values for the parameters can be true|all|false # true print all exceptions # except java/util/EmptyStackException # java/lang/ClassNotFoundException and # java/security/PrivilegedActionException # all print all exceptions # false don t print exceptions # To turn exception printing off pletely you need to set # exceptions = false even if it was turned # on by stacktraces = true JRCMD 使用JRCMD实用工具是一种新的调用Ctrl Break Handler的便捷方式 可在JRockit发行版的bin目录中找到它 用法 jrcmd <PID> <mand> <parameters>

JRCMD使用JRCMD实用工具是一种新的调用Ctrl Break Handler的便捷方式 可在JRockit发行版的bin目录中找到它

用法 jrcmd <PID> <mand> <parameters>

PID = 要在其中执行Ctrl Break Handler的JRockit进程的进程ID mand = 要执行的Ctrl Break Handler命令 parameters = Ctrl Break Handler的参数

如果不指定选项（或者只指定 P） 那么将显示运行在本地机器上的所有JRockit的进程ID 如果PID设为 那么命令将发送给在本地机器上运行的所有JRockit JVM

要列出特定的JRockit中有哪些Ctrl Break Handler可用 可以使用help命令

jrcmd <PID> help

要想获得某个具体的Ctrl Break Handler的帮助信息 需要在help后添加Ctrl Break Handler的名称 比如

jrcmd help kill_management_server

也可以使用JRCMD列出指定进程的性能计数

jrcmd <PID> l

远程调用Ctrl Break Handler可以使用JRockit Management Console来远程调用Ctrl Break Handler 存在一个对JRockitConsoleMBean的 *** 作 称为runCtrlBreakHandlerWithResult JRockit Management Console可以从属性浏览器调用对MBean的 *** 作 这里有关于如何调用Ctrl Break Handler的逐步描述

连接到一个运行中的JRockit 右击该连接 选择Browse Attributes 展开 jrockit domain文件夹 选择JRockitConsole MBean 单击operations选项卡 查看可用 *** 作 单击String parameter参数按钮 找到runCtrlBreakHandlerWithResult *** 作 输入希望执行的Ctrl Break Handler名称 语法与ctrlhandler act文件相同 按下OK 按下Execute按钮 执行 *** 作

试着输入 help 作为参数 将会列出所有可用的Ctrl Break Handler 如图 所示

图 从JRockit Management Console调用Ctrl Break Handler（单击查看大图）

堆视图（试验性）当分析应用程序如何使用某种垃圾收集策略时 在每一次GC后对堆进行快照将会非常有帮助 这有助于开发人员研究数据 比如碎片/压缩以及算法通常如何执行 但是快照中包含如此多的数据量以至于查看它没有什么意义 因此JRockit团队开发了一个提供图形化表示的小工具 以便更好地进行说明

图 显示了一个快照的例子（使用的是一个非常早的JRockit 预发布版本）

每一排表示一次垃圾收集 左边是开始的堆 右边是结束的堆 堆显示的右边是一个可配置图形 实心白 域表示空白堆 黑 域是充实区（也就是填充了对象的区域） 浅灰 域是碎片区 红色 **和绿 域是可配置图形 可以从命令行指定在可配置图形中显示什么 该工具依然很粗糙 对于用户也不够友好 不过毋庸置疑它对JRockit的终端用户非常有用 所以这是一个非常不错但是不能通用的工具

code coverage（试验性）很多开发人员在以某种方式使用他们的应用程序时 使用code coverage分析来研究诸如代码库中的多少以及哪些部分正在运行之类的状况 测试人员喜欢使用code coverage来度量测试套件覆盖应用程序的比例 但是 对于大型应用程序 由code coverage工具所引起的性能开销通常是被禁止的

JRockit内置了高性能的行code coverage 当启用code coverage运行时 代码将由记录行命中的捕获器生成 一旦某行被命中并记录 就删除捕获器 JRockit可以继续以接近全速的速度运行

要使JRockit记录code coverage数据 必须指定一个命令行选项

用法 Xcodecoverage

可以使用以下系统属性来控制该行为

系统属性 描述 decoverage filter=<filterspec> filterspec是个以分号（Windows）或冒号（Linux）隔开的筛选器字符串列表 它定义哪些类应当被覆盖 以 开头的筛选器字符串会被视为不应当覆盖的类

示例 decoverage filter=java/util/Hashtable;/bea/; /bea/bla

decoverage filterfile=<filename> 设置包含筛选器定义的文件的文件名 文件格式为每行一个筛选器字符串 decoverage outputfile=<filename> 设置存放输出的文件 如果写入<filename>_ 输出文件不能被打开 那么将尝试<filename>_ 以此类推 在多个JVM共享一个公共命令行的情况中 这可能会很有用 decoverage testid=<id string> 设置初始测试标识符 decoverage verbose 使code coverage更为详细 适用于在覆盖文件（均是纯文本文件）中执行文本比较 decoverage appendoutput 设置对输出文件的写入为追加而不是覆盖

这里给出特定于code coverage的参数 用于生成如下图中所示的数据

Xcodecoverage decoverage filter=/jrockit/console/;/jrockit/mon/ decoverage outputfile=console_coverage txt

在内部 由一个code coverage小工具来解释JRockit所生成的数据 如图 所示

图 code coverage工具的输出示例

lishixinzhi/Article/program/Java/hx/201311/26298

Jstat名称：Java Virtual Machine statistics monitoring tool

功能描述：

Jstat是JDK自带的一个轻量级小工具。它位于java的bin目录下，主要利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对Heap size和垃圾回收状况的监控。

命令用法：jstat [-命令选项] [vmid] [间隔时间/毫秒] [查询次数]

注意：使用的jdk版本是jdk8。

C:\Users\Administrator>jstat -helpUsage: jstat -help|-options jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]] Definitions: <option> An option reported by the -options option <vmid> Virtual Machine Identifier A vmid takes the following form: <lvmid>[@<hostname>[:<port>]] Where <lvmid> is the local vm identifier for the target Java virtual machine, typically a process id; <hostname> is the name of the host running the target Java virtual machine; and <port> is the port number for the rmiregistry on the target host See the jvmstat documentation for a more complete description of the Virtual Machine Identifier <lines> Number of samples between header lines <interval> Sampling interval The following forms are allowed: <n>["ms"|"s"] Where <n> is an integer and the suffix specifies the units as milliseconds("ms") or seconds("s") The default units are "ms" <count> Number of samples to take before terminating -J<flag> Pass <flag> directly to the runtime system

option：参数选项

-t：可以在打印的列加上Timestamp列，用于显示系统运行的时间

-h：可以在周期性数据输出的时候，指定输出多少行以后输出一次表头

vmid：Virtual Machine ID（ 进程的 pid）

interval：执行每次的间隔时间，单位为毫秒

count：用于指定输出多少次记录，缺省则会一直打印

option 可以从下面参数中选择

jstat -options

-class 用于查看类加载情况的统计

-compiler 用于查看HotSpot中即时编译器编译情况的统计

-gc 用于查看JVM中堆的垃圾收集情况的统计

-gccapacity 用于查看新生代、老生代及持久代的存储容量情况

-gcmetacapacity 显示metaspace的大小

-gcnew 用于查看新生代垃圾收集的情况

-gcnewcapacity 用于查看新生代存储容量的情况

-gcold 用于查看老生代及持久代垃圾收集的情况

-gcoldcapacity 用于查看老生代的容量

-gcutil 显示垃圾收集信息

-gccause 显示垃圾回收的相关信息（通-gcutil）,同时显示最后一次仅当前正在发生的垃圾收集的原因

-printcompilation 输出JIT编译的方法信息

示例：

1-class 类加载统计

[root@hadoop ~]# jps #先通过jps获取到java进程号（这里是一个zookeeper进程）3346 QuorumPeerMain7063 Jps[root@hadoop ~]# jstat -class 3346 #统计JVM中加载的类的数量与sizeLoaded Bytes Unloaded Bytes Time 1527 28427 0 00 102

Loaded:加载类的数量

Bytes：加载类的size，单位为Byte

Unloaded：卸载类的数目

Bytes：卸载类的size，单位为Byte

Time：加载与卸载类花费的时间

2-compiler 编译统计

[root@hadoop ~]# jstat -compiler 3346 #用于查看HotSpot中即时编译器编译情况的统计Compiled Failed Invalid Time FailedType FailedMethod 404 0 0 019 0

Compiled：编译任务执行数量

Failed：编译任务执行失败数量

Invalid：编译任务执行失效数量

Time：编译任务消耗时间

FailedType：最后一个编译失败任务的类型

FailedMethod：最后一个编译失败任务所在的类及方法

3-gc 垃圾回收统计

[root@hadoop ~]# jstat -gc 3346 #用于查看JVM中堆的垃圾收集情况的统计 S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 1280 1280 00 1280 10240 9198 151040 20424 84480 81304 10240 9960 7 0019 0 0000 0019

S0C：年轻代中第一个survivor（幸存区）的容量 （字节）

S1C：年轻代中第二个survivor（幸存区）的容量 (字节)

S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (字节)

S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (字节)

EC：年轻代中Eden（伊甸园）的容量 (字节)

EU：年轻代中Eden（伊甸园）目前已使用空间 (字节)

OC：Old代的容量 (字节)

OU：Old代目前已使用空间 (字节)

MC：metaspace(元空间)的容量 (字节)

MU：metaspace(元空间)目前已使用空间 (字节)

CCSC：当前压缩类空间的容量 (字节)

CCSU：当前压缩类空间目前已使用空间 (字节)

YGC：从应用程序启动到采样时年轻代中gc次数

YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)

FGC：从应用程序启动到采样时old代(全gc)gc次数

FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)

GCT：从应用程序启动到采样时gc用的总时间(s)

4-gccapacity 堆内存统计

[root@hadoop ~]# jstat -gccapacity 3346 #用于查看新生代、老生代及持久代的存储容量情况 NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC 12800 832640 12800 1280 1280 10240 151040 1665920 151040 151040 00 10567680 84480 00 10485760 10240 7 0[root@hadoop ~]# jstat -gccapacity -h5 3346 1000 #-h5：每5行显示一次表头 1000：每1秒钟显示一次，单位为毫秒 NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC 12800 832640 12800 1280 1280 10240 151040 1665920 151040 151040 00 10567680 84480 00 10485760 10240 7 0 12800 832640 12800 1280 1280 10240 151040 1665920 151040 151040 00 10567680 84480 00 10485760 10240 7 0 12800 832640 12800 1280 1280 10240 151040 1665920 151040 151040 00 10567680 84480 00 10485760 10240 7 0 12800 832640 12800 1280 1280 10240 151040 1665920 151040 151040 00 10567680 84480 00 10485760 10240 7 0 12800 832640 12800 1280 1280 10240 151040 1665920 151040 151040 00 10567680 84480 00 10485760 10240 7 0 NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC 12800 832640 12800 1280 1280 10240 151040 1665920 151040 151040 00 10567680 84480 00 10485760 10240 7 0 12800 832640 12800 1280 1280 10240 151040 1665920 151040 151040 00 10567680 84480 00 10485760 10240 7 0 12800 832640 12800 1280 1280 10240 151040 1665920 151040 151040 00 10567680 84480 00 10485760 10240 7 0 12800 832640 12800 1280 1280 10240 151040 1665920 151040 151040 00 10567680 84480 00 10485760 10240 7 0

NGCMN：年轻代(young)中初始化(最小)的大小(字节)

NGCMX：年轻代(young)的最大容量 (字节)

NGC：年轻代(young)中当前的容量 (字节)

S0C：年轻代中第一个survivor（幸存区）的容量 (字节)

S1C：年轻代中第二个survivor（幸存区）的容量 (字节)

EC：年轻代中Eden（伊甸园）的容量 (字节)

OGCMN：old代中初始化(最小)的大小 (字节)

OGCMX：old代的最大容量(字节)

OGC：old代当前新生成的容量 (字节)

OC：Old代的容量 (字节)

MCMN：metaspace(元空间)中初始化(最小)的大小 (字节)

MCMX：metaspace(元空间)的最大容量 (字节)

MC：metaspace(元空间)当前新生成的容量 (字节)

CCSMN：最小压缩类空间大小

CCSMX：最大压缩类空间大小

CCSC：当前压缩类空间大小

YGC：从应用程序启动到采样时年轻代中gc次数

FGC：从应用程序启动到采样时old代(全gc)gc次数

5-gcmetacapacity 元数据空间统计

[root@hadoop ~]# jstat -gcmetacapacity 3346 #显示元数据空间的大小MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC FGCT GCT00 10567680 84480 00 10485760 10240 8 0 0000 0020

MCMN：最小元数据容量

MCMX：最大元数据容量

MC：当前元数据空间大小

CCSMN：最小压缩类空间大小

CCSMX：最大压缩类空间大小

CCSC：当前压缩类空间大小

YGC：从应用程序启动到采样时年轻代中gc次数

FGC：从应用程序启动到采样时old代(全gc)gc次数

FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)

GCT：从应用程序启动到采样时gc用的总时间(s)

6-gcnew 新生代垃圾回收统计

[root@hadoop ~]# jstat -gcnew 3346 #用于查看新生代垃圾收集的情况S0C S1C S0U S1U TT MTT DSS EC EU YGC YGCT1280 1280 678 00 1 15 640 10240 3622 8 0020

S0C：年轻代中第一个survivor（幸存区）的容量 (字节)

S1C：年轻代中第二个survivor（幸存区）的容量 (字节)

S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (字节)

S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (字节)

TT：持有次数限制

MTT：最大持有次数限制

DSS：期望的幸存区大小

EC：年轻代中Eden（伊甸园）的容量 (字节)

EU：年轻代中Eden（伊甸园）目前已使用空间 (字节)

YGC：从应用程序启动到采样时年轻代中gc次数

YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)

7-gcnewcapacity 新生代内存统计

[root@hadoop ~]# jstat -gcnewcapacity 3346 #用于查看新生代存储容量的情况NGCMN NGCMX NGC S0CMX S0C S1CMX S1C ECMX EC YGC FGC12800 832640 12800 83200 1280 83200 1280 666240 10240 8 0

NGCMN：年轻代(young)中初始化(最小)的大小(字节)

NGCMX：年轻代(young)的最大容量 (字节)

NGC：年轻代(young)中当前的容量 (字节)

S0CMX：年轻代中第一个survivor（幸存区）的最大容量 (字节)

S0C：年轻代中第一个survivor（幸存区）的容量 (字节)

S1CMX：年轻代中第二个survivor（幸存区）的最大容量 (字节)

S1C：年轻代中第二个survivor（幸存区）的容量 (字节)

ECMX：年轻代中Eden（伊甸园）的最大容量 (字节)

EC：年轻代中Eden（伊甸园）的容量 (字节)

YGC：从应用程序启动到采样时年轻代中gc次数

FGC：从应用程序启动到采样时old代(全gc)gc次数

8-gcold 老年代垃圾回收统计

[root@hadoop ~]# jstat -gcold 3346 #用于查看老年代及持久代垃圾收集的情况MC MU CCSC CCSU OC OU YGC FGC FGCT GCT84480 82275 10240 10037 151040 21022 8 0 0000 0020　

MC：metaspace(元空间)的容量 (字节)

MU：metaspace(元空间)目前已使用空间 (字节)

CCSC：压缩类空间大小

CCSU：压缩类空间使用大小

OC：Old代的容量 (字节)

OU：Old代目前已使用空间 (字节)

YGC：从应用程序启动到采样时年轻代中gc次数

FGC：从应用程序启动到采样时old代(全gc)gc次数

FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)

GCT：从应用程序启动到采样时gc用的总时间(s)

9-gcoldcapacity 老年代内存统计

[root@hadoop ~]# jstat -gcoldcapacity 3346 #用于查看老年代的容量OGCMN OGCMX OGC OC YGC FGC FGCT GCT151040 1665920 151040 151040 8 0 0000 0020

OGCMN：old代中初始化(最小)的大小 (字节)OGCMX：old代的最大容量(字节)OGC：old代当前新生成的容量 (字节)OC：Old代的容量 (字节)YGC：从应用程序启动到采样时年轻代中gc次数FGC：从应用程序启动到采样时old代(全gc)gc次数FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)GCT：从应用程序启动到采样时gc用的总时间(s) 在此我向大家推荐一个架构学习交流圈。交流学习指导伪鑫：1253431195（里面有大量的面试题及答案）里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

10-gcutil 垃圾回收统计

[root@hadoop ~]# jstat -gcutil 3346 #显示垃圾收集信息S0 S1 E O M CCS YGC YGCT FGC FGCT GCT5297 000 4210 1392 9739 9802 8 0020 0 0000 0020　

S0：年轻代中第一个survivor（幸存区）已使用的占当前容量百分比

S1：年轻代中第二个survivor（幸存区）已使用的占当前容量百分比

E：年轻代中Eden（伊甸园）已使用的占当前容量百分比

O：old代已使用的占当前容量百分比

M：元数据区已使用的占当前容量百分比

CCS：压缩类空间已使用的占当前容量百分比

YGC ：从应用程序启动到采样时年轻代中gc次数

YGCT ：从应用程序启动到采样时年轻代中gc所用时间(s)

FGC ：从应用程序启动到采样时old代(全gc)gc次数

FGCT ：从应用程序启动到采样时old代(全gc)gc所用时间(s)

GCT：从应用程序启动到采样时gc用的总时间(s)

11-gccause

[root@hadoop ~]# jstat -gccause 3346 #显示垃圾回收的相关信息（通-gcutil）,同时显示最后一次或当前正在发生的垃圾回收的诱因S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC5297 000 4609 1392 9739 9802 8 0020 0 0000 0020 Allocation Failure No GC

LGCC：最后一次GC原因

GCC：当前GC原因（No GC 为当前没有执行GC）

12-printcompilation JVM编译方法统计

[root@hadoop ~]# jstat -printcompilation 3346 #输出JIT编译的方法信息Compiled Size Type Method421 60 1 sun/nio/ch/Util$2 clear

Compiled：编译任务的数目

Size：方法生成的字节码的大小

Type：编译类型

Method：类名和方法名用来标识编译的方法。类名使用/做为一个命名空间分隔符。方法名是给定类中的方法。上述格式是由-XX:+PrintComplation选项进行设置的

远程监控

与jps一样，jstat也支持远程监控，同样也需要开启安全授权，方法参照jps。

C:\Users\Administrator>jps 1921681461283346 QuorumPeerMain3475 JstatdC:\Users\Administrator>jstat -gcutil 3346@192168146128 S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 5297 000 6515 1392 9739 9802 8 0020 0 0000 0020

可以使用对象的toString（）方法，回返回一个字符串，字符串后半部分的哈希码就是唯一的。

toString

public String toString()返回该对象的字符串表示。通常，toString 方法会返回一个“以文本方式表示”此对象的字符串。结果应是一个简明但易于读懂。建议所有子类都重写此方法。

Object 类的 toString 方法返回一个字符串，该字符串由类名（对象是该类的一个实例）、at 标记符“@”和此对象哈希码的无符号十六进制表示组成。换句话说，该方法返回一个字符串，它的值等于：

getClass()getName() + '@' + IntegertoHexString(hashCode())

返回：

该对象的字符串表示形式。

以上就是关于JVM 问题排查全部的内容，包括:JVM 问题排查、JROCKIT 5.0——轻松玩转JVM、jvm 性能调优工具之 jstat 命令详解等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！