jvm调优工具

1.jps 查询当前服务器启动了哪些java项目

 

 2.jmap -histo 16332>./histo.log

 

 3.jmap -heap 16632查询堆的信息

 

 4.jmap ‐dump:format=b,file=kk.hprof 16332 堆栈导出，

线上环境可以设置内存溢出时自动导出堆信息

1. -XX:+HeapDumpOnOutOfMemoryError
2. -XX:HeapDumpPath=./ （路径）

可以用jvusalvm进行分析

 

 

5.jstack + 进程id可以查询死锁

 

 prio:java线程的优先级，os_prio:java线程优先级在系统中的标识   tid:代表java线程编号  nid:java线程编号在系统的标识

 用jvsualvm查询：

 

 

6.远程连接jvsualvm:

 

 需要配置：

java ‐Dcom.sun.management.jmxremote.port=8888 ‐Djava.rmi.server.hostname=192.168.50.60 ‐Dcom.sun.management.jmxremot
e.ssl=false ‐Dcom.sun.management.jmxremote.authenticate=false ‐jar xxxxxx‐server.jar

-Dcom.sun.management.jmxremote.port 为远程机器的JMX端口
-Djava.rmi.server.hostname 为远程机器IP

tomcat的JMX配置：在catalina.sh文件里的最后一个JAVA OPTS的赋值语句下一行增加如下配置行
JAVA_OPTS="$JAVA_OPTS ‐Dcom.sun.management.jmxremote.port=8888 ‐Djava.rmi.server.hostname=192.168.50.60 ‐Dcom.sun.management.jmxremote.ssl=false ‐Dcom.sun.management.jmxremote.authenticate=false"

 

 

 7. jinfo -flags 进程Id :查询jvm的参数

  8. 查询系统的参数：jinfo -sysprops 23392

 9. jstat  -gc +pid

 

 

 S0C: S0区的总大小  S0U ：S0区已使用大小        S1C: S1区的总大小  S1U ：S1区已使用大小     EC: eden区的总大小  EU ：eden区已使用大小    OC 和OU代表老年代的总量和使用量

MC和MU代表元空间的总大小和使用大小   CCSC和CCSU代表压缩空间的大小和使用大小  YGC和YGCT代表年轻代回收次数和时间  FGC和FGCT代表老年代的回收次数和时间 GCT代表总回收时间

 10. jstat -gcutil +pid查看使用比率

 

 

 优化建议：

JVM运行情况预估
用 jstat gc -pid 命令可以计算出如下一些关键数据，先给自己的系统设置一些初始性的
JVM参数，比如堆内存大小，年轻代大小，Eden和Survivor的比例，老年代的大小，大对象的阈值，大龄对象进入老年代的阈值等。

年轻代对象增长的速率
可以执行命令 jstat -gc pid 1000 10 (每隔1秒执行1次命令，共执行10次)，通过观察EU(eden区的使用)来估算每秒eden大概新增多少对
象，如果系统负载不高，可以把频率1秒换成1分钟，甚至10分钟来观察整体情况。注意，一般系统可能有高峰期和日常期，所以需要在不
同的时间分别估算不同情况下对象增长速率。

Young GC的触发频率和每次耗时
知道年轻代对象增长速率我们就能推根据eden区的大小推算出Young GC大概多久触发一次，Young GC的平均耗时可以通过 YGCT/YGC
公式算出，根据结果我们大概就能知道系统大概多久会因为Young GC的执行而卡顿多久。

每次Young GC后有多少对象存活和进入老年代
这个因为之前已经大概知道Young GC的频率，假设是每5分钟一次，那么可以执行命令 jstat -gc pid 300000 10 ，观察每次结果eden，
survivor和老年代使用的变化情况，在每次gc后eden区使用一般会大幅减少，survivor和老年代都有可能增长，这些增长的对象就是每次
Young GC后存活的对象，同时还可以看出每次Young GC后进去老年代大概多少对象，从而可以推算出老年代对象增长速率。

Full GC的触发频率和每次耗时
知道了老年代对象的增长速率就可以推算出Full GC的触发频率了，Full GC的每次耗时可以用公式 FGCT/FGC 计算得出。
优化思路其实简单来说就是尽量让每次Young GC后的存活对象小于Survivor区域的50%，都留存在年轻代里。尽量别让对象进入老年
代。尽量减少Full GC的频率，避免频繁Full GC对JVM性能的影响。

 11. Arthas 阿里开源的一个jvm检测工具，非常强，详细使用根据官网学习即可  https://arthas.aliyun.com/doc/

12. GC 日志:

jvm的配置：-Xloggc:D:/gc‐%t.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintGCCause -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M

上面的配置会在D盘，生成GC相关的日志，总共会保留10份，没份的大小是100M

 

 

 程序运行配置：

java ‐jar ‐Xloggc:./gc‐%t.log ‐XX:+PrintGCDetails ‐XX:+PrintGCDateStamps ‐XX:+PrintGCTimeStamps ‐XX:+PrintGCCause ‐XX:+UseGCLogFileRotation ‐XX:NumberOfGCLogFiles=10 ‐XX:GCLogFileSize=100M xxkkkk.jar

 

日志的内容大概如下：

 上面所示：第一列是GC发送的时间，0.092是项目启动到GC经过的时间，接着是这次GC产生的原因，后面PSYoungGen: 2048K->504K(2560K)]  2048K是GC前新生代的使用的大小，504K是新生代GC后内存使用大小，2560K是新生代的总大小，

 0.0015258这个是GC的时间；

我们可以配置不同的垃圾处理器来看他们的日志，不同垃圾收集器的GC日志是不一样的，导出GC日志后，我们可以使用专门的日志工具进行分析

登录网站：https://gceasy.io/

 

java -XX:+PrintFlagsInitial 表示打印出所有参数选项的默认值
java -XX:+PrintFlagsFinal 表示打印出所有参数选项在运行程序时生效的值