java项目线上出现OOM问题定位看这篇文章就够了

csdn中看到了很多关于OOM问题介绍的，但是对于定位问题没有看到什么真实有效的资料
所以这里自己写一个记录下，方便日后工作中需要时可以查阅

模拟OOM问题出现

这里我们先建一个springboot项目模拟出OOM问题，具体代码如下。
在com.ai.toptea.sysm.entity.MyThread中加入大量对象，并且一直处于被引用状态，不会被GCC回收。


打包部署到服务器上后开始运行，并观察日志。

查看日志发现java.lang.OutOfMemoryError: Java heap space
这里我们是创建大量对象，对象又是存储在堆中，所以这边OOM的原因后面已经标注了是heap没有空间了。
大家对于此类问题的分析，平时可以多看看JVM的知识，了解JVM中运行时数据区域中每一个区域存放哪些内容，这样在定位OOM问题时也可以根据信息更好的确认。

使用jmap命令生产堆转储快照

先用jsp命令或者ps命令查看到进程pid，
然后使用命令jmap -dump:live,format=b,file=mem-test.hpref <pid>导出快照查看。

使用visualVM查看堆转储快照

由于jhat 命令查看一般不够方便，所以都会使用visualVM来查看。visualVM在jdk的bin目录下就有，但是本人用jdk1.8自带的无法打开GC root界面。
所以又自己下载了一个，下载链接https://visualvm.github.io/download.html

将打印出mem-test.hpref文件放到本地下载好的visualvm中加载
先点击load

然后选择我们打印出的快照文件

之后按图中步骤依次点击后查看

本图中

1. 第一步是选择查看具体对象信息
2. 第二步是选择实例
3. 三步是打开GC引用信息
4. 第四步是根据size排序后选择size最大的一个点击查看
5. 第五步是查看此实例的GC引用信息

我们从第五步中可以看到我们自己项目中的类，static map in class com.ai.toptea.sysm.entity.MyThread : MyThread，就是我们加入大量对象的类com.ai.toptea.sysm.entity.MyThread
这样就可以定位到我们代码中具体哪个类产生了大量对象一直没有回收了。

设置OOM自动生产快照

启动时加入-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./java-"${time}".hprof
就可以当OOM时打印出带有时间名字的快照

完整的脚本在这里，改下jar包名就可以直接用了！

#!/bin/sh
#export JAVA_HOME=/app/toptea/jdk1.8.0_151
#PATH=$JAVA_HOME/bin:$PATH:$HOME/bin:.
time=`date -d now "+%Y-%m-%d %H:%M:%S.000"`
nohup java -Xbootclasspath/a:../ -Xms32m -Xmx32m -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./java-"${time}".hprof -jar ../beyond-men-high-test-2.0.0.jar >../logs/data.log 2>&1 &

打开文件，会发现自动生产的文件会显示出OOM问题出现时具体的线程信息

然后我们右击点击Select in Threads

然后搜索我们的项目名，可以看到我们项目中具体哪个类引发的。
但是这个只是引发的线程，最重要还是要查看具体哪些对象一直没被回收，然后去解决，才能防止下次OOM问题的发生！