修复内存泄漏后需通过多维度数据验证：监控老年代使用率、full gc间隔与回落幅度，对比gc日志，跟踪可疑对象实例数变化，压力测试+空载观察，以及堆转储快照比对，确认对象生命周期恢复正常、内存增长趋势被遏制。
修复内存泄漏后，验证不能只看“不报OOM”就认为搞定——很多问题会延迟暴露，或在高负载下才复现。关键在于用数据确认对象生命周期已回归正常、内存增长趋势被真正遏制。
监控堆内存与GC行为变化
启动修复后的服务，持续观察至少2个完整业务周期（如定时任务执行轮次、典型用户活跃时段）：
- 用 jstat -gc
5000 每5秒采样一次，重点关注： - 对比修复前后的GC日志：启用 -Xlog:gc*:file=gc.log:time,uptime,tags，检查是否还有“GC overhead limit exceeded”或长时间STW（>1s）记录。
— 老年代（Old Gen）使用率是否稳定在60%以下，不再持续爬升；
— Full GC间隔是否拉长（例如从每10分钟一次变为每2小时以上）；
— 每次Full GC后老年代内存是否明显回落（降幅≥30%）。
检查可疑对象实例数量趋势
定位到的泄漏对象（如某个静态Map、未清理的ThreadLocal值、缓存类实例）必须做量化验证：
- 用 jcmd
VM.native_memory summary 或 Arthas watch 命令实时跟踪目标类实例数，例如：
watch com.example.CacheManager cacheMap 'params[0].size()' -n 5 - 在VisualVM或JConsole中添加自定义MBean或使用JMX暴露关键集合size指标，绘制成时间曲线；
- 确认该数值在业务操作后能回落（如用户登出触发清理），而非单向累积。
压力测试+长时间空载观察
模拟真实场景，避免“本地跑得通，线上又崩”：
- 用JMeter或Gatling对核心接口施加中等压力（如原QPS的70%），运行30–60分钟，观察堆内存是否呈现“锯齿状但基线平稳”（即每次GC后回落至相近水平）；
- 压力停止后，保持服务空载运行4–8小时，监测是否出现缓慢爬升——这是ThreadLocal或异步任务残留的典型信号；
- 若使用了本地缓存，主动触发缓存过期或清理逻辑，验证内存是否同步释放。
比对修复前后堆转储快照
这是最直接的证据链闭环：
- 在相同业务阶段（如完成100次订单结算后），分别用 jmap -dump:format=b,file=before.hprof
和 after.hprof 生成两个堆快照； - 用Eclipse MAT打开，对比Histogram中问题类的实例数和Shallow Heap占比——修复后应下降80%以上；
- 重点检查 Path to GC Roots：原来被static字段或线程栈强引用的对象，现在是否已变为弱引用、软引用，或彻底不可达。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
