一、问题背景：当你的Java应用开始"发福"

某电商系统上线3个月后，运维突然收到报警：应用服务器的内存使用率突破85%红线，且呈现持续增长趋势。尽管每天凌晨的Full GC能短暂回收部分内存，但次日中午又会回到危险水位——这是典型的内存泄漏症状。

二、排查三板斧：从现象到证据链

2.1 现象捕捉（点击查看真实监控截图）

• GC频率从正常的每小时2-3次激增至每分钟5次
• 老年代内存占用曲线呈「阶梯式上升」形态
• 通过jstat -gcutil观察发现，每次Full GC后Old区回收效率不足10%

2.2 第一现场快照

bash

# 立即生成堆转储（建议在内存达到80%时操作）
jmap -dump:live,format=b,file=heapdump_$(date +%Y%m%d%H%M).hprof 

# 同时抓取线程快照
jstack  > thread_dump.log

三、Arthas线上诊断：不重启的CT扫描

3.1 安装与接入

bash

curl -O https://arthas.aliyun.com/arthas-boot.jar
java -jar arthas-boot.jar

3.2 关键诊断指令实战

bash

# 实时内存仪表盘（类似加强版top）
dashboard -i 2000

# 对象实例统计TOP20
heapdump --live /tmp/heapdump.hprof
ognl '@java.lang.management.ManagementFactory@getMemoryMXBean().@heapMemoryUsage.@used'

# 追踪特定类加载情况
classloader -t

四、MAT深度解剖：直击泄漏病灶

4.1 Dominator Tree分析法

1. 打开heapdump文件后，优先查看「Dominator Tree」
2. 按Retained Heap排序，发现OrderContextHolder类持有1.2GB内存
3. 右键Path To GC Roots排除软/弱引用

4.2 泄漏铁证锁定

java

public class CacheManager {
    // 罪魁祸首：没有容量限制的静态Map
    private static Map orderCache = new ConcurrentHashMap<>();
    
    public static void addOrder(String key, OrderDTO order) {
        orderCache.put(key, order);
    }
}五、根治方案：从紧急止血到长效机制

5.1 紧急修复措施

java

// 方案1：改用WeakHashMap（适合缓存场景）
private static Map<String, WeakReference> orderCache = new ConcurrentHashMap<>();

// 方案2：增加LRU淘汰策略
private static Map orderCache = new LinkedHashMap<>() {
    @Override
    protected boolean removeEldestEntry(Map.Entry eldest) {
        return size() > 1000;
    }
};

5.2 防御体系建设

1. 接入Prometheus+Grafana监控：设置堆内存、GC次数、对象创建速率等关键指标
2. 代码准入规范：所有静态集合必须明确生命周期管理策略
3. 压测验证：使用JMeter模拟72小时连续运行，观察内存曲线是否平稳

六、排查工具箱选型指南

技术要点总结：

• 内存泄漏的本质是「对象意外地存活于GC Roots引用链」
• 静态集合、未关闭的资源、内部类引用是三大高发雷区
• 组合使用在线诊断（Arthas）和离线分析（MAT）效率最高

最新实践：JDK 16引入的ZGC已支持亚毫秒级GC暂停，但并不能解决内存泄漏问题——再好的垃圾回收器也收不回被错误持有的对象！