Epsilon GC在GraalVM原生镜像中完全不存在，因其依赖HotSpot JVM而原生镜像已彻底移除JVM；构建期可通过-H:MaxHeapSize=0或-H:InitialCollectionPolicy=none关闭运行时GC，实现类似“只分配不回收”的效果，但机制完全不同。
Java AOT（提前编译）和原生镜像（如 GraalVM Native Image）本身已完全脱离 JVM 运行时，因此 Epsilon GC 在原生镜像中不参与、也不起作用——它根本不存在于该执行模型中。
原生镜像没有 JVM，自然也没有 Epsilon GC
GraalVM 原生镜像在构建阶段完成静态分析、类初始化与 AOT 编译，生成的是独立的平台原生可执行文件，运行时不依赖 JVM、不加载 classloader、不启动 HotSpot VM。而 Epsilon GC 是 HotSpot JVM 中的一个具体垃圾回收器实现（通过 -XX:+UseEpsilonGC 启用），仅存在于 JVM 进程内。一旦进入原生镜像模式，JVM 本身已被移除，Epsilon GC 的代码、参数、堆管理逻辑全部失效。
- Epsilon 的源码（如
EpsilonHeap、EpsilonCollectorPolicy）属于 HotSpot GC 子系统，不会被包含进 native image 构建产物 - 原生镜像使用自己的内存管理模型：Image Heap（只读、构建期固化）、Runtime Heap（可写、由内置 GC 管理，非 JVM GC）
- 你无法在 native image 启动命令中传入
-XX:+UseEpsilonGC，JVM 参数对原生二进制无效
那 AOT 编译阶段能否“模拟”Epsilon 行为？
不能直接启用 Epsilon，但 AOT 构建过程存在一种功能上近似的策略：禁用运行时 GC。
- 通过
-H:+AllowIncompleteClasspath和--initialize-at-build-time将尽可能多的对象布局固化到 Image Heap，减少 Runtime Heap 分配 - 使用
-H:MaxHeapSize=0或-H:InitialCollectionPolicy=none可关闭原生镜像的运行时 GC，使其行为接近“分配即终止”——这与 Epsilon 的“只分配不回收”理念相似，但底层机制完全不同 - 注意：关闭 GC 后若 Runtime Heap 耗尽，进程会直接 crash（类似 Epsilon OOM），但无任何 JVM 错误日志，调试需依赖 native image 的 heap 报告或
-H:+PrintAnalysisCallTree
真正需要关注的内存边界不是 GC，而是初始化时机
原生镜像的关键约束不在“用哪个 GC”，而在“哪些类/资源在构建期初始化、哪些推迟到运行时”。这直接影响内存驻留位置和大小：
立即学习“Java免费学习笔记（深入）”；
-
--initialize-at-build-time：类静态块、常量、反射元数据等打入 Image Heap → 内存固化、不可修改 -
--initialize-at-run-time：延迟到启动时初始化 → 占用 Runtime Heap，受 GC 控制（若启用） - Epsilon 在 JVM 模式下常用于测试“最小堆行为”，但在原生镜像中，等效目标应是：最小化 Runtime Heap 使用，最大化 Image Heap 静态布局
结论：配合边界就是“零交集”
Epsilon GC 和 Java AOT / 原生镜像属于两个互斥的技术栈：前者是 JVM 内部可插拔的 GC 实现，后者是彻底绕过 JVM 的执行范式。它们的唯一联系，仅在于都服务于同一目标——降低启动开销与内存不确定性。但实现路径截然不同：一个在 JVM 里做减法（关掉 GC），一个在构建期做重构（去掉 JVM）。实际选型时，应根据部署场景决定走 JVM + Epsilon（如短生命周期批处理），还是走 native image（如 Serverless 函数、边缘设备）。
