Java应用内存泄漏如何排查？

说起来Java应用的内存泄漏问题，真是让人又爱又恨啊！Java的自动内存管理本该让开发者高枕无忧，但现实却常常事与愿违。就在上周，我们团队就遇到一个棘手的生产问题：一个运行了三个月的Java服务突然开始频繁Full GC，响应时间从原来的几十毫秒飙升到数秒。起初大家还以为是业务量激增导致的，直到查看监控才发现JVM堆内存使用率长期维持在90%以上，这明显不正常。

内存泄漏的典型症状

其实Java内存泄漏往往都有迹可循。最常见的就是堆内存使用率持续攀升，即使触发了GC也降不下来。我们当时遇到的情况就很典型：老年代使用率一直维持在高位，Young GC频率异常增加，每次Full GC后释放的内存也越来越少。更明显的是，通过jstat观察到的内存曲线就像爬楼梯一样，只升不降！

另一个容易被忽视的迹象是应用响应时间逐渐变慢。你可能觉得奇怪，明明代码没改，为什么系统越来越卡？这往往是因为GC线程占用了大量CPU资源，导致业务线程执行时间被挤压。我们当时就是用top命令发现Java进程的CPU使用率异常高，其中sys占比很大，这才意识到问题的严重性。

实用排查工具与技巧

要快速定位内存泄漏，jmap绝对是首选工具。我们当时就是用jmap -histo:live <pid>发现了端倪——某个自定义缓存类的实例数量异常之多，居然占用了近1GB内存！不过要提醒大家，这个命令会触发Full GC，在生产环境使用要特别谨慎，最好在业务低峰期操作。

如果条件允许，使用jcmd生成堆转储文件会更安全。我们后来的做法是jcmd <pid> GC.heap_dump /tmp/heap.hprof，然后用MAT工具详细分析。说实话，第一次看到MAT的泄漏分析报告时，我们都惊呆了——原来是一个静态Map在不停地累积数据，而且从来没有清理过！

其实很多时候问题就出在这些细节上。比如我们遇到的这个案例，开发同学本意是做数据缓存，结果因为没有设置过期时间，数据越积越多。更糟糕的是，由于这个Map被多个线程并发访问，还导致了CPU飙高的问题。这种复合型问题要是不深入排查，真的很难发现根源。

预防胜于治疗

经过这次教训，我们团队现在都会在测试环境先用jstat做长时间的压力测试，观察内存使用曲线。另外，强制要求所有使用缓存的地方必须设置合理的过期策略，对于大对象更要特别注意。说实话，与其等问题发生了再手忙脚乱地排查，不如提前把这些预防措施做到位。

最后给大家一个小建议：定期用VisualVM或JProfiler这类工具做性能剖析，它们能帮你发现很多潜在的内存问题。毕竟，在问题还没影响到用户之前就解决掉，这才是最好的运维实践，你们说是不是？