jvm指令，jvm内存溢出原因分析过程和实例，MAT分析使用，NewRatio无效

ゝ一世哀愁。 2022-03-18 10:39 310阅读 0赞

### jvm相关的指令简单解析 ###

jps :JVM Process Status Tool,显示指定系统内所有的HotSpot虚拟机进程。  
命令格式  
jps \[options\] \[hostid\]  
option参数  
\-l : 输出主类全名或jar路径  
\-q : 只输出LVMID  
\-m : 输出JVM启动时传递给main()的参数  
\-v : 输出JVM启动时显示指定的JVM参数  
其中\[option\]、\[hostid\]参数也可以不写。

jcmd 1695 GC.run  命令行进行gc  
说明： 1695是jps获取的java进程号

jstat  
jstat(JVM statistics Monitoring)是用于监视虚拟机运行时状态信息的命令，它可以显示出虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据。  
Option  Displays…  
class   class loader的行为统计。  
compiler HotSpt JIT编译器行为统计。  
gc  垃圾回收堆的行为统计。  
gcnew   新生代行为统计。  
......  
实例  
jstat -gcnew 4502  
 S0C    S1C    S0U    S1U   TT MTT  DSS      EC       EU     YGC     YGCT    
 512.0  512.0    0.0   64.0  1  15  512.0  23552.0  19612.0  62079 2264.691

jstat -gc 4502  
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT  
209664.0 209664.0  0.0   12744.5 629248.0 510460.3 3145728.0   150092.5  204144.0 200261.6 22176.0 21505.2   1321   32.334  442    74.518  106.852

jmap  
jmap -heap \[pid\] 要注意的是在使用CMS GC 情况下，jmap -heap的执行有可能会导致JAVA 进程挂起  
jmap -histo \[pid\] 查看JVM堆中对象详细占用情况  
jmap -dump:format=b,file=文件名 \[pid\] 导出整个JVM 中内存信息  
jmap -histo:live pid命令  //这个会立即触发fullgc

jstack  
jstack用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。  
\-F : 当正常输出请求不被响应时，强制输出线程堆栈  
\-l : 除堆栈外，显示关于锁的附加信息  
\-m : 如果调用到本地方法的话，可以显示C/C++的堆栈  
jstack \[option\] pid >head.log

### jvm中堆使用情况一般查询过程 ###

1.  查看java程序对应的pid ：jps指令查看  后面带有Bootstrap的就是。  
2.  查看整个JVM内存状态：jmap -heap \[pid\] 要注意的是在使用CMS GC 情况下，jmap -heap的执行有可能会导致JAVA 进程挂起
3.  查看JVM堆中对象详细占用情况 jmap -histo \[pid\]
4.  导出整个JVM 中内存信息 jmap -dump:format=b,file=文件名 \[pid\]
5.  使用eclipse的MAT分析内存文件

如:  
Jps 找到java对应的进程号  
jmap -dump:format=b,file=文件名 \[pid\]  
![2019022016455418.png][]

![20190220164618202.png][]  
文件生成后 用eclipse的 MAT插件就可以查看，如果没有安装可以借鉴  
https://blog.csdn.net/u010335298/article/details/52233689  
然后重启eclipse，选择File open打开文件即可开始分析

### dump OOM内容的两种方式 ###

1.输出方式有两种方式：    
方式一：命令参数jmap -dump:format=b,file=xxx.hprof  pid     
方式二：jvm配置增加oom时自动dump，配置如下  
 -XX:+HeapDumpOnOutOfMemoryError   
 -XX:HeapDumpPath=/export/Domains/dump.hprof    
推荐方式二，更加灵活方便

### 内存溢出分析实例 ###

背景：  
运维监控，统计深圳机场限额使用情况，手动写SQL结果集过大，导致java.lang.OutOfMemoryError异常，系统报警。  
问题排查步骤：  
1.  收到报警短信，第一时间查看云信对应的系统报什么错误信息，找出可疑问题。  
2.  找运维导出内存溢出的快照文件  
3.  使用MAT内存分析工具，分析报错报告，找出问题所在

### 使用MAT分析报错报告流程 ###

1.  先查看leak Suspects,找出最有可能出现问题的对象  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70][]  
2.在向下看，可以确定两个可以对象，java.lang.Thread   
和com.mysql.jdbc.JDBC4ResultSet ，可以定位是线程和 sql问题  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 1][]  
针对不同的可能影响内存溢出的问题，点击Details可看到具体的信息  
Shallow Heap指的是所有的实例的内存总和。Retained Heap指的是所有类实例被分配的内存总和，retained heap占用最多的是object数组  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 2][]  
com.mysql.jdbc.ByteArrayRow被实例化了3,055,923次  
![20190220164751499.png][]  
在Accumulated Objects列表中，我们可以看见创建的大量的对象。  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 3][]  
3.查看See stacktrace,查看堆栈  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 4][]  
有上图的的三处基本可以定位到，gcpm项目内com.suning.gcpm.admin.business.commonQuery.CommonQueryBussiness.commonSQL ，这个方法的问题，再查看代码，  
确定是后台执行sql的问题。  
这样就定位了问题，找到了罪魁祸首  
因为刚刚，我在用后台查在生产查询了一个sql,并且没有返回结果。  
Sql要查询的结果是 top\_org\_code= '6054372338'用户下，账期支付方式  
并且改变的限额>=已有的限额

