《深入理解 Java 虚拟机 JVM 高级特性与最佳实践(第3版)》_求知之路漫漫_1.4.2 武林盟主: HotSpot VM

【摘要】 本书摘自《深入理解 Java 虚拟机 JVM 高级特性与最佳实践(第3版)》一书中第1章，第4节，周志明著。

1.4.2 武林盟主: HotSpot VM

相信所有 Java 程序员都听说过HotSpot 虚拟机，它是 Sun/OracleJDK 和 OpenJDK中 的默认Java 虚拟机，也是目前使用范围最广的Java 虚拟机。但不一定所有人都知道的是， 这个在今天看起来“血统纯正”的虚拟机在最初并非由Sun 公司所开发，而是由一家名为 “Longview Technologies” 的小公司设计；甚至这个虚拟机最初并非是为Java 语言而研发的， 它来源于 Strongtalk 虚拟机，而这款虚拟机中相当多的技术又是来源于一款为支持 Self 语 言实现“达到C 语言50%以上的执行效率”的目标而设计的 Self 虚拟机，最终甚至可以追

溯到20世纪80年代中期开发的 Berkeley Smalltalk上。Sun 公司注意到这款虚拟机在即时 编译等多个方面有着优秀的理念和实际成果，在1997年收购了Longview Technologies 公 司，从而获得了HotSpot 虚拟机。

HotSpot既继承了Sun 之前两款商用虚拟机的优点(如前面提到的准确式内存管理), 也有许多自己新的技术优势，如它名称中的HotSpot 指的就是它的热点代码探测技术(这里 的描写带有“历史由胜利者书写”的味道，其实HotSpot 与 Exact 虚拟机基本上是同时期的 独立产品， HotSpot 出现得还稍早一些， 一开始 HotSpot 就是基于准确式内存管理的，而 Exact VM之中也有与 HotSpot 几乎一样的热点探测技术，为了 Exact VM 和 HotSpot VM哪 个该成为Sun 主要支持的虚拟机，在Sun 公司内部还争吵过一场，HotSpot 击败 Exact 并不 能算技术上的胜利),HotSpot 虚拟机的热点代码探测能力可以通过执行计数器找出最具有 编译价值的代码，然后通知即时编译器以方法为单位进行编译。如果一个方法被频繁调用， 或方法中有效循环次数很多，将会分别触发标准即时编译和栈上替换编译 (On-Stack Replacement,OSR) 行为0。通过编译器与解释器恰当地协同工作，可以在最优化的程序 响应时间与最佳执行性能中取得平衡，而且无须等待本地代码输出才能执行程序，即时编 译的时间压力也相对减小，这样有助于引入更复杂的代码优化技术，输出质量更高的本地 代码。

2006年， Sun 陆续将 SunJDK的各个部分在 GPLv2 协议下开放了源码，形成了Open- JDK项目，其中当然也包括 HotSpot虚拟机。HotSpot从此成为 Sun/OracleJDK 和 OpenJDK 两个实现极度接近的JDK 项目的共同虚拟机。Oracle 收购Sun 以后，建立了HotRockit 项目来把原来 BEA JRockit中的优秀特性融合到 HotSpot 之中。到了2014年的JDK 8时 期，里面的HotSpot 就已是两者融合的结果， HotSpot 在这个过程里移除掉永久代，吸收了 JRockit 的 Java Mission Control 监控工具等功能。

得益于Sun/OracleJDK 在 Java 应用中的统治地位，HotSpot 理所当然地成为全世界使 用最广泛的Java 虚拟机，是虚拟机家族中毫无争议的“武林盟主”。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们 18664393530@aliyun.com 处理，核实后本网站将在24小时内删除侵权内容。