Epsilon收集器：无需垃圾回收的实验性工具与应用场景

Epsilon收集器是“只分配、不回收”的实验性GC工具，用于剥离GC干扰以精准定位性能瓶颈、加速短时任务、适配Serverless场景及内存压力测试，仅适用于Java 11+且需显式启用。

Epsilon收集器不是用来替代G1或ZGC的常规GC方案，而是一个“只分配、不回收”的实验性工具。它不清理任何对象，堆一满就抛出OutOfMemoryError并退出JVM。它的价值不在长期运行，而在精准控制、极致轻量和干扰剥离。

性能压测：剥离GC噪声，定位真实瓶颈

在P999/P9999延迟敏感型压测中，传统GC会引入停顿、写屏障开销与缓存抖动，掩盖代码本身或系统层的问题。Epsilon彻底移除这些变量，让所有毛刺100%来自业务逻辑、JIT编译、调度抖动或硬件中断（如网卡中断、CPU降频）。例如同一行情处理路径下，ZGC的P999为86μs，而Epsilon+对象池方案稳定在32±5μs——波动仅由硬件精度决定。

• 启动参数：-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx256m
• 禁用jstat -gc（无GC统计），改用jcmd <pid> VM.native_memory summary观察实时堆占用
• 避免使用finalize()、WeakReference等依赖回收机制的API，它们在Epsilon下永不触发

短时单次任务：用OS回收代替JVM回收

策略回测脚本、配置校验工具、日志批量解析等任务，对象生命周期严格绑定于单次执行，总量可预估，且进程退出后OS自动回收全部内存。此时GC线程调度、TLAB同步、内存屏障全是冗余开销。Epsilon将JVM退化为轻量执行容器，消除GC相关争用，加快启动与退出速度。

• 必须精确设置-Xmx（如-Xmx64m），确保全程分配不超限
• 适合无状态、无长连接、无静态缓存、无异步回调驻留对象的场景
• 不兼容Netty连接池、Spring Bean懒加载、全局静态Map等需堆驻留的设计

Serverless函数：匹配毫秒级生命周期

AWS Lambda、阿里云FC等平台上的Java函数通常执行几毫秒到数秒，JVM不复用、无跨请求状态。传统GC的周期扫描、并发标记反而浪费CPU、引入抖动、抬高冷启动延迟。Epsilon零暂停、零后台线程、零回收逻辑，天然适配这一模型。

• 配合GraalVM原生镜像使用效果更佳：GraalVM消除JVM启动开销，Epsilon消除GC运行开销，端到端冷启动可压缩至20–50ms
• Dockerfile中建议硬编码内存上限：ENTRYPOINT ["java", "-Xmx32m", "-XX:+UseEpsilonGC", "-jar", "app.jar"]
• 仅支持Java 11+，且需显式启用实验选项

内存压力测试与调试分析

当需要验证应用是否会在限定内存内完成任务时，Epsilon是理想探针。例如设定-Xmx1g，若程序因OOM退出，说明实际分配超限，可结合heap dump分析泄漏点或分配热点；若正常结束，则证明内存预算合理。它也常用于VM开发中验证GC接口最小实现的健壮性。

• 可用于发现隐蔽的内存膨胀问题，比如无意中缓存了大量中间结果
• 帮助开发者建立对应用真实内存足迹的感知，而非依赖GC“兜底”
• 不适合生产环境长期服务，但对验证、调优、教学极具价值