说起Java虚拟机，许多Java程序员都会潜意识地把它与Sun[1]
HotSpot虚拟机等同看待，也许还有一些程序员会注意到BEA JRockit和IBM J9，但大多数人对JVM的认识都仅限于此了。
从1996年初Sun发布的JDK
1.0中所包含的Sun Classic
VM算起，Java虚拟机已经发展了15个年头，沧海桑田一瞬间，15年转眼而过，这期间曾经涌现、湮灭过许多或经典或优秀或有特色的虚拟机实现，在《Java虚拟机专栏》的第1篇中，我们先暂且把代码与技术放下，一起来回顾一下Java虚拟机家族的发展轨迹和历史变迁。
虚拟机始祖：Sun
Classic / Exact VM
以今天的视角来看，Sun
Classic VM的技术可能很原始，这款虚拟机的使命也早已终结。但仅凭它
“世界上第一款商用Java虚拟机”的头衔，就足够有令历史有记住它的理由。
1996年1月23日，Sun发布JDK
1.0，Java语言首次拥有了商用的正式运行环境，这个JDK中所带的虚拟机就是Classic
VM。这款虚拟机只能使用纯解释器方式来执行Java代码，如果要使用JIT编译器那就必须进行外挂，但是假如外挂了JIT编译器，JIT编译器就完全接管了虚拟机的执行系统，解释器便不再工作了。用户在这款虚拟机上执行java
version命令，将会看到类似下面这行的输出：
java
version "1.2.2"
Classic
VM (build JDK-1.2.2-001, green threads, sunwjit)
其中的“sunwjit”就是Sun提供的外挂编译器，其他类似的外挂编译器还有Symantec
JIT和shuJIT等。由于解释器和编译器不能配合工作，这就意味着如果要使用编译器执行，编译器就不得不为对每一个方法，每一行代码都进行编译，而无论它们执行的频率是否具有编译的价值。基于程序响应时间的压力，这些编译器根本不敢应用编译耗时稍高的优化技术，因此这个阶段的虚拟机即使用了JIT编译器输出本地代码，执行效率也和传统的C/C++程序有很大差距，“Java语言很慢”的形象就是在这时候开始在用户心中树立起来的。
相关厂商内容
白皮书下载：企业BPM(业务流程管理)宝典
Software AG webMethods BPMS 产品白皮书 12月14日QClub天津站：Global Day of Coderetreat
12月14日QClub上海站：Global Day of Coderetreat
提供全方位的云服务并配套完整的电商应用开发、运营解决方案，火速参赛！
Sun的虚拟机团队努力去解决Classic
VM所面临的各种问题，提升运行效率，在JDK 1.2时，曾在Solaris平台上发布过一款名为Exact
VM的虚拟机，它的执行系统已经具备现代高性能虚拟机雏形：如两级即时编译器、编译器与解释器混合工作模式等。Exact VM因它使用准确式内存管理（Exact
Memory Management，也可以叫Non-Conservative/Accurate Memory
Management）而得名，即虚拟机可以知道内存中某个位置的数据具体是什么类型。譬如内存中有一个32bit的整数123456，它到底是一个reference类型指向123456的内存地址还是一个数值为123456的整数，虚拟机将有能力分辨出来，这样才能在GC的时候准确判断堆上的数据是否还可能被使用。由于使用了准确式内存管理，Exact
VM可以抛弃掉以前Classic
VM基于handler的对象查找方式（原因是GC后对象将可能会被移动位置，如果地址为123456的对象移动到654321，在没有明确信息表明内存中哪些数据是reference的前提下，那虚拟机是不敢把内存中所有为123456的值改成654321的，所以要使用句柄来保持reference值的稳定），这样每次定位对象都少了一次间接查找的开销，提升执行性能。
虽然Exact
VM的技术相对Classic VM来说先进了许多，但是它命运显得十分英雄气短，在商业应用上只存在了很短暂的时间就被更为优秀的HotSpot
VM所取代，甚至还没有来得及发布Windows和Linux平台下的商用版本。而Classic VM的生命周期则相对长了许多，它在JDK 1.2之前是Sun
JDK中唯一的虚拟机，在JDK 1.2时，它与HotSpot VM并存，但默认是使用Classic VM（用户可用java
hotspot参数切换至HotSpot VM），而在JDK 1.3时，HotSpot VM成为默认虚拟机，它仍作为虚拟机的“备用选择”发布（使用java
classic参数切换），直到JDK 1.4的时候，Classic VM才正式退出商用虚拟机的历史舞台，与Exact VM一起进入了Sun Labs
Research VM之中。
武林盟主：Sun
HotSpot VM
HotSpot
VM相信所有Java程序员都知道，它是Sun
JDK和OpenJDK中所带的虚拟机，也是目前使用范围最广的Java虚拟机。但不一定所有人都知道的是，这个目前看起来“血统纯正”的虚拟机在最初并非由Sun公司开发，而是由一家名为“Longview
Technologies”的小公司设计的；甚至这个虚拟机最初并非是为Java语言而开发的，它来源于Strongtalk语言，而虚拟机中相当多的技术又是来源于一款支持Self语言实现“达到C语言50%以上的执行效率”的目标而设计的虚拟机，Sun公司注意到了这款虚拟机在JIT编译上有许多优秀的理念和实际效果，在1997年收购了Longview
Technologies公司，从而获得了HotSpot VM。
HotSpot
VM既继承了Sun之前两款商用虚拟机的优点（如前面提到的准确式内存管理），也有许多自己新的技术优势，如它名称中的HotSpot指的就是它的热点代码探测技术（其实Exact
VM之中也有与HotSpot几乎一样的热点探测，为了Exact VM和HotSpot
VM哪个成为Sun主要支持的产品VM，在Sun公司内部还大吵过一场，HotSpot打败Exact并不能算技术上的胜利），HotSpot
VM的热点代码探测能力可以通过执行计数器找出最具优编译价值的代码，然后通知JIT编译器以方法为单位进行编译。如果一个方法被频繁调用，或方法中回边（回边是指程序向后跳转的行为）次数很多，将会分别触发标准编译和OSR（栈上替换）编译动作。通过编译器与解释器恰当地协同工作，可以在最优化的程序响应时间与最佳执行性能中取得平衡，而且无需等待本地代码输出才能执行程序，即时编译的时间压力也相对减小，这样有助于引入更多的代码优化技术，输出质量更高的本地代码。
2006年的JavaOne大会上，Sun宣布最终会把Java开源，并在随后的一年，陆续地将JDK的各个部分（其中当然也包括了HotSpot
VM）在GPL协议下公开了源码，并在此基础上建立了OpenJDK。这样，HotSpot VM便成为了Sun
JDK和OpenJDK两个实现极度接近的JDK项目的共同虚拟机。
在2008年和2010年，Oracle分别收购了BEA和Sun公司，这样Oracle就同时拥有了这个星球上最优秀的两款Java虚拟机：JRockit
VM和HotSpot VM。Oracle宣布在不久的将来（大约应在JDK
8的时候）会完成这两款虚拟机的整合工作，使之优势互补。整合的方式大致上是在HotSpot的基础上，移植JRockit的优秀特性，譬如使用JRockit的垃圾回收器与MissionControl服务，使用HotSpot的JIT编译器与混合的运行时系统。当HotSpot吸收了JRockit的全部功力之后，能否一统虚拟机的江湖，成为真正的武林盟主，我们拭目以待。
小数派：Sun
Mobile-Embedded VM / Meta-Circular VM
Sun公司所研发的虚拟机可不仅有前面介绍到的服务器、桌面领域的商用虚拟机，除此之外，Sun面对移动和嵌入式市场，也发布过虚拟机产品，另外还有一类虚拟机，在设计之初就没有抱着商用的目的，仅仅是用于研究、验证某种技术和观点，又或者是作为一些规范的标准实现。这些虚拟机对于大部分不从事相关领域开发的Java程序员来说可能比较陌生，Sun公司发布的其他Java虚拟机有：
KVM
KVM中的K是“Kilobyte”的意思，它强调简单，轻量，高度可移植，但是运行速度比较慢。在Androd、iOS等智能手机操作系统出现前曾经在手机平台上得到非常广泛应用。
CDC/CLDC
HotSpot
CDC/CLDC全称是Connected（Limited）Device
Configuration，在JSR-139/JSR-218规范中进行定义，它希望在手机、电子书、PDA等设备上建立统一的Java编程接口，而CDC
HotSpot VM和CLDC HotSpot VM则是它们的一组参考实现。CDC/CLDC是整个Java ME的重要支柱，但从目前Android和Apple
iOS二分天下的移动数字设备市场看来，在这个领域中，Sun的虚拟机所面临的局面远不如服务器和桌面领域乐观。
Squawk
VM
Squawk
VM是由Sun开发，运行于Sun SPOT（Sun Small Programmable Object
Technology，一种手持的Wifi设备），也曾经运用于Java
Card。这是一个Java代码比重很高的嵌入式虚拟机实现，其中诸如类加载器、字节码验证器、垃圾收集器、解释器、编译器和线程调度都是Java语言本身所完成的，仅仅靠C语言来编写设备I/O和必要的本地代码。
