节：JVM的发展历程

Posted 2022-09-17 李阿昀

这一讲，我们就来看一下JVM的一个发展历程。

JVM的发展历程

既然是讲JVM的发展历程，那么我是肯定要给大家介绍各个不同历史时期版本的Java虚拟机的。我希望我给大家介绍完了之后，在面试的时候一旦别人问你都了解哪些虚拟机，我期望你就不要仅仅是说了解HotSpot了，除了它之外，你还应该能说出其他一些常见的Java虚拟机，虽然它们中有些已经不太使用了。

Sun Classic VM的介绍

首先，我来给大家介绍下第一个Java虚拟机，即Sun公司的Classic VM。

早在1996年Java 1.0版本的时候，Sun公司就发布了一款名为Sun Classic VM的Java虚拟机，它同时也是世界上第一款商用Java虚拟机，只是可惜的是，在JDK 1.4版本发布的时候它就被完全淘汰掉了，现在主流使用的或者默认使用的虚拟机都是HotSpot，不管是OracleJDK还是OpenJDK。而且，现在HotSpot还内置了Sun Classic VM。

接下来，我就要来给大家讲讲这款虚拟机的一个特点了，这是我重点要强调的一点，希望大家好好把握住。

Sun Classic VM这款虚拟机最大的特点便是其内部只提供了解释器，如果大家之前没有关注过Java虚拟机的话，我这么说你可能会一脸懵逼，内心肯定会骂娘，他妈的，什么叫内部只提供了解释器啊？平常心，平常心啊😂！一脸懵逼很正常，下面我解释解释你应该就不会一头雾水了。

首先，大家得知道一点，就是现在主流的虚拟机内部不光会提供解释器，而且还会提供JIT即时编译器，说这个有点干，大家不妨来看一眼下面这幅图，这幅图的话，我之前就带着大家看过了。

看到上图中的执行引擎那部分了没？可以看到执行引擎的构成主要有三部分，即解释器、即时编译器和垃圾回收器，解释器跟即时编译器是现在主流使用的虚拟机都要有的，而Sun Classic VM这款虚拟机就不同了，它内部只提供了解释器。

下面大家不妨再来看一下这幅图。

从上不难看到，各个不同国家的语言编译完了之后就是一堆没有意义的乱码，这是因为字节码文件就不是提供给人类看的，你看也看不懂。接下来，编译生成的字节码文件就要被加载到JVM当中来解释执行了，而此时就会用到执行引擎中的解释器和JIT即时编译器，上面我也说过了，这俩结构现在主流使用的虚拟机都有，只是大家要注意，要想让程序真正地执行，使用其中的一个其实就可以了，并不是说非得在解释器这一环节拿到结果之后再给到JIT即时编译器这一环节去用。

因此，在一开始的虚拟机里面，它就只提供了解释器这个结构，至于JIT即时编译器，则就没有提供了。

那有童鞋看到这里，可能就要问了，只提供解释器会有什么影响呢？

好问题！如果只提供解释器，那么用今天咱们的眼光来看的话，程序执行的效率就会比较低下了，这是因为Java虚拟机在去执行字节码指令的时候，它是得逐行逐行进行解释的，一旦碰到一些重复性的代码，例如一个for循环，如果它循环了2000次，那么其中的循环体就得需要被翻来覆去地逐行解释执行了，这样必然会程序执行的效率低下。

而要想提升效率，那就不得不考虑去使用JIT即时编译器了。关于JIT即时编译器，后面我会给大家进行详细讲解，不过这里我还是会给大家稍微介绍一下JIT即时编译。

首先，大家要知道一点，就是在程序执行过程当中，如果发现有一些代码反复地被执行，那么我们就会将其称为热点代码，也就是说，所谓的热点代码就是那些执行频率比较高的代码。

其次，确定热点代码之后，JIT即时编译器会将其及时地编译成本地机器指令并缓存起来，当下次这些热点代码需要被反复执行时，那就再也不用像解释器一样去逐行地进行翻译解释了。总之，有了JIT即时编译器，就能提升程序的执行效率。

