§2.1.7 JVM类型对比（HotSpot / OpenJ9 / GraalVM）
考察意图：是否了解JVM生态的多样性，能根据场景推荐合适的JVM实现。
回答样板：
主流JVM实现有三个阵营：
HotSpot VM——Oracle/OpenJDK默认，绝对主流
- 市场份额：Java服务端90%+在用
- 核心优势：**C2编译器（Server Compiler）**做了二十多年极致优化，逃逸分析、内联、循环优化极其成熟；G1/ZGC等现代回收器最先落地；生态最完整
- JDK 8起HotSpot与JRockit合并，吸收了JRockit的Mission Control、Flight Recorder（JFR）等运维工具
- 劣势：启动慢、内存占用高——Spring Boot应用空跑也要200MB+堆。不适合短生命周期场景（Serverless、FaaS）
OpenJ9（Eclipse OpenJ9）——IBM捐献，低内存场景
- 前身是IBM J9 VM，2017年捐给Eclipse基金会
- 核心优势：极低内存占用——同等应用比HotSpot少30-50%内存；启动速度快；Shared Classes Cache（SCC）——AOT编译缓存，多次启动复用编译结果
- 垃圾回收：GenCon（分代并发，类似G1）+ Balanced（针对大堆）+ Metronome（实时GC，可配置停顿上限）
- 劣势：生态和工具链不如HotSpot完善，部分框架兼容性问题；G1/ZGC等效方案不如HotSpot成熟
- 适用场景：云原生/Serverless（启动快、内存省）、微服务容器化部署（每个Pod省200MB很可观）、嵌入式设备
GraalVM——多语言+AOT编译
- Oracle实验室项目，定位是"通用虚拟机"——不止跑Java，还能跑JavaScript、Python、Ruby、R、WASM
- 两大杀手级特性：
- Native Image（AOT编译）：将Java应用编译为独立二进制，毫秒级启动、内存占用几十MB，非常适合Serverless和容器化。Spring Boot 3.0+官方支持GraalVM Native Image
- Truffle框架：多语言互调用，Java代码直接调Python/JS函数，零JNI开销
- 两种模式：Community Edition（免费，Native Image支持有限）+ Enterprise Edition（收费，Native Image+PGO优化+多语言商业支持）
- 劣势：AOT编译限制——限制反射/动态代理/动态类加载（需要配置
reflect-config.json等元数据）；编译时间长（小项目几分钟，大项目几十分钟）；闭包分析可能漏掉运行时动态行为导致编译失败 - 适用场景：Serverless/FaaS（毫秒级冷启动）、CLI工具、嵌入式、微服务容器镜像瘦身
场景选型速览：
| 场景 | 推荐JVM | 原因 |
|---|---|---|
| 传统服务端/企业应用 | HotSpot | 生态成熟、性能最稳定、GC方案最丰富 |
| 云原生/容器化微服务 | OpenJ9 或 GraalVM | 内存省、启动快、镜像小 |
| Serverless/FaaS | GraalVM Native Image | 毫秒启动、极低内存 |
| 多语言混合项目 | GraalVM Truffle | Java+Python/JS/R互调 |
| 嵌入式/IoT | OpenJ9 | 内存占用可控 |
| 实时响应（金融/交易） | HotSpot + ZGC | 亚毫秒停顿 |
陷阱提示：只知道HotSpot不知道有其他JVM实现；把GraalVM说成"就是编译成二进制的"忽略了多语言和Truffle；不知道GraalVM Native Image的限制（反射配置、编译时间）。