JAVA 虚拟机深入研究(二)——JVM虚拟机发展以及一些Java的新东西

最新推荐文章于 2024-11-01 15:32:36 发布

banling8851

最新推荐文章于 2024-11-01 15:32:36 发布

阅读量107

点赞数

文章标签：运维 java 移动开发

原文链接：http://www.cnblogs.com/DeanChiong/p/4984666.html

版权

内容目录：

JAVA 虚拟机深入研究(一)——关于Java的一些历史

JAVA 虚拟机深入研究(二)——JVM虚拟机发展以及一些Java的新东西

这是第二篇，我们来说说有关虚拟机的发展。

一说到虚拟机，很多人潜意识就把它跟Sun的HotSpot虚拟机划上等号，也许有些人还会想到BEA 的JRockit或者IBM 的J9，但是事实上JVM并不只有这些。

从最早的Sun在1996年发布的JDK1.0中包含的Sun Classic VM到今天，曾经出现过很多虚拟机，也跪了很多虚拟机。

Sun Classic/ Exact VM

         这款虚拟机属于那种已经跪了的品种，但是虽然它跪了，但是依然要记住，因为它是世界上第一款商用Java虚拟机。

         96年发行JDK1.0的时候这个虚拟机就是标准配置，但是它只能使用纯粹的解释器方式运行，如果想要使用JIT编译器，就必须外挂。如果外挂了JIT，那么JIT就完全接管虚拟机的执行系统，解释器也就不再工作了（其他的外挂编译器还有 Symantec JIT 和 shuJIT等），这意味着，如果要用编译器执行，那么编译器就不得不对所有的方法，每一行代码都进行编译，尽管其中的一部分并没有编译的价值.迫于程序响应时间的压力，没有程序敢于应用那些编译比较耗时的优化技术，因此这个时候得虚拟机即使用了JIT编译器输出了本地代码，执行效率依然和传统的C/C++有很大的差距，“Java很慢”的印象就是这个时候出现的。

        Sun为了解决这个问题，曾经发布了一个名叫Exact VM的虚拟机，它已经初步具备了现代高性能虚拟机的雏形，比如两级即时编译，编译器解释器混合工作的模式。这个编译器采用了准确是内存管理，也就说虚拟机知道内存中某个未知的数据具体是什么类型的，这样在GC（垃圾回收）的时候，虚拟机就可以准确的判断堆上面的数据是否还可以使用。相比于Classic VM的handler 对象查找方式来说，由于使用了准确内存管理，在GC的时候Exact VM不需要去做那一次间接性查找，也就省下了这部分的开销，自然效率高了很多。

        虽然这个Exact VM的性能和先进性都比Classic VM高很多，但是在商业上只存在了很短暂的时间就被更加牛逼的HotSpot VM给取代了，甚至都没有来得及发出Windows和Linux平台的版本，我想它也是醉了。

        相比之下Classic VM生命力却强了很多，JDK1.2之前Sun的JDK中只有这货一个，JDK1.2的时候这货和HotSpot VM共存，它是默认的，JDK1.3 时HotSpot被作为默认的虚拟机，Classic VM依然存在存在，知道JDK1.4的时候Classic VM才真正的完全退出虚拟机的舞台。

Sun HotSpot VM

提到这个虚拟机，很多人都很兴奋，因为它是Sun JDK 和Open JDK中所带的虚拟机，也是目前为止使用最为广泛的虚拟机之一，事实上这个虚拟机不是Sun研发的，而是一个叫做LongView Technologies 的小公司搞出来的，最初的时候甚至都不是为了Java而开发的，它源于Strongtalk VM,这个虚拟机用到的技术来自于一个支持Self语言的以达到C语言50%以上的执行效率为目标的虚拟机设计，Sun看上了人家的JIT编译的很多牛逼的理念和实际效果，于是在97年受够了这家公司，拿到了HotSpot Vm。

HotSpot除了继承了之前的两款虚拟机的优点以外，另外，正如它的名字一样，它的热点探测能力就是它所具有的特性，所谓热点探测就是指，通过执行计数器找出最具有编译价值的代码，然后通知JIT编译器以方法为单位进行编译。如果一个方法调用的非常频繁，或方法中有许多有效循环，将会分别触发标准编译和OSR（栈上替换）编译动作（所谓栈上替换就是指，在方法执行过程中进行编译，针对频繁调用的方法体和有效循环）。