事实已经摆在我们面前了，Sun Classic VM这款虚拟机内部并没有提供JIT即时编译器，但是现在我们又想要用，那该怎么办呢？很简单，使用外挂，就是如果想使用JIT即时编译器，那么就得需要进行外挂。但是一旦使用了JIT即时编译器，那么它便会接管虚拟机的执行系统，这样，解释器就不会再工作了，因为解释器和JIT即时编译器它俩就不能协同工作，而正常它俩是可以协同工作的，只是现在不行。

看到这里，那有童鞋可能就要问了，既然使用了JIT即时编译器之后，解释器就不会再工作了，这样不是挺好的吗？将所有的代码，包括热点代码，都编译成本地机器指令缓存起来，不挺好吗？

如果真这样做了，即选择所有的代码然后编译成本地机器指令缓存起来，而不是只选择热点代码编译成本地机器指令缓存起来，那么问题也就产生了。什么问题呢？大家可以好好想一想。

这里我就不卖关子了，我就直接说了，字节码指令翻译成本地机器指令的时候，这一过程其实是需要花费时间的，如果将每一行字节码指令都翻译成本地机器指令的话，那么这势必就会导致程序启动之后的暂停时间过长，一旦暂停时间过长，程序在一开始启动时就会卡顿一段时间的这一现象就会显现了。而要想让暂停时间不要太长，那我们就不能够使用编译优化效果更好的JIT即时编译器了。

我这样说，不知道大家能不能明白？要不，我再给大家讲一遍吧！就是一旦外挂使用了JIT即时编译器，那么程序启动之后中间暂停的时间就会过长，过后才会开始真正执行程序。要想让暂停时间不要太长，那这个时候我们就要尽可能让编译成本地机器指令的JIT即时编译器的优化技术别太高级了，因为高级了的话，暂停时间就会过长。但是，不太高级的话，效果又不会特别好。

所以，这就导致了一个现象，那就是即使咱们用了JIT即时编译器，最后你会发现Java程序执行效率跟C和C++相比，还是存在一定的差距，而这也就让大家形成了最初的一个印象，即Java语言比较慢，导致今天很多人一提起，就会说Java跟C和C++相比慢多了。

但是时至今日，就不可同日而语了，因为很多顶尖的工程师都参与到了Java的生态体系当中，Java语言走到今天，其执行速度已经不亚于C和C++了，只是在最初的时候确实要差上一些。

我上面说了这么多，也不知道大家听明白了没有，要是大家还不怎么明白的话，那我下面就举一个生活中的例子来向大家进行解释吧！

现在我正在广州的家里，无聊想要外出去广州塔玩玩，于是步行就出发了，此时，大家就可以将解释器理解成是步行，门一开我立马就开始走了，所以对于解释器来讲，它响应的速度非常快，一上来直接就开始执行程序，并不需要像JIT即时编译器那样还得把字节码指令再翻译成本地机器指令。

至于JIT即时编译器，大家则可以理解成是在从家到广州塔的这一段路途中搭乘公交车，搭乘公交车的话，那就得在公交站点上慢慢等待了，可能一等我就等了十分钟，那这是不是意味着程序启动之后暂停时间过长啊！要是采用步行这种方式的话，我都已经走了有一段距离了。但是，一旦公交车来了，我坐上去以后，就有可能超过步行这种方式所行走的距离了，因为公交车的速度是很快的。如果我们坐一趟公交车，还到不了广州塔，那么该怎么办呢？可能这时我们还得转乘其他的公交车。

上面我也说过了，Sun Classic VM这款虚拟机内部并没有提供JIT即时编译器，要是我们想用的话，那就得需要进行外挂了。但是，一旦使用了JIT即时编译器之后，解释器就不会再工作了。而这大家就可以理解成是在从家到广州塔的这一段路途中，都得通过搭乘公交车来到达目的地，如此一来，势必就会导致我们可能就要等很多次的公交车了。而要是采用步行这种方式的话，那大家就可以理解成是全纯用解释器了。

