Arthas实战（3）- 内存泄漏精准定位

1. 内存泄漏的典型症状与Arthas快速诊断内存泄漏就像家里堆积的杂物刚开始可能感觉不到影响但随着时间推移空间会越来越紧张。Java应用中最直观的表现就是频繁Full GC但回收效果不佳最终导致OOMOutOfMemoryError。上周我就遇到一个线上案例某电商促销系统在流量高峰时频繁崩溃通过Arthas的dashboard命令5分钟就发现了老年代内存只增不减的异常现象。先看个典型的内存泄漏代码示例RestController public class LeakController { static MapString, Object cache new HashMap(); GetMapping(/cache) public String addCache(String key) { cache.put(key, new byte[1024 * 1024]); // 每次请求缓存1MB数据 return Added; } }启动Arthas后这三个命令组合堪称内存排查三板斧实时监控dashboard观察内存/GC趋势堆内存快照heapdump /tmp/heap.hprof保存现场对象统计memory命令查看对象数量排行实测发现当byte[]对象数量与请求量呈线性增长时基本可以确定存在未释放的缓存。这时候再用vmtool命令动态修改缓存上限能临时缓解问题直到代码修复。2. 火焰图定位内存分配热点很多教程只教生成火焰图但关键在分析技巧。上次帮金融团队排查问题时他们生成的火焰图显示com.alibaba.fastjson.JSON.parse占用了35%的内存分配但这是表象不是根源。继续用profiler命令的--alloc参数追踪对象分配路径最终发现是某位同事把JSON解析结果缓存到了静态Map中。生成内存分配火焰图的正确姿势# 启动采样默认100次/秒 profiler start --event alloc # 压测复现问题后停止采样 profiler stop --format html --file /tmp/alloc_flame.html分析时要重点看最宽平顶代表高频分配点调用链底部找到业务代码入口异常对象类型比如持续增长的byte[]或自定义DTO有个容易忽略的技巧用profiler list查看支持的事件类型比如--event cpu可以对比CPU和内存热点是否重合。3. jmap与Arthas内存分析组合拳虽然jmap需要进程PID但配合Arthas会更高效。最近排查的物流系统案例就很典型通过jmap -histo发现ConcurrentHashMap$Node异常增长但无法定位到业务代码。这时候用Arthas的sc和sm命令反查类加载信息最终定位到是路由计算模块的缓存策略缺陷。进阶排查步骤# 1. 先用jmap抓取对象直方图 jmap -histo:live pid | head -20 # 2. 用Arthas监控特定类 watch com.example.LeakService * {params,returnObj,throwExp} -n 5 # 3. 结合OQL查询 ognl java.lang.RuntimegetRuntime().totalMemory()特别提醒jmap -dump会产生STW停顿线上慎用。推荐先用Arthas的heapdump命令它基于SAFE模式生成快照对服务影响更小。4. 内存泄漏的七种常见模式与应对策略根据我处理过的上百个案例内存泄漏主要有这些类型1. 静态集合生命周期过长就像那个电商案例用static Map做缓存却没淘汰策略。修复方案要么改用Guava Cache要么增加LRU机制。2. 未关闭的资源数据库连接、文件流等推荐用try-with-resources语法try (Connection conn dataSource.getConnection()) { // 业务代码 }3. 监听器未注销特别是Spring的EventListener如果组件不销毁但事件持续产生就会积压。可以用Arthas的stack命令检查监听器调用栈。4. ThreadLocal使用不当线程池场景下必须手动remove。通过tt -t命令跟踪线程生命周期结合heapdump分析ThreadLocalMap条目。5. 第三方库的内存陷阱比如某知名ORM框架的缓存默认不限制大小需要在初始化时显式配置Bean public Configuration myBatisConfig() { Configuration config new Configuration(); config.setLocalCacheScope(LocalCacheScope.STATEMENT); return config; }6. 字符串不当处理大字符串的substring、split操作可能持有原char[]引用。用memory命令观察String对象内存占比。7. 不合理的JVM参数比如-XX:DisableExplicitGC会影响NIO的直接内存回收。建议用vmoption命令动态查看当前配置。5. 内存优化实战从发现到修复的全过程去年优化过一个日活百万的社交APP分享下完整流程阶段一问题复现通过jstat -gcutil 1s发现老年代使用率曲线呈锯齿状上升每次Full GC后最低值越来越高。阶段二定位泄漏点用profiler抓取内存分配火焰图发现CommentDTO对象异常ognl com.example.service.CommentServicecache查看到缓存Map尺寸超标heapdump分析对象引用链找到未被GC Root引用的僵尸对象阶段三修复验证引入WeakHashMap重构缓存后用Arthas的monitor命令观察15分钟内存变化# 每5秒统计一次缓存方法调用 monitor -c 5 com.example.service.CacheService getCache关键指标恢复正常老年代内存波动稳定在200MB以内Full GC间隔从3分钟恢复到2小时以上平均吞吐量提升40%