Epsilon GC可彻底排除GC对性能指标的干扰，它不做回收、不触发STW、不引入屏障开销、不移动对象，专用于精准定位非GC类延迟或吞吐瓶颈；适用于JDK11–13的短期压力测试与内存基准评估。
直接用 Epsilon GC 运行程序，就能彻底排除 GC 对性能指标的干扰——它不做任何回收动作，不触发 STW，不引入屏障开销，也不移动对象。适合精准定位非 GC 类延迟或吞吐瓶颈。
明确测试目标：区分GC诱因与真实瓶颈
很多“卡顿”或“抖动”常被误认为是 GC 引起的，但实际可能来自 JIT 编译切换、线程调度抖动、锁竞争或 I/O 等。Epsilon 的价值在于帮你做减法：关闭 GC 后若问题仍在，说明根源不在内存管理层面。
- 观察延迟毛刺（hiccups）是否消失：若使用 G1/ZGC 时出现周期性 10–50ms 暂停，换 Epsilon 后毛刺消失，基本可锁定为 GC 周期所致
- 对比吞吐量变化：关闭 GC 后吞吐提升明显（如 CPU 利用率下降、TPS 上升），说明原 GC 屏障和并发线程消耗了可观资源
- 验证内存分配行为本身的影响：比如测试对象创建速率极限、TLAB 分配效率、逃逸分析效果等，避免 GC 提前回收干扰观测
配置与运行要点
Epsilon 不参与内存回收，只做分配上限控制。关键不是“怎么启用”，而是“怎么配得准”。
- 必须显式设置堆上限：-Xmx1g（例如），否则默认堆可能过大，掩盖 OOM 行为；Epsilon 在达到该上限时直接抛
OutOfMemoryError: Java heap space - 禁用所有其他 GC 相关参数：-XX:+UseEpsilonGC 是唯一必需的 GC 开关，不要混用 -XX:+UseG1GC 或 -XX:+UnlockExperimentalVMOptions（JDK11+ 已默认解锁）
- 建议搭配 -XX:+PrintGCDetails -Xlog:gc*：确认日志中无 GC 事件输出，仅见 “Allocation request failed” 或 OOM 报错
- 避免与 ZGC/G1 并行测试时复用同一 JVM 参数模板，尤其注意 -XX:MaxGCPauseMillis 等参数对 Epsilon 无效且可能引发警告
典型测试场景示例
以高频对象分配 + 清理循环为例，对比不同 GC 下的行为差异：
- 用默认 GC（如 G1）运行时：每轮 clear() 后旧对象被回收，有 finalize 输出，最终因 GC 无法跟上分配速度而 OOM
- 换 Epsilon 后：全程无 finalize 调用、无 GC 日志，程序快速耗尽 -Xmx 限定内存并崩溃，耗时更短、路径更干净
- 此时若想测“纯分配开销”，可配合 JFR（Java Flight Recorder）开启
jdk.ObjectAllocationInNewTLAB事件，排除 GC 线程调度噪声后，获得更真实的分配延迟分布
注意事项与边界条件
Epsilon 不是通用生产 GC，它的“无操作”特性只在特定测试中成立。
- 不适用于长期运行服务：没有回收机制，内存必然耗尽；仅适合秒级到分钟级的压测任务
- 不处理元空间（Metaspace）、CodeCache、直接内存（Direct Buffer）：这些区域仍可能触发各自独立的清理或扩容行为
- finalize() 和 Cleaner 不会被调用：依赖对象销毁逻辑（如资源释放）的代码在 Epsilon 下会泄漏，测试前需确保无此类强依赖
- JDK 版本兼容性：Epsilon 自 JDK11 引入，JDK14 起已移除；确认环境为 JDK11–13，且未启用提前弃用警告（-XX:+ShowHiddenWarnings 可辅助判断）