由此我们可以知道，解释器和JIT即时编译器这俩最好还是应该搭配使用。这就有点像我坐会公交车，下来以后发现到中途某一地再坐公交车到目的地的时候不饶远，那我就走几步，走到公交站点之后再座下一趟公交车，下来以后，再走几步，到另外一个公交站点再去座下一趟公交车······，直至到达目的地一样，并不是非得就一定要每次都下来等新的公交车，走两步是不会死人的，有可能你等的时间过长，我都已经走到目的地了。

总之，我们应该把解释器和JIT即时编译器这俩结合起来使用，而这也成为了现在虚拟机的一个主流，即通过它们二者来同时解释、编译咱们编写的程序。

以上说的可能有点啰嗦，甚至可能也有点说得操之过急，因为这得等到我给大家详细讲解执行引擎时，大家才会有深刻的认识，现在讲大家可能都吸收不了，不过这没关系啊，到时候我会给大家来详细展开说明。

Exact VM的介绍

为了解决上一个虚拟机问题，由此在JDK 1.2版本发布时，Sun就提供了此虚拟机，即Exact VM。至于它，我们则可以将其直接翻译成准确式虚拟机。

关于这款虚拟机，大家还应知道一点，即这款虚拟机号称可以Exact Memory Management（翻译过来就是准确式内存管理）。说得更直白一点，就是这款虚拟机可以知道内存中某个位置的数据具体是什么类型，很显然，这是相较于上一个虚拟机（即Sun Classic VM）的不同之处。

举个例子，比如说现在在内存空间中有一个123456这样的数值，那你能区分它到底是一个纯粹的整数呢，还是表示的是一个对象的引用地址？我想，应该是不能的吧！但是对于Exact VM而言，那就不再是什么事了，因为它是可以进行区分的，而这也就意味着上一个虚拟机（即Sun Classic VM）则是不能够进行区分的了。

若不能进行区分，则势必会产生一些麻烦，那么这些麻烦是什么呢？为了给大家讲清楚产生了些什么麻烦，下面我会画一个图，当然，图可能会画得有点简陋，所以还请大家见谅啊！

关于上图所描述的内容，这里我会给大家一个解释。从上图中可以看到，堆中有一个具体对象，栈中有一个地址，但我们不知道该地址是不是堆中具体对象的。如果我们知道的话，那么经历垃圾回收以后，一旦该对象不是一个垃圾了，那它势必就要被重用，重用的话，那它的地址就有可能会发生变化，不过这其中的更多详细内容得等到大家学到垃圾回收相关章节时才会知晓，到时候我就会给大家详细介绍一些垃圾回收相关算法，例如标记整理算法、复制算法等等。

这也就是说，对于那些非垃圾对象而言，它们是要被转移位置的，而一旦要被转移位置，那么我们就得需要来判断栈中的地址（例如上图中的123456）到底是一个对象的引用地址，还是只是一个纯粹的数值了，如果确实是一个对象的引用地址，那么非垃圾对象的地址就要发生变化。很显然，这样的一个区分在Sun Classic VM当中是没法做到的。

继而一个更加有深度的问题就出现了，那就是非垃圾对象如果需要被转移位置，那么该怎么办？其实，这涉及到对象该如何去查找这一主题了，由于我了解的也不是特别多，所以这里我就只好浅浅说一嘴了。

关于如何去查找对象，我只是知道会需要用到一个Handle（翻译过来就是句柄的意思）的对象查找方式，说得更具体一点，就是通过句柄这样一种对象查找方式去额外记录一下地址，但这无形当中又会增加对象查找的一个开销。

上面说了这么多，大家可能都五迷三道了，不过这没关系啊，上面大家仅作一下了解即可，不过大家无论如何都得明确知道一点，就是Exact VM这款虚拟机可以知道内存中某个位置的数据具体是什么类型。

最后，关于Exact VM这款虚拟机我还得说一嘴，就是这款虚拟机已经具备了现代高性能虚拟机的维形，即：

