内存溢出的处理方式及问题背后的思考

内存溢出的处理方式及问题背后的思考

一 : 什么是内存溢出

引用百度百科的解释：
内存溢出(Out Of Memory，简称OOM)是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于能提供的最大内存。此时程序就运行不了，系统会提示内存溢出，有时候会自动关闭软件，重启电脑或者软件后释放掉一部分内存又可以正常运行该软件，而由系统配置、数据流、用户代码等原因而导致的内存溢出错误，即使用户重新执行任务依然无法避免。

对比生活场景就是，给了你一个1L的杯子，给你倒水的时候，却给你了2L甚至更多的水，超过了你的承受能力，这就溢出了。这样就很好理解了。

二 : 产生原因（java为例）

1: JVM配置不合理
一般情况下，大部分的项目都是使用默认的配置。
那么这个时候就需要去统计项目业务操作产生的实例数，以及在高频时段业务频次，这样就可以计算出内存占用的峰值，进而调整Eden，Survivor等的参数。
2: 内存没有释放
部分线程实例没有及时释放，使得无用的实例占用过多的内存。
3: 申请资源过多
这种是最常见的问题，比如一个查询取到的数据量过大，集合中的实例过多，数据量过大，占用的内存自然就比较多。如果多个进程都进行了同样的操作，内存就会很容易溢出。

三 : 问题的排查

1: 现在Linux服务器找到自己的PID（进程号）
常见命令：ps -ef | grep java

jps
查看进行ID

以generate的进程为例

jmap -heap 12892
显示Java堆详细信息

jmap -histo 12892 >java.log
显示堆中对象的统计信息，并将信息输入至java.log文件中
打开java.log文件，可以看到实例的个数及占用的内存大小

jstat -gcutil pid interval(ms)
查看GC情况
S0：Survivor space 0 utilization as a percentage of the space's current capacity.
新生代中Survivor space 0区已使用空间的百分比
S1：Survivor space 1 utilization as a percentage of the space's current capacity.
新生代中Survivor space 1区已使用空间的百分比
E：Eden space utilization as a percentage of the space's current capacity.
新生代已使用空间的百分比
O：Old space utilization as a percentage of the space's current capacity.
老年代已使用空间的百分比
M：Old space utilization as a percentage of the space's current capacity.
永久带已使用空间的百分比
CCS：Compressed class space utilization as a percentage.
以百分比表示的压缩类空间利用率。
YGC：Number of young generation GC events.
从应用程序启动到当前，发生Yang GC 的次数
YGCT：Young generation garbage collection time.
从应用程序启动到当前，Yang GC所用的时间【单位秒】
FGC：Number of full GC events.
从应用程序启动到当前，发生Full GC的次数
FGCT：Full garbage collection time.
从应用程序启动到当前，Full GC所用的时间
GCT:：Total garbage collection time.
从应用程序启动到当前，用于垃圾回收的总时间【单位秒】

jstat -gcutil 12892 1000

通过以上命令基本可以找到那个实例的问题了，如果还不行，那试试找对应的线程。

top
查看进程PID

top状态下 Shift + h 查询线程
获取线程PID2 10进制转换成16进制
Ctrl + C 退出
如线程12904，转换后为3268

jstack PID >log.out
如：jstack 6130 >log.out

打开log.out文件
用刚才转换16进制后的参数搜索，可以看到对应的线程信息。

如果做到这，还是不行，那只能下载dump文件了

jmap -dump:file=文件名.dump [pid]
jmap -dump:format=b,file=文件名 [pid]
format=b指定为二进制格式文件
比如刚才的这个Java进程
jmap -dump:file=test.dump 6130

将文件下载下来，可以使用jdk自带的visualvm工具进行查看分析，也可使用其他的分析工具。
这样就可以查看完整的信息了。

四 : 问题的思考

写一些自己的总结
1： 日常业务数据的操作，需要注意表的数据量，切忌全表查询，没有任何有效条件。
2： 命令jstackjmapjstat 需要较高的权限，而且CUP飙升之后，一般会很快的回落。如果已上线的项目，需确保有相应的权限，以及时问题的排查。
3： 就JAVA而言，后端的任何接口都是需要加校验的，即使前端增加了校验，后端仍要增加校验，防止前端校验失效等问题。
如校验失效，不仅会对JVM造成压力，同样会对数据库造成压力。
4： 已上线的项目，业务是累积的，数据量也是叠加的，需定时排查生产环境数据量，防患于未然。
5： 对于大表的操作，一定要小心谨慎。

写到这也就差不多了，感兴趣的可以搜一下jstack jmap jstat。这种日常工作中问题的排查也是挺有趣的。
有什么不对的还望指正，书写不易，觉得有帮助就点个赞吧！

五 : PPT分享

https://download.csdn.net/download/qq_38254635/86743025

六 : 参考链接

内存溢出百度百科：https://baike.baidu.com/item/%E5%86%85%E5%AD%98%E6%BA%A2%E5%87%BA/1430777
jstat官方文档：https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jstat.html