bingoogolapple.github.io
bingoogolapple.github.io copied to clipboard
bingoogolapple
JVM 监控工具
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
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
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
JVisualVM
JVisualVM 安装 MBeans 插件的步骤：工具(T) – 插件(G) …… 其他插件的安装过程基本一致
jvisualvm
JVisualVM 分配分析
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 之后仍然接近全满，程序性能就会大幅降低，可能是资源不足或者内存泄漏。这种症状会对吞吐量产生严重影响
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 就能看见是在哪里创建的