1、内存Heap Dump文件抓取

heap dump记录了JVM中堆内存运行的情况。

• XX:+HeapDumpOnOutOfMemoryError
  ​ 应用启动时配置参数，当OutOfMemoryError发生时自动生成 Heap Dump 文件。这可是一个非常有用的参数，因为当你需要分析Java内存使用情况时，往往是在OOM(OutOfMemoryError)发生时。

  -XX:+HeapDumpOnOutOfMemoryError 
  -XX:HeapDumpPath=data 
  

注意：JVM 生成 Heap Dump 的时候，虚拟机是暂停一切服务的。如果是线上系统执行 Heap Dump 时需要注意。

2、线程Thread Dump文件抓取

Thread dump 文件记录了当时JVM中线程运行的情况，Thread dumps 能帮助我们判断 CPU 峰值、死锁、内存异常、应用反应迟钝、响应时间变长和其他系统问题。

• kill -3
  出于安全方面的考虑，生产环境有时候只包含JRE环境，这时jdk下的工具就不能用了

  kill -3 <pid>
  kill -3 37320
  

3、GUI分析工具——JVisualVM/JConsole

• JConsole ：
  JDK提供的一个基于GUI查看JVM系统信息的工具，既可以管理本地的JVM，也可以管理远程的JVM

• JVisualVM：
  JDK提供的可以从本地或者远程运行的 JVM 里抓取 dump 文件。
  https://www.cnblogs.com/xifengxiaoma/p/9402497.html

https://blog.csdn.net/moneyshi/article/details/81511687

JVisualVM/JConsole虽然用起来很方便，但是如果要连接远程机器上的jvm，则远程机器上的jvm需要加参数（本地的不需要），所以生产环境上我们通常是不会直接用这两个工具的，这时就需要用到命令行工具了。

4、命令行工具

4.1 jmap

Jmap是一个JDK提供的可以输出所有内存中对象的工具，甚至可以将VM 中的heap，以二进制输出成文本。打印出某个java进程（使用pid）内存内的，所有‘对象’的情况（如：产生那些对象，及其数量）。

常用命令

• jmap -heap pid
  查看进程堆内存详细信息，包括使用的GC算法、堆配置参数和各代中堆内存使用情况

• jmap -histo[:live] pid
  查看java堆中对象的相关信息，包含数量以及占用的空间大小，如果带上live则只统计活对象

• jmap -permstat pid
  打印进程的类加载器和类加载器加载的持久代对象信息，输出：类加载器名称、对象是否存活（不可靠）、对象地址、父类加载器、已加载的类大小等信息

• jmap -dump:live,format=b,file=heap-dump.bin <pid>
  生成Heap Dump到文件，其中的pid是JVM进程的id，heap-dump.bin是生成的文件名称，在执行命令的目录下面，可以把生成的dump文件加载到GUI工具中查看

4.2 jstack——jdk包含

jstack主要用来查看某个Java进程内的线程堆栈信息，jstack可以定位到线程堆栈，根据堆栈信息我们可以定位到具体代码，所以它在JVM性能调优中使用得非常多

• jstack -F pid
  检查是否有死锁

• jstack -l pid
  打印出额外的锁信息，在发生死锁时可以用jstack -l pid来观察锁持有情况

• jstack -l 37320 > /opt/tmp/threadDump.txt
  保存 dump 信息到文件

• 使用实例：系统cpu消耗比较高，那我们怎么定位到是哪里出问题？

1. 先找出java进程ID；
   ps -ef | grep flybird —— 21711
2. 找出该进程内最耗费CPU的线程；
   top -Hp pid ——21742
3. 输出进程21711的堆栈信息，并且查询到具体的线程id；
   jstack 21711 | grep 54ee
   注意：54ee是线程id 21742的16进制值

4.3 jstat（JVM统计监测工具）

• jstat -gc 91328
  查看jvm垃圾回收情况，包括FGC、YGC的总次数和累计耗时

• jstat -gcutil 91328
  功能和gc 一样，但是是百分比的形式，读取更友好

• jstat -gccapacity 91328
  读取各个代区的当前容量、最大容量、当前使用量等信息

5、调优

image.png image.png

• -Xms:设置初始分配大小，默认为物理内存的“1/64”；
• -Xmx:最大分配内存，默认为物理内存的“1/4”；
• -Xss规定了每个线程堆栈的大小。一般情况下256K是足够了。太大了影响此进程中并发线程数大小；

在整个堆内存的调整策略之中，有经验的人基本只会调整两个参数：“-Xmx”(最大内存)、“-Xms”（初始化内存）。如果要取得这些内存的整体信息，直接利用Runtime类即可；

在很多情况下，-Xms和-Xmx设置成一样的。这么设置，是因为当Heap不够用时，会发生内存抖动，影响程序运行稳定性。

通过 ps -ef | grep java 可以查询到启动时设置的这些参数，如下

$ ps -ef | grep java
user_00   1689     1  1 Oct19 ?        17:39:05 /usr/local/services/elasticsearch-7.2.1/jdk/bin/java 
-Xms2g 
-Xmx2g
-Xss1m  
-XX:+UseG1GC 
-XX:MaxTenuringThreshold=15 
-XX:MaxGCPauseMillis=3000 
-XX:InitiatingHeapOccupancyPercent=75 
-Des.networkaddress.cache.ttl=60 
-Des.networkaddress.cache.negative.ttl=10 -XX:+AlwaysPreTouch 
-Djava.awt.headless=true 
-Dfile.encoding=UTF-8 
-Djna.nosys=true 
-XX:-OmitStackTraceInFastThrow 
-Dio.netty.noUnsafe=true 
-Dio.netty.noKeySetOptimization=true 
-Dio.netty.recycler.maxCapacityPerThread=0 
-Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true 
-Djava.io.tmpdir=/tmp/elasticsearch-2105800618487179719 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=data 
-XX:ErrorFile=logs/hs_err_pid%p.log 
-Xlog:gc*,gc+age=trace,
safepoint:file=/data/elasticsearch/logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m 
-Djava.locale.providers=COMPAT -Dio.netty.allocator.type=pooled 
-XX:MaxDirectMemorySize=1073741824 
-Des.path.home=/usr/local/services/elasticsearch-7.2.1 
-Des.path.conf=/usr/local/services/elasticsearch-7.2.1/config 
-Des.distribution.flavor=default -Des.distribution.type=tar 
-Des.bundled_jdk=true -cp /usr/local/services/elasticsearch-7.2.1/lib/* org.elasticsearch.bootstrap.Elasticsearch -p /usr/local/services/elasticsearch-7.2.1/logs/elasticsearch.pid --quiet