1.虚拟机始祖：Sun Classic / Exact VM

1996，Sun公司发布JDK 1.0，所带虚拟机为Classic VM。

• 纯解释器方式执行Java代码
• 使用即时编译器必须进行外挂

Sun团队，JDK 1.2，发布Exact VM虚拟机

• 具备现代高性能虚拟机雏形
• 热点探测，两极即时编译器、编译器与解释器混合工作模式

两者最终被HotSpot VM所取代

• JDK 1.2 - Classic与HotSpot并存，默认为Classic
• JDK 1.3 - 默认为HotSpot
• JDK 1.4 - Classic退出商用虚拟机舞台

2.武林盟主：HotSpot VM

• Sun / OracleJDK 和 OpenJDK 中的默认Java虚拟机

3.天下第二：BEA JRockit / IBM J9 VM

BEA公司的JRockit

• 专注于服务器端
• 不包含解释器实现，代码全靠即时编译器编译后执行
• BEA公司被Oracle公司收购，如今不再发展

IBM公司的IBM J9

• J9虚拟机
• 市场定位与HotSpot接近，全面考虑服务端、桌面应用、嵌入式

4.小家碧玉：Mobile / Embedded

Sun / Oracle 公司产品

• 面向移动和嵌入式市场
• 前途并不乐观

5.软硬合璧：BEA Liquid VM / Azul VM

软硬合璧：与特定硬件平台绑定、软硬件配合工作的专有虚拟机

越过通用操作系统直接控制硬件，最大限度发挥硬件能力

Liquid VM

• 被称为JRockit VE
• 不需要操作系统支持

Azul VM

• 运行于Azul Systems公司的专有硬件Vega系统上
• Vega生产线被放弃，投入Zing与Zulu产品线

6.挑战者：Apache Harmony / Google Android Dalvik VM

Apache Harmony

• 率先开源
• 推动了Android发展

Google Android Dalvik VM

• 曾经是Android平台的核心组件之一
• 在Android5.0中ART全面替代了Dalvik虚拟机

7.Java虚拟机未来展望

7.1 Graal VM：无语言倾向

• 2018年4月，Oracle Labs公布
• 官方称为“Universal VM”和“Polyglot VM”
• HotSpot基础上诞生
• 程序特化：将这些语言的代码编译后的中间格式通过解释器转换为能被Graal VM接收的中间表达形式

7.2 Graal编译器：新一代即时编译器

HotSpot中原有编译器：

• CI：编译时间短，输出代码优化程度低
• C2：编译时间长，输出代码优化程度高

Graal编译器

• 以C2替代者身份登场
• 借鉴了C2的优势，输出质量相近，开发效率与拓展型更强，更复杂的优化

7.3 Substrate VM：向Native迈进

小型微服务应用架构下，Java表现出不适应，需要预热才能达到最高性能

提前编译：相对于即时编译，可以减少即时编译带来的预热时间，但破坏了Java“一次编写，到处运行的承诺”

Substrate VM

• 好处：显著降低内存占用及启动时间
• 十分适合嵌入其他系统