user\_code用户表  
zs\_credit\_limit\_useinfo限额记录表  
zs\_credit\_limit\_info   限额表   
SELECT c.credit\_value, c.used\_credit\_value ,u.change\_value FROM zs\_credit\_limit\_useinfo u   
LEFT JOIN zs\_user z ON  z.user\_code=u.cust\_no  
LEFT JOIN zs\_credit\_limit\_info c ON  c.cust\_no=c.cust\_no  
WHERE u.change\_reason='08'   
AND z.top\_org\_code= '6054372338'  
AND u.change\_value>=c.credit\_value

Sql问题：关联条件写错，c.cust\_no=c.cust\_no

结论：生产环境查询sql注意事项：  
1.  本地执行，保证语法正确  
2.  生产sql先查看一下执行计划，有没有性能瓶颈  
3.  先查询count(),先查总数，再执行查询结果集  
4.大促敏感时期，生产操作都要注意  
5.如果关联表的结果集过大，可以找DBA导出生产的SQL，导入本地库，关联查询  
6.手动分页查询

### NewRatio无效实例 ###

jmap -heap 10284，结果如下：  
Attaching to process ID 10284, please wait...  
Debugger attached successfully.  
Server compiler detected.  
JVM version is 25.91-b14

using thread-local object allocation.  
Parallel GC with 4 thread(s)

Heap Configuration:  
   MinHeapFreeRatio         = 0  
   MaxHeapFreeRatio         = 100  
   MaxHeapSize              = 6442450944 (6144.0MB)  
   NewSize                  = 134217728 (128.0MB)  
   MaxNewSize               = 134217728 (128.0MB)  
   OldSize                  = 2013265920 (1920.0MB)  
   NewRatio                 = 2  
   SurvivorRatio            = 8  
   MetaspaceSize            = 21807104 (20.796875MB)  
   CompressedClassSpaceSize = 1073741824 (1024.0MB)  
   MaxMetaspaceSize         = 17592186044415 MB  
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:  
PS Young Generation  
Eden Space:  
   capacity = 104857600 (100.0MB)  
   used     = 55912680 (53.322486877441406MB)  
   free     = 48944920 (46.677513122558594MB)  
   53.322486877441406% used  
From Space:  
   capacity = 14680064 (14.0MB)  
   used     = 613560 (0.5851364135742188MB)  
   free     = 14066504 (13.414863586425781MB)  
   4.179545811244419% used  
To Space:  
   capacity = 14155776 (13.5MB)  
   used     = 0 (0.0MB)  
   free     = 14155776 (13.5MB)  
   0.0% used  
PS Old Generation  
   capacity = 2013265920 (1920.0MB)  
   used     = 566038448 (539.8163299560547MB)  
   free     = 1447227472 (1380.1836700439453MB)  
   28.11543385187785% used

45234 interned Strings occupying 4779152 bytes.

问题：  
old计算出来是280M，实际1920M   ？？？？？？？？？？？？？？？  
NewRatio 与实际新生代和老生代占用内存不一致原因？？？

获取当前linux上jvm配置  
ps -ef | grep java

work     10284     1  1 Feb12 ?        02:09:26 /data/j2sdk/bin/java -Djava.util.logging.config.file=/data/zhipin-bi/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Xms2048M -Xmx6144M -Xmn128M -XX:PermSize=128M -XX:MaxPermSize=256m -XX:-OmitStackTraceInFastThrow -Xdebug -XX:+PrintTenuringDistribution -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Djava.security.egd=file:/dev/./urandom -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -Xloggc:/data/zhipin-bi/tomcat/bin/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/zhipin-bi/tomcat/bin/dump.hprof

-Xms2048M -Xmx6144M -Xmn128M，这三个配置已经有了，实际上NewRatio就会无效，但是jmap -heap 的结果中NewRatio是怎么来的呢？

[2019022016455418.png]: /images/20220318/1a716ae67ce04f02b964513611655e05.png
[20190220164618202.png]: /images/20220318/522fcf8ba3f349c1b8bc60e1a76e2942.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70]: /images/20220318/3b2ed64c9ba3413798f9cf8eae479ea9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 1]: /images/20220318/213e482b141642bba469bb26b550f607.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 2]: /images/20220318/053092a8abf744f5be49d21f712a46d4.png
[20190220164751499.png]: /images/20220318/7ad821a5d5694bac9ba1b76ae03bfb98.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 3]: /images/20220318/b923e947d84442959d1baee74b84bc2d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 4]: /images/20220318/c14ef74806dd4beda2cd69d98a175c86.png