• 热点探测；
• 编译器与解释器混合工作模式。

这也就是说，Exact VM这款虚拟机解决了上一个虚拟机（即Sun Classic VM）出现的弊端。大家应该知道，在Sun Classic VM当中，JIT即时编译器与解释器是不能够混合工作的，而在Exact VM当中，现在就是可以的了。

此外，在Exact VM当中，JIT即时编译器在工作的时候还可以实现热点探测这一功能，即探测出来具体哪些代码是属于高频执行的代码（高频执行的代码也被称为热点代码），然后JIT即时编译器会只针对这些热点代码进行一个即时编译。

只是可惜的是，Exact VM这款虚拟机它只在Sun公司自己的Solaris平台中短暂使用过，其他平台上使用的还是Classic VM。而且，还没等到它在其他平台去普及使用，它就已经被HotSpot虚拟机替换掉了，真是所谓英雄气短啊！

总之，Exact VM这款虚拟机的整个生命周期就比较短，用一句话来形容，就是开始了吗？艹，已经结束了！

HotSpot VM的介绍

在这一小节，我给大家来重点介绍一下Sun公司的HotSpot虚拟机。

如果说大家只知道一款虚拟机的话，那么恐怕就非HotSpot虚拟机莫属了，而且至今我们仍然都在使用它。

有人或许会说，它是Sun公司推出的第三款虚拟机，但这里我要说，这句话说得还不足够准确，这是因为HotSpot虚拟机其实并不算是血统纯正的Sun公司的产品，它最初是由一家名为“Longview Technologies”的小公司设计的，只不过在1997年的时候，这家小公司被Sun公司收购了，所以它最终又归Sun公司所有了。装辗至2009年，Sun公司又被甲骨文公司收购了，所以现在HotSpot虚拟机的东家又变成是甲骨文公司了。

此外，在JDK 1.3版本发布时，HotSpot VM便成为了默认虚拟机，并且直至到现在。

相信大家不难知道，目前HotSpot虚拟机是占有绝对的市场地位的，用武侠小说中的话来说，就是称霸武林。而且，我们可以从下面几点来体现HotSpot虚拟机占有绝对的市场地位。

其一，从JDK不同版本的角度来说，不管是到现在还仍然广泛使用的JDK 6，还是大家目前开发中使用比例最多的JDK 8，乃至于是到目前为止最新版本的JDK，它们默认使用的都是HotSpot虚拟机。

其二，不管是Sun/Oracle JDK也好，还是OpenJDK也好，它们都选择的是HotSpot来作为它们的默认虚拟机。

正是基于以上两点，因此我写的这套JVM系列教程默认介绍的虚拟机都是HotSpot，相关机制也主要是指HotSpot的GC机制，但是我也会兼具到其他常用的一些商用虚拟机，当然，我们还是会以HotSpot为主。

其三，从服务器、桌面到移动端、嵌入式，你会发现这些领域都出现了HotSpot的身影。

这里，我善意提醒大家一下，就是大家在面试的时候，如果面试官提到Java虚拟机的一些具体实施了，那么除非你非常清楚，否则的话你就按照HotSpot虚拟机来说就行，最好不要面试官问到你Java虚拟机的一些相关机制了，你这个时候来一句，请问您问的是HotSpot虚拟机呢，还是其他的虚拟机？如果你要这样问的话，那么面试官可能会紧接着来一句话，那你把各个虚拟机都说一下吧，这就是你纯粹挖坑往下跳了。总之，默认情况下，如果大家都不说的话，那么心照不宣指的都是HotSpot虚拟机。当然，你要确实有本事，都给面试官介绍一下，也OK，因为你厉害嘛，不过你得注意提前准备好说词。

提到商用虚拟机，我相信大家都知道，截至到目前，市面上共有三大主流的商用虚拟机，它们分别是：

1. HotSpot VM
2. JRockit VM
3. J9

