Epsilon收集器不执行垃圾回收，仅分配内存，堆满即终止JVM；专用于极端性能测试剥离GC干扰，及无垃圾、单次短时任务实现零延迟与确定性退出。
Epsilon收集器在Java中不执行任何垃圾回收，只分配内存，堆一满即终止JVM。它不是为长期运行服务的，而是专为两类场景设计：极端性能测试需剥离GC干扰，以及无垃圾产生、单次短时运行的任务需零延迟与确定性退出。
剥离GC噪声，精准归因延迟来源
在P999或P9999延迟压测中，传统GC（如G1、ZGC）会引入不可控停顿、缓存抖动和写屏障开销，掩盖真实瓶颈。Epsilon彻底移除这些变量，让延迟毛刺100%来自代码逻辑、系统调度、JIT编译或硬件层（如NIC中断、CPU频率切换）。实测显示，相同行情处理路径下，ZGC的P999为86μs，而Epsilon+对象池方案稳定在32±5μs——波动仅由硬件精度决定，与JVM内存管理无关。
- 用-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx256m启动，确保GC完全静默
- 禁用jstat -gc（无GC统计），改用jcmd <pid> VM.native_memory summary观测实时堆占用
- 避免使用finalize()、WeakReference等依赖回收机制的API，它们在Epsilon下永不触发
适配无垃圾、单次运行任务的物理确定性
某些任务天然无垃圾：比如策略回测脚本、配置校验工具、日志解析批处理，其对象生命周期严格绑定于单次执行，且总量可预估。这类任务无需GC介入——进程退出时OS自动回收全部内存，而GC线程调度反而浪费CPU周期、拖慢启动/结束速度。Epsilon在此类场景下将JVM退化为轻量级执行容器，消除TLAB同步、内存屏障、GC线程争用等冗余开销。
- 设定-Xmx即设定了任务最大资源边界，例如-Xmx64m表示该任务最多使用64MB堆，超限即以退出码137终止，信号明确、无歧义
- 配合Runtime.getRuntime().totalMemory() - freeMemory()可实时监控分配水位，用于动态判断是否逼近阈值
- 容器化部署时，-Xmx可与cgroup memory limit严格对齐，杜绝内存超卖与节点驱逐风险
作为内存压力与分配行为的基准标尺
Epsilon把“崩溃”转化为有效测量点。同一段代码在不同优化版本下，使用相同-Xmx参数运行，其存活时间直接反映单位时间内的对象生成率。例如：未优化版在-Xmx512m下运行8.2秒后退出；优化减少临时对象后，同样配置下运行12.6秒才退出——说明对象分配速率下降约35%，验证了低垃圾设计效果。
立即学习“Java免费学习笔记（深入）”；
- 记录JVM退出码（137或143）和运行时长，构成可复现、可比对的基准数据点
- 用AtomicLong累加关键路径对象创建次数，替代弱引用监听，避免GC依赖
- 对比不同实现（如Stream.collect() vs for-loop + ArrayList）的堆耗尽时间，量化内存效率差异
