我要评论最近公司生产环境里面一个服务的一直在上升，过一段时间就要触发报警，重启也只能暂时缓解，由于还没有oom，猜测可能是内存泄漏了。
内存泄漏
内存泄漏是java应用中常见的问题，指对象已经不再被使用，但由于被意外引用而无法被垃圾回收器(gc)回收，导致内存占用持续增长，最终可能引发oom(outofmemoryerror)错误。
内存问题排查
还是采用常规的办法，八股文面试必问。
1.查看jvm内存配置
查看内存中对象的数量和大小，判断是否在合理的范围，如果在合理的范围内，增大内存配置，调整内存比例就可以了。
查询一下那个服务的pid进程号，根据进程号查询。
jmap -heap pid
可以看出 老年代的使用率已经非常高了。
2.分析gc是否正常执行
jstat -gcutil 1000
s0 — heap上的 survivor space 0 区已使用空间的百分比 s1 — heap上的 survivor space 1 区已使用空间的百分比 e — heap上的 eden space 区已使用空间的百分比 o — heap上的 old space 区已使用空间的百分比 m — 元空间 区已使用空间的百分比 ygc — 从应用程序启动到采样时发生 young gc 的次数 ygct– 从应用程序启动到采样时 young gc 所用的时间(单位秒) fgc — 从应用程序启动到采样时发生 full gc 的次数 fgct– 从应用程序启动到采样时 full gc 所用的时间(单位秒) gct — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒) lgcc - 进行gc的原因（低版本jdk可能没有这一列）
3.导出 dump 各种工具分析
以文件方式导出 jvm 内存使用情况：
jmap -dump:live,format=b,file=xxxx.hprof pid
4.工具分析dump
jvm 分析工具有很多，我这里使用idea自带的小仪表盘，无需单独下载，可以直接使用，小仪表盘的名字叫profiler，功能比较强大，最好使用idea2023以后的版本。
打开dump 文件：
打开后页面如下：
查找一下大对象：
快速找出耗内存大对象：
根据大对象直接定位到具体的代码：
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持代码网。
发表评论