这里我之所以要提到其他另外两款虚拟机，是因为我想告诉大家它们都没有方法区这一概念。在之前的讲解中，相信我已经给大家介绍过了JVM的整体结构，如下图所示，可以清楚地看到JVM的整体结构中就有一个方法区，不难知道，方法区这一概念其实就是针对HotSpot虚拟机来讲的，而像JRockit VM和J9则都没有方法区这一概念。

如果大家听说过永久代这一概念的话，当然，要是你没听说过，也没关系啊，直接去网上搜相关内容即可，那么应该是知道关于永久代的介绍的，总归是与下面大差不差。

永久代更规范的名字叫做方法区，而且它还是方法区的一种实现方式，注意，方法区是Java虚拟机规范中定义的，并且只有HotSpot（动态编译）才有永久代。之所以叫它永久代，是因为垃圾回收效果很差，大部分的数据会一直存在直到程序停止运行为止。

如果大家继续往下深究的话，那么你会发现在JDK 8版本发布的时候，HotSpot又引入了一个元空间的概念。此时，大家一定要注意一点，就是方法区和元空间是有区别的，最大的区别是元空间并不在虚拟机中，而是使用的本地内存。这其实就跟JRockit VM一样了，说白了，就是开始慢慢向人家靠拢。

最后，关于HotSpot虚拟机，我还得说一嘴，就是HotSpot它这个名字就体现出了其热点代码探测技术。上面我在介绍Exact VM时，说到过这款虚拟机已经具备了现代高性能虚拟机的维形，但是真正的落地实现则是HotSpot，而且现在它还在不断的优化。

如果大家对名称中的HotSpot指的就是它的热点代码探测技术这句话不甚了解的话，那么下面我会从两个方面来向大家进行详细解释。

首先，大家不妨再来回顾回顾一下下面这幅图。

回顾完之后，我就要从第一个方面来向大家解释上面那句话的意思了。

从上图所描述的内容看，大家不难知道，首先JVM会通过计数器找到最具编译价值的代码（也即所谓的热点代码），找到之后再将字节码指令翻译成本地机器指令，继而缓存到本地，当下次这些热点代码需要被反复执行时，CPU就会直接去执行缓存下来的本地机器指令，那自然而然执行效率就会变得非常高了。

其实，JVM通过计数器找到最具编译价值代码之后，除了即时编译缓存起来之外，还可以触发栈上替换。所谓的栈上替换，其实体现的就是对象不一定都需要创建在堆空间中，在栈中我们也可以去分配对象。而在栈中去分配对象，一些好处也会随之而来，例如垃圾回收管理起来会更方便一些、效率也会更高一些。

接下来，我就要从另外一个方面来向大家解释上面那句话的意思了。

上面我给大家介绍Sun Classic VM时，提到过一个事，就是解释器主要是来负责程序响应时间的，这是因为解释器一上来就会逐行解释字节码；而编译器主要负责解决的是程序执行性能的问题。

所以，通过编译器与解释器二者之间的协同工作，我们便能在最优化的程序响应时间与最佳执行性能中取得一个平衡。

至此，我就稍微给大家介绍了一下HotSpot虚拟机，至于其更详细的内容，后续我会慢慢给大家介绍到，总之，大家不要心急，毕竟心急吃不了热豆腐。此外，大家还要知道一点，就是我写的这套JVM系列教程默认介绍的虚拟机都是HotSpot，因为它非常重要，需要我们重点学习。

JRockit VM的介绍

一说到JRockit，大家就应该要立马条件反射起来，原因就是它是目前市面上三大主流的商用虚拟机之一，而其他另外两个则分别是HotSpot和J9。

大家初次认识JRockit时，可能应该或多或许知道它最开始是BEA公司的一款产品吧！确实是这样啊，只不过在2008年时，该公司被Oracle公司收购了，那自然而然JRockit便最终归属于Oracle公司旗下了。

看到这里，不知道大家心里有没有这样一个疑问，就是既然JRockit与HotSpot都同属于Java虚拟机，那么它俩之间有没有什么区别呢？

