Java 虚拟机家族考

说起 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 语言很慢”的形象就是在这时候开始在用户心中树立起来的。

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 和必要的本地代码。

• JavaInJava
  JavaInJava 是 Sun 公司 1997 年～1998 年间所研发的一个实验室性质的虚拟机，从名字就可以看出，它试图以 Java 语言来实现 Java 语言本身的运行环境，既所谓的“元循环”（Meta-Circular，是指使用语言自身来实现其运行环境）。它必须运行在另外一个宿主虚拟机之上，内部没有 JIT 编译器，代码只能以解释模式执行。在上世纪末主流 Java 虚拟机都未能很好解决性能问题的时代，开发这种项目，其执行速度大家可想而知。

• Maxine VM
  Maxine VM 和上面的 JavaInJava 非常相似，它也是一个几乎全部以 Java 代码实现（只有用于启动 JVM 的加载器使用 C 语言编写）的元循环 Java 虚拟机。这个项目于 2005 年开始，到现在仍然在发展之中，比起 JavaInJava，Maxine VM 就显得“靠谱”很多，它有先进的 JIT 编译器和垃圾收集器（但没有解释器），可在宿主模式或独立模式下执行，其执行效率已经接近了 HotSpot Client VM 的水平。

百家争鸣：BEA JRockit / IBM J9 VM

前面介绍了 Sun 公司的各种虚拟机，除了 Sun 公司以外，其他组织、公司也研发过不少虚拟机实现，其中规模最大、最著名的就是 BEA 和 IBM 公司了。

JRockit VM 曾经号称“世界上速度最快的 Java 虚拟机”（广告词，貌似 J9 VM 也这样说过），它是 BEA 公司在 2002 年从 Appeal Virtual Machines 公司收购获得的虚拟机。BEA 将其发展为一款专门为服务器硬件和服务端应用场景高度优化的虚拟机，由于专注于服务端应用，它可以不太关注于程序启动速度，因此 JRockit 内部不包含解析器实现，全部代码都靠即时编译器编译后执行。除此之外，JRockit 的垃圾收集器和 MissionControl 服务套件等部分的实现，在众多 Java 虚拟机中也一直处于领先水平。

IBM J9 VM 并不是 IBM 公司唯一的 Java 虚拟机，不过是目前 IBM 主力发展的 Java 虚拟机，J9 原本是内部开发代号，正式名称是“IBM Technology for Java Virtual Machine”，简称 IT4J，只是这个名字太拗口了一点，普及程度不如 J9。J9 VM 最初是由 IBM Ottawa 实验室一个 SmallTalk 的虚拟机扩展而来的，当时这个虚拟机有一个 bug 是因为 8k 值定义错误引起，工程师们花了很长时间终于发现并解决了这个错误，此后这个版本的虚拟机就被称为 K8 了，后来扩展出支持 Java 的虚拟机就被称为 J9 了。与 BEA JRockit 专注于服务端应用不同，IBM J9 的市场定位与 Sun HotSpot 比较接近，它是一款设计上从服务端到桌面应用再到嵌入式都全面考虑的多用途虚拟机，J9 的开发目的是作为 IBM 公司各种 Java 产品的执行平台，它的主要市场在和 IBM 产品（如 IBM WebSphere 等）搭配以及在 IBM AIX 和 z/OS 这些平台上部署 Java 应用。

除了 BEA 和 IBM 外，其他一些大公司如 HP、SAP 等也号称有自己的专属 JDK 和虚拟机，但是它们是通过从 Sun 购买版权的方式获得的，并非自己独立开发。

最终兵器：Azul VM/BEA Liquid VM

我们平时所提及的“高性能 Java 虚拟机”一般是指 HotSpot、JRockit、J9 这类在通用平台上运行的商用虚拟机，但其实 Azul VM 和 BEA Liquid VM 这类特定硬件平台专有的虚拟机才是“高性能”的最终兵器。

Azul VM 是 Azul Systems 公司在 HotSpot 基础上进行大量改进，运行于 Azul Systems 公司的专有硬件 Vega 系统上的 Java 虚拟机，每个 Azul VM 实例都可以管理至少数十个 CPU 和数百 GB 的内存的硬件资源，并提供在巨大内存范围内实现可控的 GC 时间的垃圾收集器、为专有硬件优化的线程调度等优秀特性。在 2010 年，Azul 开始从硬件转向软件，发布了自己的 Zing JVM，可以在通用 x86 平台上提供接近于 Vega 系统的特性。

Liquid VM 是 BEA 公司开发的，可以直接运行在自家 Hypervisor 系统上的 JRockit VM 的虚拟化版本，Liquid VM 不需要操作系统的支持，或者说它自己本身实现了一个专用操作系统的必要功能，如文件系统、网络支持等。由虚拟机越过通用操作系统直接控制硬件可以获得很多好处，如在线程调度时，不需要再进行内核态 / 用户态的切换等，这样可以最大限度地发挥硬件的能力，提升 Java 程序的执行性能。

挑战者：Apache Harmony / Google Android Dalvik VM

这节介绍的 Harmony VM 和 Dalvik VM 只能称作“虚拟机”，而不能称作“Java 虚拟机”，但是这两款虚拟机（以及所代表的技术体系）对最近三年的 Java 世界产生了非常大的影响和挑战，甚至有悲观的评论家认为成熟的 Java 生态系统有崩溃的可能。

