Epsilon收集器不执行任何垃圾回收操作，仅分配内存；当堆满时直接抛出OutOfMemoryError，无降级或拦截机制。

因为Epsilon收集器的设计目标就是“不回收”，它压根没有垃圾回收逻辑。

它不是不想救，而是根本没装急救包

Epsilon被定位为一个“无操作”（No-Op）收集器，启动时就明确告诉JVM：我不做分配外的任何事——不触发GC，不移动对象，不整理内存，也不尝试释放任何空间。当物理堆（即-Xmx指定的堆上限）被填满，且新对象无法分配时，JVM按规范必须抛出OutOfMemoryError: Java heap space。Epsilon不会拦截、延迟或降级处理这个信号，因为它没有任何回收路径可退化。

与G1、ZGC等收集器的本质区别

其他收集器内置了多层应对机制：

• G1会在内存紧张时提前启动混合GC，尝试回收部分老年代Region；
• ZGC和Shenandoah在分配失败前会主动触发并发标记与回收周期；

而Epsilon连“最后尝试”都不提供——它把内存管理责任完全交还给应用层。一旦配置的堆耗尽，错误立刻暴露，不掩盖、不缓冲、不兜底。

适用场景决定了它的“零容错”特性

Epsilon专为两类场景设计：

javascript-typescript-typescript-scaffold

你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型

下载

• 超短生命周期进程（如函数计算、单元测试、性能基准），运行期间本就不该产生可回收垃圾；
• 需要精确测量纯应用开销的实验环境，任何GC行为都会污染观测结果。

在这些场景下，“快速失败”反而是优势：OOM直接指向内存使用失控点（比如缓存无限膨胀、流式读取未分页），而不是被某次GC掩盖或延后暴露。

你不能指望它自愈，但可以靠它精准定位

用Epsilon时抛出OOM，通常说明：

• 对象分配总量已超过-Xmx硬限制；
• 不存在隐性泄漏（因为没GC干扰，堆占用曲线干净陡峭）；
• 问题一定出在对象创建逻辑或配置上，而非GC策略失效。

这时配合-XX:+PrintGCDetails（虽无GC日志，但能确认无回收发生）和堆转储（-XX:+HeapDumpOnOutOfMemoryError），能更快锁定大对象或长生命周期引用源。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南