这个问题提得非常好啊，它俩之间还就是有区别的，而且一个典型区别就是JRockit是专注于服务器端应用的，而HotSpot则是在服务器端、桌面端、移动端以及嵌入式等领域都有其应用场景。

那服务器端跟客户端、移动端的区别又在哪呢？

对于客户端和移动端来说，用户最在乎的无非就是应用的响应时间了，例如在打开手机里面的一个App应用时，用户希望的是点一下之后该App应用就能立马打开，而不是点完以后还得等五秒钟才打开，总之，用户体验非常重要。

而对于服务器端来讲，它并不太关注程序的启动速度，也就是说响应时间这块是可以被忽略掉的，并不会像HotSpot那样需要在最优化的程序响应时间与最佳执行性能中取得平衡。由于JRockit直接将响应时间这块给忽略掉了，所以JRockit内部自然就不会包含解释器实现了，故全部代码都是靠即时编译器编译后执行。

又加上即时编译器后来又不断地被优化过，所以大量的行业基准测试显示，JRockit虚拟机是世界上最快的JVM。注意，这里我并没有加上所谓的之一，因为事实确实如此，即JRockit虚拟机是世界上最快的JVM，等一会我给大家介绍IBM公司的J9虚拟机时，你会发现它其实也号称是世界上最快的JVM。

虽然JRockit专注于服务器端应用，但是客户在使用了JRockit这个产品之后，已经体验到了显著的性能提高（一些超过了70%）和硬件成本的减少（达50%）。

当然，JRockit也有属于它自己的优势，这个优势便是全面的Java运行时解决方案组合，例如JRockit面向延迟敏感型应用的解决方案JRockit Real Time可以提供以毫秒或微秒级的JVM响应时间，能适合财务、军事指挥、电信网络的需要。这句话初看大家可能有点懵，但所说的意思无非就是如果所开发的应用对响应时间敏感的话，那么JRockit也是有其相配套的解决方案的。

又例如JRockit还拥有一套Mission Control服务套件，它是一组以极低的开销来监控、管理和分析生产环境中的应用程序的工具。由于这套服务套件非常有用，所以Oracle公司在收购BEA公司以后，一直想把这套服务套件加入到HotSpot当中。关于这一点，大家也能从Oracle官网中发现一些端倪，如下图所示，通过https://www.oracle.com/java/technologies/downloads/tools/#JMC超链接打开如下页面后，你便能找到这套服务套件了，其中就包括JDK Mission Control(JMC)。

说得更具体一点，整合到HotSpot当中的这一套Mission Control服务套件其实可以分成三个独立的应用程序，它们分别是：

1. 内存泄露的监测器。上图中的JDK Mission Control(JMC)主要就是用来监控内存泄露的。
2. JVM运行时的分析器。
3. 管理控制台。

总之，Oracle公司在收购BEA公司以后，就有了要将其旗下的两款优秀虚拟机（即HotSpot与JRockit）整合在一起的想法，关于这一点，我之前也早已给大家提到过，大体是在JDK 8的时候，它俩就已经整合在一起了，整合的方式就是在HotSpot的基础上，移植JRockit的优秀特性。但是，它俩的架构又有很大的区别，所以最后能整合的地方其实还是比较有限的。

继而，问题就出现了，既然Oracle公司存在JRockit与HotSpot这两个团队，那么最后整合的时候哪个团队占主导地位呢？与大家预想的不一样，最后应该算是JRockit这个团队占据了一些优势，所以我们才会看到Java之父——詹姆斯·高斯林后来辞职之后便就职于谷歌了，目前他在谷歌主要研究人工智能和水下机器人。

以上就是我对JRockit做的一个整体的介绍，希望大家能从中有所了解。

IBM J9 VM的介绍

说到J9这款虚拟机，相信大家脑海中浮现的第一印象便是它是目前市面上三大主流的商用虚拟机之一，至于其他另外两个，上面我就已经给大家介绍过了。