Apache Harmony 是一个 Apache 软件基金会旗下以 Apache License 协议开源的实际兼容于 JDK 1.5 和 JDK 1.6 的 Java 程序运行平台，这个介绍相当拗口。它包含自己的虚拟机和 Java 库，用户可以在上面运行 Eclipse、Tomcat、Maven 等常见的 Java 程序，但是……它没有通过 TCK 认证，所以我们不得不用那么一长串拗口的语言来介绍它，而不能用一句“Apache 的 JDK”来说明。如果一个公司要宣布自己的运行平台“兼容于 Java 语言”，那就必须要通过 TCK（Technology Compatibility Kit）的兼容性测试，Apache 基金会曾要求 Sun 公司提供 TCK 的使用授权，但是一直遭到拒绝，直到 Oracle 收购了 Sun 公司之后，双方关系越闹越僵，最终导致 Apache 愤然退出 JCP（Java Community Process）组织，这是近代 Java 社区最严重的一次分裂。

在 Sun 把 JDK 开源形成 OpenJDK 之后，Apache Harmony 开源的优势被极大地削弱，甚至连 Harmony 项目的最大参与者 IBM 公司也宣布辞去 Harmony 项目管理主席的职位，参与 OpenJDK 项目的开发。虽然 Harmony 没有真正大规模商业运用过，但是它的许多代码（基本上是 Java 库部分的代码）被吸纳进 IBM 的 JDK7 实现以及 Google Android SDK 之中，尤其是对 Android 的发展起了很大推动作用。

说到 Android，这个时下最热门的移动数码设备平台在最近 3 年间的发展所取得的成果已经远远超越了 Java ME 在过去十多年所获得的成果，Android 让 Java 语言真正走进了移动数码设备领域，只是走的并非 Sun 公司原本想象的那一条路。

Dalvik VM 是 Android 平台的核心组成部分之一，它名字来源于冰岛一个名为 Dalvik 的小渔村。Dalvik VM 并不是一个 Java 虚拟机，它没有遵循 Java 虚拟机规范，不能直接执行 Java 的 class 文件，使用寄存器架构而不是 JVM 中常见的栈架构。但是它与 Java 却又有着千丝万缕的联系，它执行 dex（Dalvik Executable）文件可以通过 class 文件转化而来，使用 Java 语法编写应用程序，可以直接使用大部分的 Java API 等等。目前 Dalvik VM 随着 Android 一起处于迅猛发展阶段，在 Android 2.2 中已提供即时编译器实现，执行性能有了很大的提高。

没有成功，但并非失败：Mircosoft JVM 及其他

在十几年的 Java 虚拟机发展历程中，除去上面介绍那些被大规模商业应用过的 Java 虚拟机外，还有许多虚拟机是不为人知或者曾经绚丽过但最终湮灭的。我们以其中 Mircorsoft 公司的 JVM 来介绍一下。

也许 Java 程序员听起来可能会觉得惊讶，微软曾经是 Java 技术的铁杆支持者。在 Java 语言诞生的初期（1996 年～1998 年，以 JDK1.2 发布之前为分界），它的主要的应用之一是在浏览器中运行 Java Applets 程序，微软为了在 IE3 中支持 Java Applets 应用而开发了自己的 Java 虚拟机，虽然这款虚拟机只有 Windows 平台的版本（这很正常吧？），但却是当时 Windows 下性能最好的 Java 虚拟机，它在 1997 和 1998 连续两年获得了《PC Magazine》杂志的“编辑选择奖”。但好景不长，在 1997 年 10 月，Sun 公司正式以侵犯商标、不正当竞争等罪名控告微软，在随后对微软公司的垄断调查之中，这款虚拟机也曾作为证据之一被呈送法庭。这场官司的结果是微软赔偿 2000 万美金给 Sun，承诺终止其 Java 虚拟机的发展，并逐步在产品中移除 Java 虚拟机相关功能。

我们试想一下，如果当年 Sun 没有起诉微软公司，微软继续保持着对 Java 技术的热情，那 Java 的世界会变得更好还是更坏？.NET 技术是否会发展起来？但历史是没有如果的。其他在本文中没有介绍到的 Java 虚拟机还包括有（当然，应该还有很多笔者所不知道的）：

• JamVM： http://jamvm.sourceforge.net/
• cacaovm： http://www.cacaovm.org/
• SableVM： http://www.sablevm.org/
• Kaffe： http://www.kaffe.org/
• Jelatine JVM： http://jelatine.sourceforge.net/
• NanoVM： http://www.harbaum.org/till/nanovm/index.shtml
• MRP： http://mrp.codehaus.org/
• Moxie JVM： http://moxie.sourceforge.net/
• Jikes RVM： http://jikesrvm.org/

参考资料

本文撰写时主要参考了以下资料：

• http://en.wikipedia.org/wiki/Java_virtual_machine
• http://wikis.sun.com/display/HotSpotInternals/Home
• http://rednaxelafx.iteye.com/blog/858009

[1] Sun 与 BEA 分别在 2010、2008 年被 Oracle 公司收购，由于本文涉及到大量历史事件，为了避免混乱，依然保留 Sun 和 BEA 的名称。

感谢张凯峰对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。