文章摘要(AI生成)
Epsilon GC 是 Java 在 JDK 11 引入的一种实验性垃圾回收器，具备唯一的功能：仅负责内存分配，而不进行对象回收。其工作机制非常简单：在内存分配时检查是否有足够的内存可用，若有则分配，若无则抛出 OutOfMemoryError 错误并终止程序。Epsilon GC 的设计目的是提供一个低延迟的内存分配策略，适用于性能测试和短生命周期的应用场景，尽管其在内存占用和吞吐量方面表现较差。与传统的垃圾回收机制不同，Epsilon GC 不执行任何回收过程，因此避免了与垃圾回收相关的开销。这种全新的“无回收”策略使得 Epsilon GC 成为一种特殊的选择，主要用于特定需求下的内存管理。
Java 中的垃圾回收器从未停止创新，但你能想象一个完全不做回收的垃圾回收器也被官方引入了吗？JEP 318 提出的 Epsilon GC 就是这样一个存在。它只负责分配内存，而永远不进行回收。
🔍 What：Epsilon GC 是什么？
Epsilon GC 是 JDK 11 引入的实验性垃圾回收器，启用参数为：
-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC
它是一个无操作（no-op）垃圾回收器，即：
- 只管理内存分配，不做任何对象回收；
- 内存耗尽后直接抛出
OutOfMemoryError并终止程序； - 不会执行任何垃圾收集周期，也不维护对象图或元数据；
- 使用无锁线程本地分配缓冲区（TLAB）进行线性分配。
Epsilon GC只负责内存分配，每次分配时检查剩余内存是否充足，若有足够空间则返回分配指针；否则直接抛出 OutOfMemoryError 并终止程序。由于没有任何垃圾回收或内存整理过程，使得其运行开销极低，适用于性能测试和短生命周期场景。下面流程图聚焦于Epsilon GC的核心逻辑:
🤔 Why：为什么需要一个不做回收的 GC？
Epsilon GC 诞生的目标是：
提供一个完全被动的垃圾回收器实现，具有限制的内存分配能力和尽可能低的延迟开销，代价是内存占用和吞吐量的增加。
下面这张图展示了典型垃圾回收器的生命周期：应用程序运行时不断分配对象，当 Eden 区满时触发 Minor GC，老年代满时触发 Major GC，必要时会有 Full GC 停顿。而特殊的 Epsilon GC 则完全不执行回收，只做内存分配，当堆空间耗尽时直接抛出异常终止程序。通过对比，我们可以直观理解 Epsilon GC“无回收”的工作模式与传统 GC 的区别：
📅 When：Epsilon 是什么时候引入的？
在 JDK 11 中支持的主流垃圾回收器，包括经典的 Parallel GC、G1 GC（默认）、CMS 以及两个实验性的垃圾回收器：ZGC 和 Epsilon GC。ZGC 是一个支持大堆且极低延迟的并发垃圾回收器，而 Epsilon GC 则是完全不回收的“哑巴”收集器。多样的 GC 选择，满足了不同应用场景的需求。
- Epsilon GC 概念最早由 OpenJDK 社区研究和开发，相关工作见于 JDK 10 开发周期。
- JEP 318 在 JDK 11 正式纳入，成为官方实验性垃圾回收器。
🌍 Where：Epsilon 适用于哪些场景？
| 场景类型 | 示例 | Epsilon GC 优势 |
|---|---|---|
| 性能基准测试 | 通过 JMH、吞吐测试评估程序性能 | 无 GC 干扰，获得纯净性能数据 |
| 短生命周期任务 | CLI 工具、构建工具、Serverless 函数 | 启动快，无 GC 延迟开销 |
| 内存压力和边界测试 | 验证内存分配阈值和OOM行为 | 简化测试，快速定位内存使用异常 |
| JVM / GC 开发和接口验证 | 设计自定义 GC 或验证 JVM 接口合理性 | 最简实现，便于实验和调试 |
| 极端低延迟应用 | 金融系统、在线服务需最低延迟保障 | 消除 GC 暂停及屏障开销 |
❗ 注意：Epsilon 不适用于长期运行的服务型程序，也不适合内存敏感型应用。
👤 Who：谁应该使用 Epsilon GC？
Epsilon 是为以下开发者群体设计的：
- 性能测试工程师：需要精准测试程序、JIT、内存使用行为；
- JVM/GC 开发者：想快速构建和测试自定义 GC 模块；
- 云平台/容器架构师：部署短命 Java 服务，希望消除 GC 冗余；
- 教育和研究者：教学/研究虚拟机的 GC 机制和行为。
⚙️ How：如何使用 Epsilon GC？
步骤一：使用 JVM 参数启用
java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx<size> YourApp
注意：由于不回收对象，内存用尽时程序会抛出异常并终止，建议配合 -Xmx 控制最大堆大小，并开启堆转储（-XX:+HeapDumpOnOutOfMemoryError）方便诊断。
Epsilon 采用线性分配，使用无锁线程本地分配缓冲区（TLAB），避免了大多数分配同步开销。屏障实现为空，无需管理对象图。
因无回收操作，所以调用 System.gc() 无效。
步骤二：确保程序生命周期和内存增长可控
由于不回收对象，内存会不断增长，一旦超出 -Xmx 限制将立即抛出：
java.lang.OutOfMemoryError: Java heap space
📌 总结
| 项目 | 描述 |
|---|---|
| 名称 | Epsilon GC（No-Op GC） |
| 引入版本 | JDK 10 |
| 是否回收对象 | ❌ 从不回收 |
| 最大优势 | 零 GC 干扰，性能可预测 |
| 典型用途 | 性能测试、CLI 工具、内存极限实验、GC 研究 |
| 启动方式 | -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC |
🧠 结语
Epsilon GC 并不是用来“跑生产”的 GC，但它的价值在于提供了一个没有任何 GC 干扰的环境，这对于性能测试、教学研究乃至新一代 GC 框架的设计都有重大意义。
正如 JVM 工程师们说的：
“有时候你最需要的，是一个什么都不做的垃圾回收器。”
评论区