当然，相信大家都知道，JRockit和HotSpot这两款虚拟机现在已经是归属于Oracle公司旗下的了，由此大家可能会误以为J9这款虚拟机也是同属于Oracle公司旗下，可惜事实并非如此，J9这款虚拟机到目前为止还是属于IBM公司所有，而且，在可预见的未来，也一定还是属于IBM公司，除非IBM公司黄了。

这里我突然想到了一件事，就是应该还有人不知道J9这款虚拟机的全称吧！其实，J9这款虚拟机的全称是IBM Technology for Java Virtual Machine，简称IT4J，内部代号是J9。不难发现，即使是用简称来称呼这款虚拟机也不太合适，因为简称终究还是有点长，所以我们习惯上就用它的内部代号来称呼它了。

此外，大家还有必要知道一点，就是J9这款虚拟机的市场定位与HotSpot比较接近，说得更具体一点，就是在服务器端、桌面应用以及嵌入式等领域都有其应用，从中可以看出它还是一款多用途的虚拟机，而且，它还号称是世界上最快的Java虚拟机。

既然J9这款虚拟机是IBM公司旗下的产品，所以它自然而然便会广泛用于IBM公司旗下的各种Java产品中。

读到这里，相信有童鞋可能会有这样一个疑惑，上面提到的JRockit它号称是世界上最快的Java虚拟机，而这里提到的J9它也号称是世界上最快的Java虚拟机，那么它俩到底谁才是世界上最快的Java虚拟机呢？

我的答案是JRockit是世界上最快的Java虚拟机才是比较靠谱的，因为有舍才有得嘛！大家都知道，JRockit是专注于服务器端应用的，而且它还直接将响应时间这块给忽略掉了，全部代码都靠即时编译器编译后执行，而即时编译器后续又不断地被优化，再加上大量的行业基准测试，所以最终才得出了JRockit是世界上最快的Java虚拟机这一结论。

而对于J9这款虚拟机来讲，它的应用场景就很多了，如果这时再说它是世界上最快的Java虚拟机，那就显得稍微有点牵强了，而且从行业基准测试数据上来看，它也没有JRockit快。你如果非得要从测试数据上说它最快，那也得是基于这样一个前提，即它必须应用于IBM公司旗下的产品中。应该这么讲，J9这款虚拟机在IBM公司旗下的产品中使用效果还是挺不错的。

这里，我还翻阅了一下周志明老师的《深入理解Java虚拟机》这本书，并从中摘录出了如下这句话。

开发J9的目的是作为IBM公司各种Java产品的执行平台，在和IBM产品（如IBM WebSphere等）搭配以及在IBM AIX和z/OS这些平台上部署Java应用。

也就是说，开发J9这款虚拟机的目的是主要专门用于运行IBM公司各种Java产品的，并且它在和IBM产品（如IBM WebSphere等）搭配使用的情况下，于IBM AIX和z/OS这些平台上部署Java应用，性能会非常稳定。但如果你要是在Windows等一些平台下去使用的话，那么Bug可能就会频频出现了，这也难怪有些小伙伴会经常在公司开发中吐槽这款J9虚拟机了。

总之，J9这款虚拟机只有应用于IBM公司各种Java产品中，它的性能才可能是最快的，故从通用性上来讲，它终究还是比不过JRockit的。

其实，这也挺好理解的，在移动互联网刚开始兴起的那几年，尤其是在2014年左右的时候，你会发现媒体经常爱比的一件事就是苹果手机与安卓手机哪一个的性能更好，谁到底才能够称为年度最佳旗舰机？

由于当时这些媒体的撰稿人压根就不懂什么技术，所以他们也就非常简单粗暴的去比较了一下不同手机的硬件参数，最后得出了安卓手机完胜苹果手机的这样一个结论。但是，最终的实际用户体验，苹果手机是要完全好于安卓手机的，不说刚买的苹果手机了，就是用了一两年的苹果手机，其用户体验也是完全好于安卓手机的。原因解释起来也很简单，无非就是苹果公司从它自研的手机的硬件架构（包括CPU架构），