jvm排查问题工具

延迟 ： 也可以理解为最大停顿时间，即垃圾收集过程中一次 STW 的最长时间，越短越好，一定程度上可以接受频次的增大

吞吐量 ：应用系统的生命周期内，由于 GC 线程会占用 当前可用的 CPU 时钟周期，吞吐量即为 有效花费的时间占系统总运行时间的百分比

评判 GC 的两个核心指标

jps主要用来输出JVM中运行的进程状态信息

如果不指定hostid就默认为当前主机或服务器。

-q 不输出类名、Jar名和传入main方法的参数

-m 输出传入main方法的参数

-l 输出main类或Jar的全限名

-v 输出传入JVM的参数

语法格式：   jps [options] pid

子主题

jps

jps -v

示例

JPS进程信息

jinfo是实时地查看和调整虚拟机各种参数。

jinfo -sysprops pid 或者 jinfo  pid 输出当前 jvm 进行的全   部的系统属性

jinfo -flag xx pid 输出指定参数

语法格式：jinfo [options] pid

JINFO查看jvm配置信息

对Java应用程序的资源和性能进行实时的监控

generalOption: 一般使用-gcutil查看GC情况

vmid: 虚拟机进程号，即当前运行的java进程号

interval: 间隔时间，单位为秒或毫秒

count: 打印次数，如果缺省则打印无数次

语法格式如下：jstat generalOption vmid， [ interva，count ]

每秒统计1次，共同机5次

查询GC总体使用情况：jstat -gcutil pid1000 5

垃圾总体回收统计：jstat -gc pid1000 5

新生代垃圾回收统计：jstat -gcnew pid 1000 5

堆内存统计：jstat -gccapacity pid1000 5

新生代堆内存统计：jstat -gcnewcapacity pid1000 5

老年代统计：jstat -gcoldcapacity pid1000 5

其他命令

jstat查看虚拟机运行状态

用于生成虚拟机当前的线程快照

jstack [-l] <pid>

jstack -F [-m] [-l] <pid>

jstack [-m] [-l] <executable> <core>

用法

main 线程名称

prio 线程优先级

tid JVM线程的id

nid 系统线程id

线程处于死锁状态，将占用系统大量资源。

deadlock 死锁

runnable 线程正在执行状态中

blocked 阻塞状态

系统线程处于此种状态说明它在等待另一个条件的发生来唤醒自己，或者自己调用了sleep()方法。如果大量线程处于此种状态，说明这些线程又去获取第三方资源了，比如第三方的网络资源或读取数据库的操作，长时间无法获得响应，导致大量线程进入等待状态。因此，这说明系统处于一个网络瓶颈或读取数据库操作时间太长

waiting on condition 线程正处于等待资源或等待某个条件的发生

系统线程处于这种状态说明它在等待进入一个临界区，此时JVM线程的状态通常都是 java.lang.Thread.State: BLOCKED 如果大量线程处于这种状态的话，可能是一个全局锁阻塞了大量线程。如果短期内多次打印Thread Dump信息，发现 waiting for monitor entry 状态的线程越来越多，没有减少的趋势，可能意味着某些线程在临界区里呆得时间太长了，以至于越来越多新线程迟迟无法进入

waiting for monitor entry 或 in Object.wait()  线程在互斥和协作过程中

系统线程状态包括

waiting on condition 系统线程状态

[0x000...25000] 起始栈地址 线程堆栈调用的其实内存地址

NEW 线程刚被创建，但尚未启动

RUNNABLE 可运行线程的线程状态

running 可运行状态(runnable)的线程获得了cpu 时间片（timeslice） 执行程序代码

blocked 受阻塞并且正在等待监视器的某一线程的线程状态

WAITING 线程正在无期限地等待另一个线程来执行某一个特定的操作

TIMED_WAITING 指定了等待时间的某一等待线程的线程状态

TERMINATED 线程处于终止状态

线程状态

TIME_WAITING VM线程状态

概要

jstack 7 | grep ‘47365’查询进程为7的所有线程信息，并过滤出线程信息中包含47365的线程

jstack线程分析工具

-l  (long listing)长列表模式. 额外打印关于锁的信息

-m  (mix)混合模式，可以打印 Java 栈和本地方法栈

-F 强制打印线程栈信息，在jstack <pid>命令没有响应的时候添加该选项可以实现强制打印

参数说明

一方面是获取dump文件（堆转储快照文件，二进制文件），它还可以获取目标Java进程的内存相关信息，包括Java堆各区域的使用情况、堆中对象的统计信息、类加载信息等

-dump  生成dump文件   

-heap   输出整个堆空间的详细信息，包括GC的使用、堆配置信息，以及内存的使用信息等

-histo  输出堆空间中对象的统计信息，包括类、实例数量和合计容量

jmap [option] pid

jmap内存快照工具

最耗CPU的进程PID为291684

top

找到最耗CPU进程

指定进程内，最耗CPU的线程PID为291685

之所以要转化为16进制，是因为堆栈里，线程id是用16进制表示的

将线程PID转化为16进制：printf \"%x\\" 291685

top -Hp pid（docker环境这个命令可能有问题）

找到最耗CPU线程

jstack 291684 | grep '47365'

查看堆栈 定位线程在做什么，定位对应代码

cpu异常飙高问题

有可能是内存分配确实过小，而正常业务使用了大量内存

某一个对象被频繁申请，却没有释放，内存不断泄漏，导致内存耗尽

某一个资源被频繁申请，系统资源耗尽，例如：不断创建线程，不断发起网络连接

常见的原因：

可以查看新生代，老生代堆内存的分配大小以及使用情况，看是否本身分配过小。

1.确认是不是内存本身就分配过小jmap -heap 11155

jmap -histo:live 11155| more会以表格的形式显示存活对象的信息，并按照所占内存大小排序

-XX:+HeapDumpOnOutOfMemoryErrorOOM的时候自动dump内存快照出来

-XX:HeapDumpPath=/usr/local/app/oom把内存快照放到哪儿去

也可以通过配置自动实现导出文件

2.找到最耗内存的对象

pstree

netstat

3.确认是否是资源耗尽

分析步骤

查看进程创建的线程数，以及网络连接数，如果资源耗尽

内存OOM

常见问题排

常用命令

wget https://arthas.aliyun.com/arthas-boot.jar下载

java -jar arthas-boot.jar启动arthas

安装

thread -n 3最忙的前N个线程并打印堆栈

thread -n 3 -i 5000查看5秒内的CPU使用率top n线程栈

thread -b找出当前阻塞其他线程的线程

thread列出所有线程

top N线程

输入 Q 或者 Ctrl+C 可以退出dashboard命令

quit

dashboard查看当前系统的实时数据面板

JVMJVM的各种详细信息

arthas

-Xms -Xmx  -XX:NewSize  -XX:NewRatio  -XX:SurvivorRatio  -XX:MaxPermSize

堆内存大小设置

-XX:+CMSIncrementalMode

垃圾收集器设置

-XX:+PrintGC    

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-Xloggc:filename

垃圾回收统计信息

常用调优配置

jvm排查问题工具