Sun Classic VM
1996年, Sun发布了JDK 1.0。Java语言有了第一个正式版本的运行环境Sun Classic VM。 这款虚拟机只能使用解释器方式执行Java代码，如果想使用即时编译器就必须外挂, 但是外挂后的即时编译器就会完全接管JVM的执行系统, 这意味着即时编译器和解释器是不能配合工作的。
java -version "1.2.2"
Classic VM (build JDK-1.2-001, green threads, sunwjit)
sunwjit(Sun Workshop JIT)就是Sun提供的外挂即时编译器。由于编译器和解释器是不能配合工作，所以当即时编译器接管了JVM后，无论代码是否具有编译的价值，它都会对每行代码进行编译，这个时期编译器也不敢应用编译耗时较高的优化技术,也导致了大家会觉得”Java语言很慢“。
Exact VM
为了解决Classic虚拟机的各种问题，Sun曾研发了一款名为Exact的虚拟机。Exact的编译执行系统在当时已经具备了现代高性能虚拟机雏形，如热点探测、两级即时编译、编译器与解释器混合工作模式等。
Exact VM因使用准确式内存管理而命名。准确式内存管理是指虚拟机可以知道内存中某个位置的数据是什么类型。例如内存中有一个32bit的整数123456, 虚拟机能分辨出它到底是一个数值为123456的整数，还是一个指向了123456内存地址的引用类型。
虽然Exact VM的技术非常先进，但是命运不佳，很快就被从外部引入的HotSpot取代，在JDK1.3版本中,HotSpot成为默认虚拟机，它仍作为”备选“发布，到JDK 1.4时, 就退出商业舞台。
HotSpot VM
HotSpot虚拟机是Sun/OracleJDK和OpenJDK默认的虚拟机，得益于Sun/OracleJDK在Java应用中的统治地位，HotSpot也成为了使用最广泛的虚拟机。我们知道HotSpot不是Sun自研的虚拟机，是由一家名为"Longview Technologies"的小公司设计，Sun当时注意到HotSpot在即时编译等多个方面有优秀的理念和实际成果，在1997年就收购了"Longview Technologies"。
HotSpot即继承了Sun之前虚拟机的优点（如准确式内存管理），也有许多新的技术优势。HotSpot这个名字就代表了其具有的热点代码探测技术。热点代码探测能力可以通过执行计数器找出最具有编译价值的代码，然后通知即时编译器已“方法”为单位进行编译。
通过编译器和解释器的协同工作，可以在最优化的响应时间与最佳执行性能中取得平衡，而无需等待本地代码输出才能执行程序，即时编译的压力也相对减小，也可以探索更复杂的代码优化技术，输出质量更高的本地代码。
Mobile/Embedded VM
Oracle在Java ME产品线上的虚拟机有CDC-HI和CLDC-HI。可是Java ME的虚拟机所处的位置比较尴尬，它最大的应用市场——智能手机这块已经被Android和IOS二分天下了。
而在嵌入式系统上，主打高端的CDC-HI经过多年的扩充，已经和Java SE非常接近了，大家能用Java SE的地方自然就不愿意用Java ME了。面向更低端设备的CLDC-HI在智能控制器、传感器等领域还算有一片市场，目前CLDC中活得最好的产品是KVM, 国内的老人机和欠发达地区的功能手机都还在使用这种简单、资源消耗也更小的Java ME虚拟机。
BEA JRockit/IBM J9 VM
除了Sun/Oracle公司以外，也有其他组织、公司开发过虚拟机。它们分别是BEA System公司的JRockit和IBM公司的IBM J9。
JRockit号称是世界上速度最快的虚拟机，它是BEA在2002年从Appeal Virtual Machines 公司收购获得的Java虚拟机。BEA将其打造成了一款专门为服务端硬件和服务端应用场景高度优化的虚拟机，所以它不太关注程序的启动速度，JRockit的内部不包含解释器实现，全部代码都靠即时编译器编译执行。除此之外，JRockit的垃圾收集器和Java Mission Control 故障处理套件等的实现，在当时众多虚拟机中也处于领先水平。JRockit随着BEA被Oracle收购，也不再继续发展，永远停留在R28版本。
IBM J9是IBM公司主力发展的一款虚拟机，这款虚拟机的市场定位与HotSpot比较接近，它是一款在设计上全面考虑服务端、桌面应用，再到嵌入式的多用途虚拟机，开发J9的目的是为了应用在IBM公司各种JAVA产品上。直到今天，IBM J9依然非常活跃，它的职责分离与模块化做得比HotSpot更优秀，由J9抽象封装出来的核心组件库（包括垃圾收集器、即时编译器、诊断监控子系统）就单独构成了IBM OMR项目，可以在其他语言平台如Ruby、Python中快速组装成相应的功能。2016年，IBM将OMR和J9虚拟机完全开源，并捐献给了Eclipse基金会。
除了BEA和IBM公司外，其他大公司也号称有自己的专属虚拟机，但是它们要么是通过从Sun/Oracle公司购买版权获得的额，要么是基于OpenJDK项目改进而来的（如阿里巴巴、Twitter)，都并非是独立开发。
BEA Liquid VM/Azul VM
我们常提及的虚拟机往往是在通用硬件平台上运行的，还有一类专门与特定硬件平台绑定、软硬件配合工作的虚拟机，往往能够实现更高的执行性能，或提供某些特殊的功能特性。 这类虚拟机的代表是BEA Liquid VM 和 Azul VM。
Liquid可以运行在自家的Hypervisor系统上，不需要操作系统的支持，由虚拟机直接控制硬件。这样做有很多好处，如在线程调度时不再需要进行内核态和用户态的切换，最大限度的发挥了硬件实力，提升Java程序的执行性能。
Azul VM是在HotSpot的基础上做了大量改造，并应用于Azul System公司的专有硬件Vega系统上的虚拟机。每个Azul VM实例都可以管理至少数十个CPU和数百GB的内存。并提供了赫赫有名的PGC和C4垃圾收集器。由于要推动在专有硬件上虚拟机升级发展，需要耗费更高昂的成本，也难以借助社区的力量， Azul System最终也放弃了Vega产品线，把经历投入到Zing和Zulu产品线中。
Zing虚拟机是从某个HotSpot分支基础上独立出来开发的高性能Java虚拟机，它可以运行在通用的Linux/x86-64平台上。Zing的PGC、C4收集器可以轻易支持TB级别的堆内存。Zing的Ready Now！功能可以利用之前运行时收集到的性能监控数据，引导虚拟机在启动后快速达到稳定的高性能水平，减少启动后从解释执行到即时编译等待的时间。Zing自带的ZVision/ZVRobot功能可以方便用户监控Java虚拟机的运行状态，从找出热点代码到对象分配监控、锁竞争监控等，易于监控也是Zing的核心卖点。
Apache Harmony/Google Android Dalvik VM
Apache Harmony 是Apache软件基金会旗下以Apache License协议开源的Java程序运行平台，它含有自己的虚拟机和Java类库API，用户可以在其上运行Eclipse、Tomcat、Maven等Java程序。但是,它并没有通过TCK认证，所有我们不能用一句”Apache的JDK"或者"Apache的Java虚拟机“来代指。
一个公司要宣称自己的运行平台”兼容于Java技术体系“，那该运行平台就必须要通过TCK(Technology Compatibility Kit)的兼容性测试，Apache基金会曾要求Sun提供TCK的授权，但是一直遭到各种理由的拖延和搪塞，Oracle收购Sun公司后，关系越闹越僵，最终导致Apache基金会愤然退出JCP组织。
Dalvik虚拟机曾经是Android平台的核心组成部分之一。Dalvik虚拟机并不是一个Java虚拟机，它没有遵循《Java虚拟机规范》，不能直接执行Java的Class文件，使用的也不是Java虚拟机场景的栈架构，而是寄存器架构。但是它又与Java有着千丝万缕的联系，它使用Java语法编写应用程序，可以直接使用绝大部分的Java API等。在Android发展早期，Dalvik虚拟机也迅速流行，在Android2.2中开始提供即时编译器实现，执行性能又进一步提高。但是到了Android4.4时代，支持提前编译的ART虚拟机迅速崛起，提前编译比即时编译更容易获得高性能，所以在Android5.0里ART就全面代替了Dalvik虚拟机。
