## Sun Classic VM
- 世界上第一款商用 `Java` 虚拟机，`JDK1.4` 已经淘汰。
- 内部只有解释器，可以自己外挂`JIT`编译器，但是二者只能使用其一，不能配合工作。
- `hotspot` 内置了该虚拟机。
解释器，需要逐行解释执行，效率低下。譬如：如果循环两千次，循环体很大，每次执行都需要解释执行。
`JIT` 编译器，除了可以直接全部即时编译，还可以统计出那些代码执行频率比较高，这部分代码就是热点代码，`JIT` 编译器会将热点代码，提前编译成为机器指令，放在方法区缓存起来，下次执行到的时候，不需要解释执行，而是直接运行机器指令。（**此时的 Classic VM 还不具备热点代码探测的功能，只会全部提前编译**）
**即时编译器的执行效率很高，为什么不将它全部提前编译好缓存起来呢？**
- 全部提前编译，首次启动响应速度慢，会有卡顿的感觉，因为编译需要大量时间。（主要原因）
- 缓存代码，需要放在方法区，占用内存空间，容易溢出。
- 翻译成为机器指令，则这部分缓存的 `CodeCache` 是不能够直接跨平台，因为不同环境的机器指令是不大一样的，只能每次运行前就全部编译。
## Exact VM
为解决上一个虚拟机 `Classic VM` 的问题(解释器和即时编译器只能二选一)，`JDK 1.2` 的时候，提出来的虚拟机。
准确内存管理：`Exact Memory Management`，虚拟机可以知道内存中的某一个位置的数据具体是什么类型。
该虚拟机已经初步具备了现在高性能虚拟机的雏形：
- 热点代码探测
- 编译器和解释器混合工作
遗憾的是，`Exact VM` 只在`Solaris`短暂使用，后面就被 `Hotspot` 代替了。
## HotSpot VM
三大商用虚拟机之一。
由小公司 `“Longview Technologies”` 设计，该公司 1997 年被 `Sun` 收购，`Sun` 2009 年被甲骨文收购。
`JDK 1.3 HotSpot` 成为默认虚拟机，目前仍是，（`JRockit`和`J9`都没有方法区），`Hotspot`在服务器，桌面，移动端，嵌入式等都有应用。
`HotSpot` 名称来源主要是**热点代码探测技术**：
- 通过计数器找到最具有编译价值的代码，触发即时编译和栈上替换。
- 编译器和解释器协同工作，可以在响应时间和最佳执行性能中取得平衡。解释器负责是启动时间，而编译器主要是针对执行效率。
## JRockit
三大商用虚拟机之一。
`BEA` 公司研发的，2008年，`BEA` 公司被 `Oracle` 收购，`Oracle` 在`JDK8` 中，在 Hotspot 的基础上，整合了 `JRockit` 的优秀特性。
- 专注于服务端应用，不太关注启动速度，**内部不包含解释器实现**，全部靠即时编译器编译后执行。
- 号称世界上最快的虚拟机，执行性能强劲。
- 针对延迟敏感的应用也有解决方案 `“JRockit Real Time”`。
## J9
`J9`是三大商用虚拟机之一,全称`IBM Technology for Java Virtual Machine`，简称 `IT4J`，内部称`“J9”`。
定位和 `HotSpot` 差不多，号称世界上最快（在自己`IBM`的机器上最快）。
`2007` 年，`IBM` 发布了 `J9 VM`，命名`OpenJ9`，交给 `Eclipse` 基金会管理。
## KVM和CDC/CLDC Hotspot
- `Oracle` 在 `Java ME` 产品线上的两款虚拟机：`CDC/CLDC Hotspot Implementation VM`
- `KVM` 是 `CLDC-HI` 早期产品
- 主要是低端的移动端，简单，轻量，高度可移植
- 智能控制器，传感器
- 老人手机，功能机
## Azul VM
是与特定的硬件平台绑定，软硬件结合的专用的虚拟机，高性能`Java`虚拟机中的战斗机。
`Azul VM` 是 `Azul System` 公司在 `Hotspot` 基础上进行大量改进，运行在自家专用硬件 `Vega` 系统上的 Java 虚拟机。
每一个 `Azul VM` 可以管理至少数十个 `CPU` 和数百 `GB` 的内存，而且可以在**巨大内存范围内实现可控的GC时间**的垃圾收集器。
2010 年后，`Azul System` 发布了通用平台的 `Zing` 虚拟机。
## BEA Liquid VM
高性能 `Java` 虚拟机中的战斗机，`BEA`公司开发，运行在自己的`Hypervisor`系统上。
`Liquid VM` 不需要操作系统的支持，可以说本身已经实现了一个专用的操作系统的必要功能，比如线程调度，文件系统，网络支持等。`JRockit`停止开发，`Liquid VM` 研发也停止了。
## Apache Harmony
`Apache` 曾经推出过 `JDK 1.5`, `1.6` 兼容的 `Java` 运行平台 `Apache Harmony`。
由 `IBM` 和 `Intel` 联合开发，但是 `OpenJDK` 压制，并且 `Sun` 拒绝给予 `JCP` 认证，2011 年退役，其中 `Java` 类库代码吸纳进入 `Android SDK`中。
## Microsoft VM
微软推出的，在 `IE3` 中支持 `Java Applets`，但是 `Sun`公司 `1997`年指控微软侵权，后续微软抹去了 `Microsoft VM`。
## Taobao JVM
由阿里推出，基于`OpenJDK Hotspot Vm`，改造，深度定制一款高性能虚拟机。
- 创新的 `GCIH（GC invisible heap）`技术，实现了 `off-heap`，将生命周期较长的 `Java`对象从`heap`中移动到 `heap` 之外，并且`GC`不能管理 `GCIH` 内部的 `Java` 对象，降低了 `GC` 的回收频率和提高`GC`的回收效率。
- `GCIH` 中的对象可以多个`Java`虚拟机进程之间共享。
- 使用`crc32`指令实现`JVM intrinsic` 降低`JNI`的调用开销。
- `PMU hardware` 的`Java profiling tool` 和诊断协助功能
- 针对大数据场景的`ZenGC`
缺点：硬件严重依赖`Intel`的`cpu`，损失兼容性。
## Dalvik VM
- 谷歌开发，应用于`Android`系统，并且在`Android 2.2`中提供了`JIT`。只能称虚拟机，而不是`“Java虚拟机”`，没有遵循`Java`虚拟机规范。
- 不能直接执行`Java`的`class`文件。
- 基于寄存器架构，而不是栈的架构。
- 执行的是编译以后的`dex（dalvik Executale）`文件，执行效率比较高。`dex`文件可以通过`Class`文件转化而来，使用`Java`语法编写应用程序，可以直接使用大部分`Java API`。
- `Android 5.0` 使用提前编译（`Ahead of Time Compilation`,`AOT`）的`ART VM` 替换`Dalvik VM`。
PS：`Android`文件`.apk`修改文件后缀为`.zip`,解压之后就是很多文件,当然也包括`.dex`文件。
## Graal VM
理念：`“Run Program Faster Anywhere”`。
- 在`Hotspot VM`基础上增强，跨语言全栈虚拟机，可以作为任何语言的运行平台。
- 支持不同语言混用接口和对象
- 原理是将这些语言的源代码或者中间格式，通过解释器转化成为一种`Graal VM`接受的中间格式。
- 在运行时能够进行即时编译优化，获得更优秀的执行效率。
最后：具体`JVM`的内存结构，取决于其实现，不同产商或者同一个产商的不同版本，都可能存在一定的差异。一般我们说的，是指`Hotspot`虚拟机。
**【作者简介】**：
秦怀，公众号【**秦怀杂货店**】作者，技术之路不在一时，山高水长，纵使缓慢，驰而不息。个人写作方向：Java源码解析，JDBC，Mybatis，Spring，redis，分布式，剑指Offer，LeetCode等，认真写好每一篇文章，不喜欢标题党，不喜欢花里胡哨，大多写系列文章，不能保证我写的都完全正确，但是我保证所写的均经过实践或者查找资料。遗漏或者错误之处，还望指正。
[2020年我写了什么？](http://aphysia.cn/archives/2020)
[开源编程笔记](https://damaer.github.io/Coding/#/)
平日时间宝贵，只能使用晚上以及周末时间学习写作，关注我，我们一起成长吧~