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

本文主要是介绍内存溢出的处理方式及问题背后的思考，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

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

一 : 什么是内存溢出

引用百度百科的解释：
内存溢出(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。这种日常工作中问题的排查也是挺有趣的。
有什么不对的还望指正，书写不易，觉得有帮助就点个赞吧！

五 : 参考链接

内存溢出百度百科：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

这篇关于内存溢出的处理方式及问题背后的思考的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！