Sun Mobile-Embedded VM /Meta-Circular VM

Sun 公司除了研制了前面的那些服务器和桌面领域的商业虚拟机以外还搞了一些其他领域的或者是作为标准的，甚至根本就是研究或者验证用的，这一部分包括像KVM，CDC/CLDC HotSpot Implementation，Squawk VM，JavaInJava，Maxine VM 等，其中我要说说JavaInJava，它试图以Java语言来实现JAVA运行环境，即所谓的“元循环”（Meta-Circular，指语言用语言自身来实现其运行环境）。

BEA JRockit /IBM J9 VM

前面说的都是Sun的，其他的几个我就一笔带过算了，其中要说说JRoctit，号称最快的虚拟机，貌似J9 也这么说，不过呢，它作为专门为服务器开发的虚拟机因为不在乎启动速度所以它的内部不包含解析器的实现，全部代码都考即时编译器编译后执行，另外在垃圾回收和mission control服务的实现上JRockit也是领先地位的。

Azul VM / BEA Liquid VM

其实上面说的那些所谓商用高性能虚拟机严格的说还不算是高性能，因为真正的高性能是专业定制的，针对硬件环境的，所以这两个才算是严格的高性能虚拟机，具体的就不展开了，有兴趣可以查查。

Apache Harmony /Google Android Dalvik VM

这两个货只能叫他们虚拟机，而不能说是JAVA虚拟机，因为他们都包含了自己的虚拟机和Java库，很多人甚至觉得这是会颠覆传统Java体系的两个家伙。其实吧Apache那个也就是没通过TCK认证而已，原因就是那个由法律部门组成的技术公司，没事靠打官司挣钱的家伙（我会说是Oracle么）搞的鬼呗，当然Sun也有一点原因啦，最后导致Apache 愤怒之下退出JCP（真想骂人…..两个老鼠屎），但是吧金子总还是有人欣赏的，Harmony的很多代码奠定了现在的Android SDK的基础，对安卓的发展起到了巨大的作用，然后我们说到安卓，就说到了Dalvik虚拟机啦，这是安卓的平台的核心组成部分，但是它不是一个Java虚拟机，因为它不遵守Java的规范，不能直接执行class文件，使用寄存器架构而不是栈架构，但是呢还是有很多联系的，比如dex可以有class转化来仍然使用java编写代码，可以使用大部分的Java API。

Microsoft JVM以及其他虚拟机

关于这部分，我只想呵呵，详细的东西自己查一下吧，我列个表直接结束

Jam VM
cacaovm
SableVM
Kaffe
Jelatine JVM
Nano VM
MRP
Moxie JVM\
Jikes RVM

关于Java未来的一些技术发展方向

模块化

还记得咱之前一篇提到的jigsaw么？他就是为了这个所谓的模块化的东东，结果还不是没结果，推迟到JDK9去了…..。

所谓模块化呀，其实就是就是为了解决逐渐复杂庞大的问题而提出的一种解决途径。字面意义…..模块吗…..需要啥就按装啥就完了~~

混合语言

很多语言都有Java实现的版本，Java完不成的事就借用其他语言来搞，反正最后都是class运行于jvm就得了呗。这些运行在虚拟机上，但是又不是Java的语言我们就称为混合语言咯~~

多核并行

这个概念没啥好说的，多核心CPU啥的导致的必然情况，就提下OpenJDK的一个子项目Sumatra，一个为Java提供使用GPU接口的项目类似于C的CUDA，还有就是像是Hadoop的map/Reduce这种并行运算框架啥的了，再就是ERlang这种天生的并行计算能力语言。

64位的虚拟机

Cpu的架构都64位了，Java自然也要跟上时代，但是很不幸的是，没跟上，虽然很早以前就已经推出了64位的版本，但是Java程序在64位系统上要付出额外的不晓得代价，首先是内存，通常64的要比32的多耗费10%-30%的内存，其次，据有关测试表明，64的虚拟机在各项指标的测试中多数都落后于32的，所以还是暂时老实点先用着32把啊~~~ 64的以后会有的~~

转载于:https://www.cnblogs.com/DeanChiong/p/4984666.html