graalvm原生镜像不优化gc而是绕开它：取消分代堆，编译期固化对象至数据段，运行时仅保留极简堆，默认用epsilon gc，内存管理重心前移至构建期，footprint大幅降低。
从内存区域视角看，GraalVM原生镜像不是“优化”传统垃圾回收（GC），而是直接绕开了它——它压根不依赖JVM堆模型和配套的GC算法。
取消分代堆结构，也就没有G1/ZGC/Shenandoah的用武之地
HotSpot JVM把堆划分为新生代（Eden、S0/S1）、老年代、元空间等区域，GC算法围绕这些区域的生命周期和对象晋升策略设计。而GraalVM原生镜像采用Substrate VM运行时，其内存模型是静态、扁平、预初始化的：
- 构建阶段就完成大部分对象实例化（如单例Bean、配置类、常量池），这些对象被固化进可执行文件的数据段，运行时不再分配
- 运行时仅保留极简堆（Heap），用于处理真正动态创建的对象（如HTTP请求中的DTO）
- 没有永久代/元空间概念，类元数据在编译期固化为只读内存页
垃圾回收逻辑被大幅压缩甚至移除
由于可达性分析已在编译期完成，且运行时对象图极小，原生镜像对GC的需求本质降级：
Multi-Brain Protocol
下载
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
- 默认启用的是轻量级的“Epsilon GC”——它不回收任何内存，仅做分配计数；适合短生命周期服务（如Serverless函数）
- 也可选配“Serial GC”，但仅作用于那个精简堆，不涉及分代、并发标记或内存压缩
- 没有Stop-The-World暂停的复杂调度，也没有写屏障、卡表、Remembered Set等JVM GC基础设施
内存管理重心前移到构建期
传统GC靠运行时动态决策，而GraalVM把内存行为决策提前固化：
- 通过堆快照（Heap Snapshot）机制，在编译时将Spring容器上下文、配置对象、静态资源等“冷数据”序列化为二进制映像，加载即用
- 利用封闭世界假设剔除未引用类与方法，减少堆初始大小和潜在分配点
- 反射、代理、资源加载等动态行为需显式声明（如
reflect-config.json），否则编译器无法纳入可达分析，也就不会为其预留内存结构
实际内存 footprint 变化一目了然
以典型Spring Boot Web应用为例：
- JVM模式：堆初始512MB，元空间256MB，线程栈每线程1MB，加上JIT代码缓存，RSS常超800MB
- 原生镜像模式：堆默认仅16–64MB（可配置），无元空间，无JIT缓存，线程栈更紧凑，RSS稳定在30–60MB
- 关键差异不在“回收效率”，而在“根本不需要回收那么多”——因为90%以上的内存需求已在构建期静态满足
