Java单元测试不能直接检测内存泄漏，但可通过WeakReference验证对象回收、堆内存快照对比、静态/ThreadLocal清理断言等手段间接暴露泄漏风险，筑牢三层防护。
Java 单元测试本身不直接检测内存泄漏，但它可以作为辅助手段，配合工具和设计原则，暴露潜在的泄漏风险。关键在于：单元测试负责验证逻辑正确性；而内存泄漏是运行时资源管理问题，需靠监控、堆分析和约束性断言来间接识别。
以下是在单元测试中有效关联内存泄漏检测的实用方式：
用 WeakReference 验证对象是否被及时回收
在测试中构造一个本该被 GC 回收的对象，再通过 WeakReference 观察它是否还“活着”：
@Test
public void testObjectShouldBeGarbageCollected() throws InterruptedException {
MyService service = new MyService();
WeakReference<MyService> ref = new WeakReference<>(service);
service = null; // 切断强引用
System.gc(); // 建议 JVM 执行 GC（不保证立即执行）
Thread.sleep(100); // 给 GC 留出时间（仅用于测试，非生产）
assertNull(ref.get()); // 若仍能取到，说明可能未被回收 → 存在泄漏嫌疑
}⚠️ 注意：该方法有局限性（GC 不确定性、JVM 优化干扰），仅适用于简单场景下的快速验证，不能替代专业工具。
立即学习“Java免费学习笔记（深入）”；
在测试前后对比堆内存快照（轻量级检测）
使用 JDK 自带的 jcmd 或 JUnit + jmap 脚本，在测试方法执行前后抓取堆使用量（如 jstat -gc 输出的 used 值），做差值判断：
- 启动测试前记录初始堆使用量（例如 Eden + Survivor 使用量）；
- 运行多次相同测试（如 100 次
new MyCache().put(key, value)）； - 再次采集堆使用量；
- 若增长显著且不回落，说明可能存在缓存未清理、静态集合膨胀等泄漏模式。
✅ 实操建议：将这类检查封装为
@BeforeAll/@AfterAll中的统计逻辑，或用Testcontainers+jcmd自动化抓取。
结合 ThreadLocal 和 static 字段做“污染检查”
很多泄漏源于静态持有或线程局部变量残留。可在测试后主动检查：
@Test
public void testNoStaticLeakAfterCleanup() {
MyCache.clear(); // 显式清理
assertTrue(MyCache.getInternalMap().isEmpty()); // 断言静态 Map 已空
}
@Test
public void testThreadLocalCleared() {
MyProcessor.process("data");
// 清理后应无残留
assertNull(MyProcessor.getCurrentContext());
}这类断言不是检测 GC 行为，而是验证你写的清理逻辑是否生效——这是单元测试最可靠、最可控的内存防护层。
单元测试 + LeakCanary（仅限 Android）或 jol（JOL：Java Object Layout）辅助验证
- Android 项目中，可启用
LeakCanary的测试模式（如LeakCanary.config = LeakCanary.config.copy(detectLeaksInTests = true)），让测试失败时自动报告泄漏路径； - Java SE 项目可用 JOL 打印对象内存布局与引用链，辅助确认某对象是否意外持有了不该持有的引用（如内部类隐式引用外部类）。
不依赖运行时工具的单元测试无法“看到”内存泄漏，但能守住三道防线：
- 强制清理逻辑必须可调用、可验证；
- 限制对象生命周期（如用工厂+关闭方法）；
- 对静态/线程敏感组件设计“重置”接口并在测试中调用。
真正定位泄漏，仍需 jmap + MAT、JProfiler 或 VisualVM 分析堆转储。单元测试的作用，是让你在代码提交前就卡住那些“明摆着会漏”的设计。
