动态内存泄漏追踪需实时监控而非等OOM，VisualVM适合轻量级初筛（如Old Gen趋势、类实例数），JProfiler支持深度分配追踪与引用链分析，二者应分阶段协同使用。
动态内存泄漏追踪不是等OOM发生后再分析dump，而是在线上或测试环境中实时观察对象增长、引用关系和GC行为，提前定位隐患。VisualVM 和 JProfiler 都支持这种“活体诊断”，但能力深度和操作逻辑有明显差异。
VisualVM：轻量级实时监控+手动触发快照
VisualVM 适合快速验证怀疑点，无需额外安装，JDK自带，但缺乏自动追踪和深度引用链下钻能力。
- 启动后连接目标Java进程，在Monitor标签页中持续观察堆内存曲线——若老年代（Old Gen）呈单向缓慢爬升且Full GC后无法回落，就是典型泄漏信号
- 点击Heap Dump按钮立即生成当前堆快照，无需停机；导出为heap.hprof后可配合Eclipse MAT做支配树分析
- 在Classes子视图中按实例数排序，重点关注自定义类（如UserCache、EventListenerImpl）是否持续增长
- 注意：不支持持续分配采样，无法直接看到“哪个方法new了最多对象”，需结合代码逻辑交叉判断
JProfiler：精准分配追踪+引用链穿透
JProfiler 是真正实现“动态追踪”的主力工具，尤其适合定位新增泄漏或验证修复效果。
- 启动时勾选Record allocations（记录对象分配），运行几分钟后暂停录制，进入Allocation Hotspots视图——它会按包/类/方法维度统计新对象创建次数和总大小，一眼锁定高产代码段
- 在Live Memory → Heap Walker中，右键某个可疑类（如OrderProcessor）→ Find Objects → 查看所有实例；再对任一实例点Show Retained Stack Trace，就能看到它是被哪个线程、哪条调用链创建并持有的
- 开启Garbage Collector Monitor，观察每次GC后各代内存回收比例；若某次Full GC后Old Gen仅下降5%，说明大量对象被强引用滞留
- 对静态集合类（如static Map<String, Object> cache），可在Heap Walker中直接展开其entries，查看key/value是否包含本该已失效的业务对象
关键操作组合建议
单靠一个工具容易遗漏线索，推荐分阶段协同使用：
立即学习“Java免费学习笔记（深入）”；
- 初筛阶段：用VisualVM跑10分钟，看Old Gen趋势 + 类实例数TOP10，圈出2–3个可疑类名
- 深挖阶段：用JProfiler连接同一进程，开启Allocation Recording，聚焦刚才圈出的类，查看其分配热点和保留集（retained set）
- 验证阶段：修改代码（如加remove逻辑、改用WeakHashMap），重启后用JProfiler对比两次Allocation Hotspots数据，确认对应类分配量是否归零
避开常见陷阱
动态追踪容易被表象误导，这几个细节必须盯紧：
- 不要只看“对象数量多”，要看“存活时间长”——短期高频创建+快速回收是正常行为；真正危险的是创建后长期驻留老年代的对象
- ThreadLocal变量泄漏常表现为java.lang.ThreadLocal$ThreadLocalMap$Entry大量存在，且value指向业务对象；需检查所有ThreadLocal使用处是否配对调用remove()
- 内部类泄漏在JProfiler中会显示为OuterClass$1持有OuterClass实例，根源往往是匿名监听器注册后未注销
- VisualVM默认不采集详细GC日志，建议JVM启动时加上-XX:+PrintGCDetails -Xloggc:gc.log，与内存曲线对照分析
