造成OOM的原因

1.一次性申请的太多

更改申请对象数量

2. 内存资源耗尽未释放

找到未释放的对象进行释放

3.本身资源不够

堆内存不足

jmap -heap 查看堆信息

如何快速定位OOM？

1.系统已经OOM了

提前设置OOM后生成一个dump文件（.hprof）
-XX：+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=
然后用jvisualvm这个工具载入dump文件，选择堆类型

找到最占资源的对象

随意点开一个，找到GCROOT

右键在线程中显示

2.系统运行中还未OOM

2.1导出dump文件：

jmap -dump:format=b, file=filename.hprof 1660

利用jps可以找到java线程
利用history命令也可以看到对象
jmap -histo:live 24286

2.2.结合jvisualvm进行调试

2.3 利用Arthas

Arthas可以做什么？

1、有没有一个全局JVM运行时监控？CPU，线程，内存，堆栈信息等等
2、CPU飙高，是什么造成的？
3、接口没反应、卡住了，是不是死锁了？
4、CTO说你们这个接口太慢了，要优化一下？如何准确找出耗时的代码
5、我写的代码没有执行，是部署的分支不对，还是我压根没提交？
6、线上有一个低级错误，改起来很简单，能不能在不重启应用的情况下，进行类替换，热部署。

如何使用Arthas

1、运行时监控命令 dashboard
2、全局线程面板````thread 11 3、对代码进行反编译jad thisClass```
4、对方法级别的监控

watch 查看方法的参数、结果、异常
trace 可以查看耗时
stack 查看调用栈

5.生产上CPU飙高的问题处理
利用thread -n 5这个命令可以查看线上前5的线程

6.死锁问题查看

利用thread -b 也可以实现

7.时空隧道功能

查看请求信息

请求回放，可以重复请求

小结

１、dashboard + thread 命令，基本可以在几秒钟内一键定位问题，找出消耗 CPU 最多的线程和方法栈；
①　dashboard 命令用于整体展示进程所有线程、内存、GC 等情况，分析占用CPU 较多的线程
②　使用thread -n查看最放慢的线程在执行的线程栈，找到执行的方法
２、直接 jad 反编译相关代码，来确认根因
３、如果调用入参不明确的话，可以使用 watch 观察方法入参，并根据方法执行时间来过滤慢请求的入参。
４、由于 monitor、trace、watch 等命令是通过字节码增强技术来实现的，会在指定类的方法中插入一些切面来实现数据统计和观测，因此诊断结束要执行 shutdown 来还原类或方法字节码，然后退出 Arthas。

小技巧：可以安装Arthas的idea插件，可以右键快速生成命令