epsilon gc 是 java 11 引入的无回收垃圾收集器，专用于单元测试和内存泄漏工具开发：它禁用 gc，确保对象永驻、引用不被清理、内存增长可预测；适用于可控内存基线构建与轻量隔离测试，但需防 oom 且 jdk 21 已移除。
Java 11 引入的 Epsilon 垃圾收集器（GC）不是用来跑生产系统的，而是专为“不回收内存”的场景设计——它在 JVM 启动后完全不触发 GC，也不管理堆内存释放。这恰恰让它成为单元测试和内存泄漏工具开发中极佳的隔离载体。
单元测试中避免 GC 干扰观测
常规 GC 会带来非确定性停顿、对象提前回收、弱引用/软引用被意外清空等问题，干扰对对象生命周期、引用链、内存占用的精确观测。Epsilon 彻底关闭 GC，让所有 new 出的对象一直存活到 JVM 退出，从而保证：
- 对象分配行为完全可预测，堆内存增长与代码逻辑严格线性对应
- WeakReference/SoftReference 不会被 GC 清理，便于验证引用策略是否按预期建立
- 避免因 GC 触发时机差异导致的测试 flakiness（例如某些 test 在 GC 后断言失败，换环境又通过）
内存泄漏检测工具的可控内存基线
开发内存泄漏分析工具（如自定义 heap dump 分析器、引用链追踪器、对象计数器）时，需要稳定、纯净的内存快照。Epsilon 提供了理想基线：
- 启动后立即执行
Runtime.getRuntime().gc()无实际效果，但调用安全，适合统一初始化流程 - 所有对象保留在堆中，配合
java.lang.instrument或java.lang.management.MemoryPoolMXBean可精确统计每类对象实例数、总大小 - 结合
-XX:+PrintGCDetails（虽然 Epsilon 不打印 GC 日志，但该参数兼容）或 JFR 事件过滤，能干净地排除 GC 相关噪音，只聚焦应用层分配行为
轻量级隔离环境构建技巧
Epsilon 启动开销极低，适合高频次、短生命周期的测试进程。实际使用建议：
- 启动参数示例：
-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx512m（注意必须显式指定堆大小，否则默认为 0） - 搭配
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./dump.hprof，可在 OOM 时获取完整未回收堆镜像，用于离线分析泄漏点 - 在 Maven Surefire 或 Gradle Test 中为特定测试套件单独配置 JVM 参数，不影响主模块运行时行为
局限与注意事项
Epsilon 不是万能方案，需明确其边界：
- 堆内存只会增长，不会释放，因此测试必须控制对象创建总量，避免快速 OOM
- 不能用于验证“GC 后资源清理”逻辑（如 finalize、Cleaner、PhantomReference），因为 GC 根本不发生
- JDK 17+ 默认禁用实验性选项，需额外加
-XX:+UnlockExperimentalVMOptions；JDK 21 起 Epsilon 已移除，推荐在 JDK 11–17 环境下使用
