周三下午快下班的时候运维群里突然我说线上有个服务内存一直在涨已经触发告警了。我看了一眼监控确实JVM堆内存从下午两点开始就一路往上爬GC频率明显变高Full GC之后也回收不了多少。典型的内存泄漏表现。先止血线上不能一直挂着先把服务重启了同时把JVM参数里加上了OOM时自动dump的配置-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/heapdump.hprof这个参数之前其实一直有但之前没触发过所以也没太在意。这次算是派上用场了。拿到dump文件重启之后内存确实降下来了但问题没解决。大概过了三个小时又涨上去了。这次直接等到了OOM触发dump文件自动生成了。dump文件大概1.8Gscp到本地之后用MAT打开。分析过程打开MAT之后先看Overview直接就能看到有个HashMap占了将近60%的堆内存。点进去看GC Roots调用链大概是这样的Thread-xxx - com.xxx.service.OrderSyncService.sync() - java.util.HashMap看到OrderSyncService我就大概知道问题在哪了。这个服务是做订单同步的之前有个需求是要做去重当时开发同学用了一个静态的HashMap来做缓存说是临时方案结果这个临时方案就一直没改过。问题在于这个Map只put不remove订单数据越来越多内存就这么一直涨。修复改法其实不复杂把静态HashMap换成了Guava的Cache设置了过期时间和最大容量private static final CacheString, OrderDTO orderCache CacheBuilder.newBuilder() .maximumSize(10000) .expireAfterWrite(30, TimeUnit.MINUTES) .build();同时加了一个定时任务每小时清理一次过期数据作为兜底。几点反思静态集合类是OOM的重灾区。项目里凡是看到static Map、static List这种都要多问一句有没有清理机制JVM参数不要偷懒。HeapDumpOnOutOfMemoryError这个参数建议所有Java服务都加上关键时刻能救命。临时方案一定要记录。很多线上问题都是当初的临时方案没人管最后变成了长期隐患。我们后来在代码review的时候加了一条规则凡是带TODO标记的临时方案必须关联一个issue跟踪。工具推荐排查内存问题常用的几个工具MATEclipse Memory Analyzer分析dump文件首选直观Arthas阿里开源的线上诊断神器heapdump、dashboard命令很好用jstat轻量级适合快速看GC情况jstat -gcutil pid 1000直接看这次排查前后花了大概两个小时核心还是定位问题花的时间多。写出来记录一下也希望能帮到遇到类似问题的同学。有问题的话评论区聊。