1.4 Java虚拟机发展史上一节我们从整个Java技术的角度观察了Java 技术的发展许多Java程序员都会潜意识地把它与Sun公司的HotSpot虚拟机等同看待也许还有一些程序员会注意到BEA.JRockit和IBM J9但对JVM的认识不仅仅只有这些。从1996年初Sun公司发布的JDK1.0中所包含的SunClassicVM到今天曾经涌现、湮灭过许多或经典或优秀或有特色的虚拟机实现在这一- 节中我们先暂且把代码与技术放下 一起来回顾- -下Java 虛拟机家族的发展轨迹和历史变迁。1.4.1 Sun Classic / Exact VM以今天的视角来看Sun Classic VM的技术可能很原始这款虚拟机的使命也早已终结。但仅凭它“世界上第-款商用Java虚拟机”的头衔就足够有让历史记住它的理由。1996年1月23日Sun公司发布JDK 1.0Java 语言首次拥有了商用的正式运行环境这个JDK中所带的虛拟机就是ClassicVM。这款虚拟机只能使用纯解释器方式来执行Java代码如果要使用JIT编译器就必须进行外挂。但是假如外挂了JIT编译器JIT编译器就完全接管了虚拟机的执行系统解释器便不再工作了。用户在这款虚拟机上执行java-version命令将会看到类似下面这行输出:java version 1.2.2Classic VM (build JDK-1.2.2-001. green threads, sunwjit)其中的“sunwjit就是Sun提供的外挂编译器其他类似的外挂编译器还有SymantecJIT和shuJIT等。由于解释器和编译器不能配合工作这就意味着如果要使用编译器执行编译器就不得不对每-一个方法、每一行代码都进行编译而无论它们执行的频率是否具有编译的价值。基于程序响应时间的压力这些编译器根本不敢应用编译耗时稍高的优化技术因此这个阶段的虚拟机即使用了JIT编译器输出本地代码执行效率也和传统的C/C程序有很大差距“Java 语言很慢”的形象就是在这时候开始在用户心中树立起来的。Sun的虚拟机团队努力去解决ClassicVM所面临的各种问题提升运行效率。在JDK1.2时曾在Solaris平台上发布过一-款名为ExactVM的虚拟机它的执行系统已经具备现.代高性能虚拟机的雏形:如两级即时编译器、编译器与解释器混合工作模式等。ExactVM因它使用准确式内存管理( Exact Memory Management也可以叫Non-Conservative/AccurateMemory Management)而得名即虚拟机可以知道内存中某个位置的数据具体是什么类型。譬如内存中有一个32位的整数123456它到底是-一reference 类型指向123456 的内存地址还是一一个数值为123456的整数虚拟机将有能力分辨出来这样才能在GC (垃圾收集)的时候准确判断堆上的数据是否还可能被使用。由于使用了准确式内存管理ExactVM可以拋弃以前Classic VM基于handler的对象查找方式(原因是进行GC后对象将可能会被移动位置如果将地址为123456的对象移动到654321在没有明确信息表明内存中哪些数据是reference的前提下虚拟机是不敢把内存中所有为123456的值改成654321的所以要使用句柄来保持reference值的稳定)这样每次定位对象都少了一次间接查找的开销提升执行性能。虽然Exact VM的技术相对Classic VM来说先进了许多但是在商业应用上只存在了很短暂的时间就被更为优秀的HotSpotVM所取代甚至还没有来得及发布Windows和Linux平台下的商用版本。而ClassicVM的生命周期则相对长了许多它在JDK1.2之前是SunJDK中唯- -的虚拟机 在JDK 1.2时它与HotSpot VM并存但默认使用的是Classic VM(用户可用java-hotspot参数切换至HotSpot VM)而在JDK 1.3 时HotSpot VM成为默认虚拟机但Classic VM仍作为虚拟机的“备用选择”发布(使用java-classic参数切换)直到JDK1.4的时候ClassicVM才完全退出商用虚拟机的历史舞台与ExactVM--起进人了Sun Labs Research VM之中。1.4.2 Sun HotSpot VM提起HotSpotVM相信所有Java程序员都知道它是SunJDK和OpenJDK中所带的虚拟机也是目前使用范围最广的Java虚拟机。但不一定所有人都知道的是这个目前看起来“血统纯正”的虚拟机在最初并非由Sun公司开发而是由一-家名为“LongviewTechnologies的小公司设计的;甚至这个虚拟机最初并非是为Java语言而开发的它来源于Strongalk VM而这款虚拟机中相当多的技术又是来源于- - 款支持Self语言实现“达到C语言50%以上的执行效率”的目标而设计的虚拟机Sun公司注意到了这款虚拟机在JIT编译.上有许多优秀的理念和实际效果在1997年收购了Longview Technologies 公司从而获得了HotSpot VM。HotSpotVM既继承了Sun之前两款商用虚拟机的优点(如前面提到的准确式内存管理)也有许多自己新的技术优势如它名称中的HotSpot指的就是它的热点代码探测技术(其实两个VM基本上是同时期的独立产品HotSpot 还稍早- -些HotSpot 一开始就是准确式GC而Exact VM之中也有与HotSpot几乎一样的热点探测。为了Exact VM和HotSpotVM哪个成为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年和2009年Oracle 公司分别收购了BEA公司和Sun公司这样Oracle就同时拥有了两款优秀的Java虚拟机: JRockit VM和HotSpot VM。Oracle 公司宣布在不久的将来(大约应在发布JDK 8的时候)会完成这两款虚拟机的整合工作使之优势互补。整合的方式大致上是在HotSpot的基础上移植JRockit的优秀特性譬如使用JRockit 的垃圾回收器与MissionControl服务使用HotSpot的JIT编译器与混合的运行时系统。1.4.3 Sun Mobile-Embedded VM / Meta-Circular VMSun公司所研发的虚拟机可不仅有前面介绍的服务器、桌面领域的商用虚拟机除此之外Sun 公司面对移动和嵌人式市场也发布过虚拟机产品另外还有一-类虚拟机在设计之初就没抱有商用的目的仅仅是用于研究、验证某种技术和观点又或者是作为一.些规范的标准实现。这些虚拟机对于大部分不从事相关领域开发的Java程序员来说可能比较陌生。Sun公司发布的其他Java虛拟机有:(1) KVMKVM中的K是“Kilobyte的意思它强调简单、轻量、高度可移植但是运行速度比较慢。在Android、iOS等智能手机操作系统出现前曾经在手机平台上得到非常广泛的应用。(2) CDC/CLDC HotSpot ImplementationCDC/CLDC全称是Connected (Limited) Device Configuration在JSR-139/JSR-218规范中进行定义它希望在手机、电子书、PDA等设备上建立统一的Java编程接口而CDC-HI VM和CLDC-HI VM则是它们的一-组参考实现。CDC/CLDC是整个Java ME的重要支柱但从目前Android和iOS二分天下的移动数字设备市场看来在这个领域中Sun 的虛拟机所面临的局面远不如服务器和桌面领域乐观。(3) Squawk VMSquawk VM由Sun公司开发运行于Sun SPOT (Sun Small Programmable Object Technology,- -种手持的WiFi 设备)也曾经运用于Java Card.这是-一个Java代码比重很高的嵌人式虚拟机实现其中诸如类加载器、字节码验证器、垃圾收集器、解释器、编译器和线程调度都是 Java语言本身完成的仅仅靠C语言来编写设备I/O和必要的本地代码。(4) JavaInJavaJavalnJava是Sun公司于1997年~ 1998 年间研发的一个实验室性质的虚拟机从名字就可以看出它试图以Java语言来实现Java语言本身的运行环境既所谓的“元循环”(Meta-Circular是指使用语言自身来实现其运行环境)。它必须运行在另外一个宿主虚拟机之上内部没有JIT编译器代码只能以解释模式执行。在20世纪末主流Java虚拟机都未能很好解决性能问题的时代开发这种项目其执行速度可想而知。(5) Maxine VMMaxine VM和上面的JavalnJava非常相似它也是一个几乎全部以Java代码实现(只有用于启动JVM的加载器使用C语言编写)的元循环Java虚拟机。这个项目于2005年开始到现在仍然在发展之中比起JavaInJavaMaxine VM就显得“靠谱”很多它有先进的JIT编译器和垃圾收集器(但没有解释器)可在宿主模式或独立模式下执行其执行效率.已经接近了HotSpot Client VM的水平。1.4.4 BEA JRockit I IBM J9 VM前面介绍了Sun公司的各种虚拟机除了Sun公司以外其他组织、公司也研发过不少虚拟机实现其中规模最大、最著名的就是BEA和IBM公司了。JRockit VM曾经号称“世界上速度最快的Java 虚拟机”(广告词貌似J9 VM也这样说过)它是BEA公司在2002年从Appeal Virtual Machines公司收购的虚拟机。BEA公司将其发展为一款专门为服务器硬件和服务器端应用场景高度优化的虚拟机由于专注于服务器端应用它可以不太关注程序启动速度因此JRockit内部不包含解析器实现全部代码都靠即时编译器编译后执行。除此之外JRockit 的垃圾收集器和MissionControl服务套件等部分的实现在众多Java虚拟机中也一- 直处于领先水平。IBMJ9VM并不是IBM公司唯一的Java虚拟机不过是目前其主力发展的Java虚拟机。IBM J9 VM原本是内部开发代号正式名称是IBM Technology for Java VirtualMachine简称IT4J,只是这个名字太拗口了一点普及程度不如J9。J9 VM最初是由IBMOttawa实验室一个 名为SmallTalk的虚拟机扩展而来的当时这个虚拟机有一一个 bug是由8k值定义错误引起的工程师花了很长时间终于发现并解决了这个错误此后这个版本的虚拟机就称为K8了后来扩展出支持Java的虚拟机就被称为J9了。与BEA JRockit专注于服务器端应用不同IBM J9的市场定位与Sun HotSpot比较接近它是- - 款设计上从服务器端到;桌面应用再到嵌人式都全面考虑的多用途虚拟机J9的开发其的是作为IBM公司各种Javaifi产品的执行平台它的主要市场是和IBM产品_(如IBMWebSphere等):搭配以及在IBMAIX和z/OS这些平台上部署Java应用。1.4.5 Azul:VM /BEA Liquid:VM的我们平时所提及的“高性能Java虚拟机”一般是指HotSpot、JRockit、J9这类在通用平rhe台上运行的商用虚拟机但其实AzulVM和BEALiquidVM这类特定硬件平台专有的虚拟机才是“高性能”的武器。Azul VM是Azul Systems公司在HotSpot基础E进行大量改进运行于Azul Systems公司的专有硬件Vega系统上的Java虚拟机每个AzulVM实例都可以管理至少数十个CPU和数百GB内存的硬件资源并提供在巨大内存范围内实现可控的GC时间的垃圾收集器、为专有硬件优化的线程调度等优秀特性。在2010年Azul Systems公司开始从硬件转向软件发布了自己的Zing JVM可以在通用x86平台上提供接近于Vega系统的特性。Liquid VM即是现在的JRockit VE ( Virtual Edition)它是BEA公司开发的可以直接运行在自家Hypervisor系统上的JRockit VM的虚拟化版本Liquid VM不需要操作系统的支持或者说它自己本身实现了一个专用操作系统的必要功能如文件系统、网络支持等。由虚拟机越过通用操作系统直接控制硬件可以获得很多好处如在线程调度时不需要再进行内核态/用户态的切换等这样可以最大限度地发挥硬件的能力提升Java程序的执行性能。1.4.6 Apache Harmony / Google Android Dalvik VM这节介绍的HarmonyVM和DalvikVM只能称做“虚拟机”而不能称做“Java虚拟机”但是这两款虚拟机(以及所代表的技术体系)对最近几年的Java世界产生了非常大的影响和挑战甚至有些悲观的评论家认为成熟的Java生态系统有崩溃的可能ApacheHarmony是-一个Apache软件基金会旗下以ApacheLicense协议开源的实际兼容于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实现及GoogleAndroidSDK之中尤其是对Android的发展起到了很大的推动作用。说到Android,这个时下最热门的移动数码设备平台在最近几年间的发展过程中所取得的成果已经远远超越了JavaME在过去十多年所获得的成果Android让Java语言真正走进了移动数码设备领域只是走的并非Sun公司原本想象的那- - 条路。Dalvik VM是Android平台的核心组成部分之一它的名字来源于冰岛-一个名为Dalvik的小渔村。Dalvik VM并不是-一个Java虚拟机它没有遵循Java虚拟机规范不能直接执行Java的Class文件使用的是寄存器架构而不是JVM中常见的栈架构。但是它与Java又有着千丝万缕的联系它执行的dex(DalvikExecutable)文件可以通过Class文件转化而来使用Java语法编写应用程序可以直接使用大部分的Java API等。目前Dalvik VM随着Android一起处于迅猛发展阶段在Android 2.2中已提供即时编译器实现在执行性能上有了很大的提高。1.4.7 Microsoft JVM及其他在十几年的Java虚拟机发展过程中除去上面介绍的那些被大规模商业应用过的Java虚拟机外还有许多虚拟机是不为人知的或者曾经“绚丽”过但最终湮灭的。我们以其中微软公司的JVM为例来介绍- -下。也许Java程序员听起来可能会觉得惊讶微软公司曾经是Java技术的铁杆支持者(也必须承认与Sun公司争夺Java的控制权令Java从跨平台技术变为绑定在Windows上的技术是微软公司的主要目的)。在Java语言诞生的初期(1996年~ 1998年以JDK 1.2 发布为分界)它的主要应用之-一是在浏览器中运行Java Applets程序微软公司为了在IE3中支持Java Applets应用而开发了自己的Java虚拟机虽然这款虚拟机只有Windows平台的版本却是当时Windows下性能最好的Java虚拟机它在1997年和1998年连续两年获得了.《PC Magazine》杂志的“编辑选择奖”。但好景不长在1997年10月Sun 公司正式以侵犯商标、不正当竞争等罪名控告微软公司在随后对微软公司的垄断调查之中这款虚拟机也曾作为证据之一被呈送法庭。这场官司的结果是微软公司赔偿2000万美金给Sun公司(最终微软公司因垄断赔偿给Sun公司的总金额高达10亿美元)承诺终止其Java虚拟机的发展并逐步在产品中移除Java虚拟机相关功能。具有讽刺意味的是到最后在WindowsXPSP3中Java虚拟机被完全抹去的时候Sun公司却又到处登报希望微软公司不要这样做。WindowsXP高级产品经理Jim Cullinan称:“我们花费了3年的时间和Sun打官司当时他们试图阻止我们在Windows中支持Java现在我们这样做了可他们又在抱怨这太具有讽刺意味了。”我们试想一下如果当年Sun公司没有起诉微软公司微软公司继续保持着对Java技术的热情那Java的世界会变得怎么样呢? .NET 技术是否会发展起来?但历史是没有假设的。其他在本节中没有介绍到的Java虚拟机还有(当然应该还有很多笔者所不知道的):口 JamVM。口 cacaovm。口 SableVM。口 Kaffe。口 Jelatine JVM。口 NanoVM。口 MRP。口 Moxie JVM.口 Jikes RVM。HotRockit 项目的相关介绍: http://hirt.se/presentations/WhatToExpect.ppt.1.4.8 本章总结与展望回顾 Java 虚拟机从 1996 年 Sun Classic VM 诞生至今的发展历程我们可以清晰地看到一条以性能提升和内存管理精细化为核心的技术演进主线。早期的 Classic VM 仅支持纯解释执行JIT 编译器需要外挂且无法与解释器协同工作导致 Java 语言一度背负“执行效率低下”的标签。随后出现的 Exact VM 引入了准确式内存管理Exact Memory Management和编译器与解释器混合工作模式奠定了现代高性能虚拟机的基础架构雏形。真正将 JVM 带入现代高性能时代的是HotSpot VM其核心创新在于热点代码探测HotSpot Detection与分层编译技术使得虚拟机能够智能地将编译资源集中在最需要优化的代码上从而在即时编译JIT的效率与程序启动速度之间取得最佳平衡。HotSpot 的成功不仅在于其技术先进性更在于其开放策略——随着 Sun 将 JDK 开源形成 OpenJDKHotSpot 成为了事实上的行业标准。与此同时市场上也涌现了各具特色的商用与开源虚拟机形成了多元竞争的格局BEA JRockit与IBM J9分别专注于服务器端场景和全栈多用途市场它们在垃圾回收器、监控工具等方面做出了独特贡献。Azul VM和BEA Liquid VM则代表了面向特定硬件深度优化的方向通过软硬件协同设计追求极致的性能与可扩展性。在移动与嵌入式领域KVM、CDC/CLDC HI等 Sun 的嵌入式虚拟机以及后来颠覆行业的Google Android Dalvik VM及后续的 ART展示了 Java 技术在泛终端设备上的强大生命力。而像Apache Harmony这样的开源项目虽未成为主流但其代码与思想对 Android 及 IBM JDK 7 产生了深远影响并引发了关于 Java 生态开放性与兼容性的深刻讨论。驱动这些演进的核心力量始终是对更高性能的不懈追求、对内存使用效率与垃圾回收能力的持续优化以及适应多样化硬件与场景的扩展能力。从解释执行到 JIT从保守式 GC 到准确式 GC从通用平台到专用硬件每一次重大进步都围绕着如何更高效、更稳定地运行 Java 程序。展望未来Java 虚拟机的发展趋势可能集中在以下几个方向云原生与容器化适配JVM 需要进一步降低内存占用、缩短启动时间并优化在容器环境中的资源感知与调度能力以更好地适应微服务与 Serverless 架构。新硬件与异构计算随着 AI、大数据负载的增长JVM 需要更好地利用 GPU、NPU 等加速器并提供更高效的大内存管理与非堆内存访问模式。语言与运行时创新Project Loom虚拟线程、Project Valhalla值类型和 Project Panama外部函数接口等 OpenJDK 项目正在推动 Java 语言与运行时模型的重大变革未来 JVM 需要深度集成这些特性以释放其全部潜力。生态融合与标准化随着 GraalVM支持多语言、原生编译等新技术出现传统 JVM 与新兴运行时之间的界限可能变得模糊跨生态的工具链与标准或将逐步统一。从 Classic VM 到 HotSpot从 JRockit 到如今的 OpenJDK 主导生态Java 虚拟机的发展史是一部不断突破性能瓶颈、拓展应用边界的技术史诗。尽管曾经百花齐放但经过市场与技术的选择如今已呈现出以 OpenJDK/HotSpot 为核心、多种高性能衍生版本并存的收敛态势。未来JVM 仍将在性能、可观测性、安全性与跨平台能力上持续进化支撑全球数百万应用稳健运行。