JVM的前世今生及未来盘点

最新推荐文章于 2024-04-16 10:06:34 发布

愿好

最新推荐文章于 2024-04-16 10:06:34 发布

阅读量425

点赞数

分类专栏： Arthur解析系列之JVM 文章标签： jvm

本文链接：https://blog.csdn.net/m0_37840000/article/details/125816140

版权

Arthur解析系列之JVM 专栏收录该内容

13 篇文章 0 订阅

订阅专栏

始祖：Sun Classic/Exact VM

Sun Classic是java世界的第一款商用虚拟机，以今天的视角看来，Sun Classic虚拟机的技术已经相当原始，这款虚拟机最初的使命也早已终结。这款虚拟机只能使用纯解释器的方式来执行，这也意味着如果你需要在开发时使用及时编译的功能，你就必须外挂即时编译器，其中的Sun Workshop JIT就是Sun公司提供的一款即时编译器，其他类似的外挂编译器还有Symantec JIT和shuJIT。这里有一点值得注意的地方，就是当我们使用外挂的编译器时，由于解释器和编译器不能配合工作，这就意味着如果要使用编译执行，编译器就不得不对每一个方法、每一行代码都进行编译，而无论他们执行的频率是否具有编译的价值。

Exact VM的命名由来是因为它使用了准确式内存管理（Exact Memory Management），准确式内存管理是指虚拟机可以知道内存中某个位置的数据具体是什么类型。譬如内存中有一个32bit的整数123456，虚拟机将有能力分辨出它到底是一个指向了123456的内存地址的引用类型还是一个数值为123456的整数，准确分辨出哪些内存是引用类型，这也是在垃圾收集时准确判断堆上的数据是否还可能被使用的前提。虽然Exact VM的技术相对Classic VM来说先进了很多，但是它的命运显得十分英雄气短，在商业应用上只存在了很短的时间就被外部引进的HotSpot VM所取代，而Classic VM的生命周期则相对要长不少，它在JDK1.2之前是JDK中唯一的虚拟机，在JDK1.2时，它与HotSpot VM并存，但默认使用的是Classic VM（用户可用java -hotspot参数切换至HotSpot VM），而在JDK1.3时，HotSpot VM成为默认的虚拟机，它仍然作为虚拟机的“备用选择”发布（使用java -classic参数切换），知道JDK1.4的时候，Classic VM才完全退出商用虚拟机的历史舞台，与Exact VM一起进入了 Sun Labs Research VM中。

武林盟主：Hotspot VM

Sun/OracleJDK和OpenJDK中的默认java虚拟机，也是目前使用最广泛的虚拟机，HotSpot既继承了Sun之前两款虚拟机的优点，也有很多自己的技术优势，比如它名称中的HotSpot就是指它的热点探测技术。HotSpot虚拟机的热点探测能力可以通过执行计数器找出最具有编译价值的代码，然后通知即时编译器以方法为单位进行编译。如果一个方法被频繁调用，或者方法中的有效循环次数很多，将会分别触发标准即时编译和栈上替换编译（On-Stack-Replacement，OSR）行为。通过编译器和解释器恰当地协同工作，可以在最优化的程序响应时间和最佳执行性能中取得平衡，而无需等待本地代码输出才能执行程序即时编译的时间压力也相对较小。这样有助于引入更复杂的代码优化技术，输出更高的本地代码。

2006年，Sun陆续将SunJDK的各个部分在GPLv2协议下开放了源码，形成了Open-JDK项目，其中当然也包括HotSpot虚拟机。HotSpot从此成为Sun/OracleJDK和OpenJDK两个两个实现极度相近的JDK项目的共同虚拟机。Oracle收购Sun以后，建立了HotRockit项目来把原来BeanJRockit中的优秀特性融合到HotSpot之中。到了2014年的JDK8时期，里面的HotSpot就已是两者融合的结果，HotSpot在这个过程中移除掉永久代，吸收了JRockit的Java Mission Control监控工具等功能。
得益于Sun/Oracle JDK在java应用中的统治地位，HotSpot利索当然成为了全世界使用最广泛的Java虚拟机，是虚拟机家族中毫无争议的“武林盟主”。

新生代：GraalVM

Hotspot中在JDK10前有两类虚拟机，客户端编译器(C1)：编译耗时短，优化程度低，服务端编译器(C2)：编译耗时长，优化程度高。JDK10后加入了一个全新的即时编译器：Graal编译器，主要是为了替代C2，借鉴了其优点，在保持输出相近质量的编译代码的同时，开发效率和拓展性上都要显著优于C2编译器

GraalVM的改进Substrate VM(AOT提前编译框架):

对于长时间运行的，或者小型化的应用而言，java天生就带有劣势，表现在对于微服务架构推行下，java启动时间长，需要预热才能达到最高性能。为了解决这个问题，就逐步开始对提前编译提供支持，即虚拟机在编译成二进制码后能直接调用。substrateVM是GraalVM0.20版本里新出现的一个极小型的运行时环境，包括了独立的异常处理、同步调度、线程管理、内存管理(垃圾收集)和JNI访问等组件，目标是替代Hotspot用来支持提前编译后的程序执行。同时还包含一个本地镜像的构造器（Native Image Generator），用来给用户程序建立基于Substrate VM的本地运行时镜像。该构造器采用指针分析技术，从用户提供的程序入口，搜索所有可达的代码。其轻量特性，使其十分适合嵌入其它系统，也让Graal VM支持其它语言不会有重量级的运行负担。Substrate VM带来的好处是能显著降低了内存占用及启动时间,由于HotSpot本身就会有一定的内存消耗(通常约几十MB),这对最低也从几GB内存起步的大型单体应用来说并不算什么,但在微服务下就是一笔不可忽视的成本。根据Oracle官方给出的测试数据,运行在Substrate VM上的小规模应用,其内存占用和启动时间与运行在HotSpot相比有了5倍到50倍的下降。Substrate VM使得GraalVM支持其它语言时不会有重量级的运行负担。