JVM 监控工具

[bingoogolapple]

jps Java命令学习系列（一）jps

用来查看 JVM 里面所有进程的具体状态, 包括进程 ID，进程启动的路径等等。与 unix 上的 ps 类似，用来显示本地的 java 进程，可以查看本地运行着几个 java 程序，并显示他们的进程号

• -q 只显示pid，不显示class名称,jar文件名和传递给main 方法的参数
• -m 输出传递给main 方法的参数，在嵌入式jvm上可能是null
• -l 输出应用程序main class的完整package名 或者 应用程序的jar文件完整路径名
• -v 输出传递给JVM的参数

  列出本机所有 JVM 实例

jps

列出远程服务器 192.168.1.110 所有的 JVM 实例，采用 RMI 协议，默认连接端口为1099

jps 192.168.1.110

[bingoogolapple]

jconsole

一个图形化界面，可以观察到 Java 进程的 GC、class、内存等信息

[bingoogolapple]

jinfo

观察运行中的 Java 程序的运行环境参数,包括 Java System 属性和 JVM 命令行参数

jinfo 14304
jinfo -flag NewSize 17832

[bingoogolapple]

jstack

可以观察到 JVM 中当前所有线程的运行情况和线程当前状态

jstack 14304

[bingoogolapple]

jmap

观察运行中的 JVM 物理内存的占用情况 参数如下：

• -heap 打印 JVM heap 的情况
• -histo 打印 JVM heap 的直方图。其输出信息包括类名，对象数量，对象占用大小
• -histo:live 同上，但是只打印存活对象的情况

jmap -heap 5412
jmap -heap `jps -v | grep tomcat-8000 | awk '{print $1}'`

jmap -histo:live 14304

将内存使用的详细情况输出到文件，并在浏览器中查看

jmap -dump:format=b,file=heapDump 14304
jhat -port 5000 heapDump

[bingoogolapple]

jstat java高分局之jstat命令使用

这是 JDK 命令中比较重要，也是相当实用的一个命令，可以观察到 ClassLoader，Compiler，gc 相关信息，具体参数如下：

• -class 统计 ClassLoader 行为信息

• -gc 统计jdk gc 时 heap 信息

• -gccapacity 统计不同的 generations 相应的 heap 容量情况

• -gccause 统计 gc 的情况和引起 gc 的事件

• -gcnew 统计 gc 时，新生代的情况

• -gcnewcapacity 统计 gc 时，新生代 heap 容量

• -gcold 统计 gc 时，老年区的情况

• -gcoldcapacity 统计 gc 时，老年区 heap 容量

• -gcpermcapacity 统计 gc 时，permanent 区 heap 容量

• -gcutil 统计 gc 时，heap 情况

• S0 Heap 上的 Survivor space 0 区已使用空间的百分比

• S1 Heap 上的 Survivor space 1 区已使用空间的百分比

• E Heap 上的 Eden space 区已使用空间的百分比

• O Heap 上的 Old space 区已使用空间的百分比

• M 元数据区使用比例

• CCS 压缩使用比例

• YGC 从应用程序启动到采样时发生 Young GC 的次数

• YGCT 从应用程序启动到采样时 Young GC 所用的时间(单位秒)

• FGC 从应用程序启动到采样时发生 Full GC 的次数

• FGCT 从应用程序启动到采样时 Full GC 所用的时间(单位秒)

• GCT 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)

每秒钟一次，一共5次，-h3 表示每三行打印一下标题，最后一个参数不指定则一直打印

jstat -gc 14304
jstat -gc 14304 1000 5
jstat -gcutil -h3 14304 1000 9

• 最后一列「GCT」，与 JVM 的总运行时间「Timestamp」的比值就是「GC」的开销。如果每一秒内，「GCT」的值都会明显增大，与总运行时间相比，就暴露出 GC 开销过大的问题。不同系统对 GC 开销有不同的容忍度，由性能需求决定，一般来讲，超过 10% 的 GC 开销都是有问题的
• 「YGC」和「FGC」列的快速变化往往也是有问题的征兆。频繁的 GC 暂停会累积，并导致更多的线程停顿（stop-the-world pauses），进而影响吞吐量
• 如果看到「OU」列中老年代的使用量约等于老年代的最大容量「OC」，并且不降低的话，就表示虽然执行了老年代 GC，但基本上属于无效 GC

[bingoogolapple]

JVisualVM

JVisualVM 安装 MBeans 插件的步骤：工具(T) – 插件(G) …… 其他插件的安装过程基本一致

jvisualvm

JVisualVM 分配分析

[bingoogolapple]

Java Mission Control

jmc

[bingoogolapple]

GCViewer

java -jar gcviewer_1.3.4.jar gc.log

java -jar gcviewer_1.3.4.jar gc.log summary.csv chart.png

Chart

• 蓝色线条表示堆内存的使用情况
• 黑色的 Bar 则表示每次 GC 暂停时间的长短

GCViewer 能用图形界面快速展现异常的 GC 行为。一般来说，图像化信息能迅速揭示以下症状：

• 低吞吐量。当应用的吞吐量下降到不能容忍的地步时，有用工作的总时间就大量减少。具体有多大的容忍度取决于具体场景。按照经验，低于 90% 的有效时间就值得警惕了，可能需要好好优化下 GC
• 单次 GC 的暂停时间过长。只要有一次 GC 停顿时间过长，就会影响程序的延迟指标。例如，延迟需求规定必须在 1000 ms 以内完成交易，那就不能容忍任何一次 GC 暂停超过 1000 ms
• 堆内存使用率过高。如果老年代空间在 Full GC 之后仍然接近全满，程序性能就会大幅降低，可能是资源不足或者内存泄漏。这种症状会对吞吐量产生严重影响

[bingoogolapple]

Hyprof

java -jar -agentlib:hprof=heap=sites -Xms2g -Xmx2g -Xss256k -XX:+UseG1GC -Xloggc:./log/G1.log -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintGCDetails tuning-1.0.jar

• 在程序退出时,会将分配信息 dump (转储)到工作目录下的 java.hprof.txt 文件中。使用文本编辑器打开, 并搜索「SITES BEGIN」关键字，找到 selft 占用最多的 trace 对应的数字 xxxNumber，然后搜索 TRACE xxxNumber 就能看见是在哪里创建的

[bingoogolapple]

Aprof

[bingoogolapple]

http://blog.csdn.net/renfufei/article/details/56678064