epsilon收集器不是用于运行应用，而是用于“撞墙”式测试——只分配不回收，堆满即确定性退出；专用于短生命周期任务（如策略回测、日志解析）和内存压测（剥离gc干扰，精准归因延迟与吞吐瓶颈）。
Java 的 Epsilon 收集器不是用来“运行”应用的，而是用来“撞墙”的——它不回收内存，只分配；堆一满，JVM 就确定性退出。这种设计让它在两类场景中不可替代：短生命周期任务和内存压测。
短生命周期任务：无状态、单次执行、内存可控
适合 Epsilon 的任务有明确特征：不跨请求复用 JVM、无长连接或缓存驻留、对象生命周期严格绑定单次执行。典型例子包括：
- HTTP 路由转发、DTO 转换、规则校验、事件格式化等轻量计算
- 策略回测脚本、配置校验工具、日志批量解析
- Serverless 函数（如 AWS Lambda、阿里云 FC），执行时间常为几毫秒到数秒
这些场景下，OS 在进程退出时自动回收全部内存，GC 线程调度、TLAB 同步、写屏障等开销反而拖慢启动与结束速度。Epsilon 把 JVM 退化为轻量执行容器，消除冗余开销。
内存压测：剥离 GC 干扰，精准归因延迟与吞吐瓶颈
在 P999/P9999 延迟压测中，G1 或 ZGC 可能引入周期性停顿、缓存抖动和写屏障开销，掩盖真实瓶颈。Epsilon 彻底移除 GC 变量，让所有毛刺 100% 来自代码逻辑、系统调度、JIT 编译或硬件层（如 NIC 中断、CPU 频率切换）。
- 若换用 Epsilon 后延迟毛刺消失，基本可锁定为 GC 周期所致
- 若吞吐提升明显（如 CPU 利用率下降、TPS 上升），说明原 GC 的并发线程与屏障消耗了可观资源
- 配合 JFR 开启 jdk.ObjectAllocationInNewTLAB 事件，可获取纯分配路径下的真实延迟分布
关键配置与约束
启用 Epsilon 必须同时指定三个要素，缺一不可：
- -Xmx：硬性堆上限（如 -Xmx64m），超限即退出，不尝试回收
- -XX:+UnlockExperimentalVMOptions：JDK 11–15 必需，解锁实验特性
- -XX:+UseEpsilonGC：唯一启用开关，禁用其他 GC 参数（如 -XX:+UseG1GC）
注意：JDK 17+ 已移除 Epsilon；避免使用 finalize()、WeakReference 等依赖回收的 API，它们在 Epsilon 下永不触发。
