Epsilon收集器不执行任何垃圾回收操作，仅分配内存；当堆满时直接抛出OutOfMemoryError，无降级或拦截机制。
因为Epsilon收集器的设计目标就是“不回收”，它压根没有垃圾回收逻辑。
它不是不想救，而是根本没装急救包
Epsilon被定位为一个“无操作”（No-Op）收集器，启动时就明确告诉JVM：我不做分配外的任何事——不触发GC，不移动对象，不整理内存，也不尝试释放任何空间。当物理堆（即-Xmx指定的堆上限）被填满，且新对象无法分配时，JVM按规范必须抛出OutOfMemoryError: Java heap space。Epsilon不会拦截、延迟或降级处理这个信号，因为它没有任何回收路径可退化。
与G1、ZGC等收集器的本质区别
其他收集器内置了多层应对机制：
- G1会在内存紧张时提前启动混合GC，尝试回收部分老年代Region；
- ZGC和Shenandoah在分配失败前会主动触发并发标记与回收周期；
而Epsilon连“最后尝试”都不提供——它把内存管理责任完全交还给应用层。一旦配置的堆耗尽，错误立刻暴露，不掩盖、不缓冲、不兜底。
立即学习“Java免费学习笔记（深入）”；
适用场景决定了它的“零容错”特性
Epsilon专为两类场景设计：
- 超短生命周期进程（如函数计算、单元测试、性能基准），运行期间本就不该产生可回收垃圾；
- 需要精确测量纯应用开销的实验环境，任何GC行为都会污染观测结果。
在这些场景下，“快速失败”反而是优势：OOM直接指向内存使用失控点（比如缓存无限膨胀、流式读取未分页），而不是被某次GC掩盖或延后暴露。
你不能指望它自愈，但可以靠它精准定位
用Epsilon时抛出OOM，通常说明：
- 对象分配总量已超过-Xmx硬限制；
- 不存在隐性泄漏（因为没GC干扰，堆占用曲线干净陡峭）；
- 问题一定出在对象创建逻辑或配置上，而非GC策略失效。
这时配合-XX:+PrintGCDetails（虽无GC日志，但能确认无回收发生）和堆转储（-XX:+HeapDumpOnOutOfMemoryError），能更快锁定大对象或长生命周期引用源。
