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</pid>观察实时堆占用 - 避免使用
finalize()、WeakReference等依赖回收机制的API，它们在Epsilon下永不触发
短时单次任务：用OS回收代替JVM回收
策略回测脚本、配置校验工具、日志批量解析等任务，对象生命周期严格绑定于单次执行，总量可预估，且进程退出后OS自动回收全部内存。此时GC线程调度、TLAB同步、内存屏障全是冗余开销。Epsilon将JVM退化为轻量执行容器，消除GC相关争用，加快启动与退出速度。
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
- 必须精确设置
-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“兜底”
- 不适合生产环境长期服务，但对验证、调优、教学极具价值
