内存溢出的处理方式及问题背后的思考
一 : 什么是内存溢出
对比生活场景就是，给了你一个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： 对于大表的操作，一定要小心谨慎。
五 : PPT分享
https://download.csdn.net/download/_/
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/38945.html