探秘JVM（一）——JVM的前世今生

yxixi

　　缘起Java
　　说起大名鼎鼎的Java语言，可有说不尽的黑历史。它的诞生是Sun公司的Green团队为了让世界上所有的电子设备更加智能，开发一种全新的嵌入式的系统。它的目的是为了解决c++语言复杂庞大的缺点，以及实现跨平台，然而想要在当时统一不同的硬件平台谈何容易（受限于各种厂商的利益关系），于是乎这个项目就耽搁了。
　　在早期因特网大获成功后，业界兴起了开发动态网页的大潮，而刚好oak语言具有轻量、简单的特性，非常适合在互联网中传播，于是Sun开始重拾oak项目，紧接着Sun就推出来了Applet。Applet是一种采用Java编程的内嵌在HTML中的小程序，可以把它类比为当今火热的JavaScript在网页中的作用。在1995年5月23日，Suns在SunWorld大会中正式推出Java和HotJava浏览器，同时提出了那句著名的口号“Write Once，Run Anywhere”。
　　随后Java迎来了井喷式的发展，包括IBM、Apple、Adobe、HP、Oracle、Netscape、微软在内的软件行业巨头纷纷购买了Java的使用许可，开始为自己的产品开发相应的Java平台。主流的操作系统也宣布将嵌入Java技术，大量网页浏览器应用Java技术来制作。也正是这些意料之外的成功，在96年1月，Sun发布了第一个开发工具包JDK1.0,这也标志着Java成为独立的开发工具。
　　Java大事件

• 1995年5月23日，Java语言诞生
  
• 1996年1月，第一个JDK-JDK1.0诞生
  
• 1996年4月，10个最主要的操作系统供应商申明将在其产品中嵌入JAVA技术
  
• 1996年9月，约8.3万个网页应用了JAVA技术来制作
  
• 1997年2月18日，JDK1.1发布
  
• 1997年4月2日，JavaOne会议召开，参与者逾一万人，创当时全球同类会议规模之纪录
  
• 1997年9月，JavaDeveloperConnection社区成员超过十万
  
• 1998年2月，JDK1.1被下载超过2,000,000次
  
• 1998年12月8日，JAVA2企业平台J2EE发布
  
• 1999年6月，SUN公司发布Java的三个版本：标准版（J2SE）、企业版（J2EE）和微型版（J2ME）
  
• 2000年5月8日，JDK1.3发布
  
• 2000年5月29日，JDK1.4发布
  
• 2001年6月5日，NOKIA宣布，到2003年将出售1亿部支持Java的手机
  
• 2001年9月24日，J2EE1.3发布
  
• 2002年2月26日，J2SE1.4发布，自此Java的计算能力有了大幅提升
  
• 2004年9月30日18:00PM，J2SE1.5发布，成为Java语言发展史上的又一里程碑。为了表示该版本的重要性，J2SE1.5更名为Java SE 5.0
  
• 2005年6月，JavaOne大会召开，SUN公司公开Java SE 6。此时，Java的各种版本已经更名，以取消其中的数字“2”：J2EE更名为Java EE，J2SE更名为Java SE，J2ME更名为Java ME
  
• 2006年12月，SUN公司发布JRE6.0
  
• 2009年12月，SUN公司发布Java EE 6
  
• 2010年11月，由于Oracle公司对于Java社区的不友善，因此Apache扬言将退出JCP[14]
  
• 2011年7月28日，Oracle公司发布Java SE 7
  
• 2014年3月18日，Oracle公司发表Java SE 8
  

　　Data From Wikipidea link:https://zh.wikipedia.org/wiki/Java
　　JVM的大乱斗
　　JVM的发展经历了从无到有、百家争鸣、一家独大的三个过程。Java能够成为最受欢迎的语言之一，JVM的不断壮大功不可没。
　　1、Sun Classic VM（从无到有）
　　　　这个算是第一款商用的JVM，从JDK 1.1到1.2时代用的就是这款虚拟机，纯解释器形式，如果想要使用JIT（Just In Time Compiler）编译器必须外挂，并且此时JIT编译器便完全接管了虚拟机的活。但是大家都知道JIT编译器是实时编译字节码（.class里的东西），并且JIT会把翻译过的机器码保存起来，因此如果你的代码复用性和使用率很高，使用JIT会加快代码的执行速度（相对于解释器）。但是如果你的代码中有大量的低频代码，那么编译后真正被执行的代码部分很少，此时JIT的效率就很差了（相对于解释器逐行翻译成执行来说）。Classic VM虚拟机太过极端，只能二选一，因此速度肯定快不到哪里去，比起C/C++更是有很大的差距。这也注定Classic VM很快将被淘汰。
　　这里需要说明一下在JVM中有三类编译器，以后将编译器的时候在详细展开：
　　1）前端编译器：把*.java文件转变为*.class文件，典型的有Javac、ECJ等。
　　2）后端编译器（JIT编译器）：把字节码转化为机器码的编译器，典型的有HotSpot VM中的C1、C2编译器等。
　　3）静态提前（AOT）编译器：把*.java直接转化成本地机器码的编译器，比如GCJ、Excelsior JET。
　　2、Sun Hotspot VM
　　　　Hotspot这个虚拟机对于每一个Java程序员来说都不应该陌生，OpenJDK中使用的便是这种虚拟机，同时它也是目前使用范围最广的虚拟机。但其实Hotspot的前身是Longview公司为Self语言打造的，性能优异，据说有50%C语言的执行效率。原因是其JIT编译有许多优异的理念。正是Sun看中了这个技术收购了Longview公司，同时获得了HotSpot VM的技术。HotSpot正如起名字所示，就是能够探测热点代码，原理是通过执行计数器的方式，然后通知JIT编译器对该代码以方法为单位进行编译。低频代码用解释器执行，高频代码以编译后的机器码执行（并且以方法为最小单位），这种方式结合了解释器和编译器的优点，性能上来说也得到了一定的提升。2006年的时候Sun公司把Java开源，第二年也陆续将JDK的各部分进行了开源，其中就包括HotSpot VM。

　　3、Sun Moblie-Embedded VM/Meta-Circular VM
　　Sun公司不光在桌面应用和服务端有野心，同时也把目光放到了移动和嵌入式领域。
　　1)KVM
　　　　KVM可能大家不是很熟悉，因为前几年它已经被淘汰了。但是说起曾经非智能手机和部分智能手机中的Java应用，其实都是跑在这个虚拟机上的。他也是博主对Java的第一印象，直到上了大学才知道Java如此强大，以前一直以为只是一个手机应用平台（捂脸）。。不过话说回来本身较差的代码执行速度加上低性能的手机，这种技术下的应用的体验自然好不到哪去。加上后来智能手机的崛起，KVM的没落也是情理之中。
　　2）CDC/CLDC HotSpot Implementation
　　　　CDC/CLDC是整个Java ME概念的支柱技术，他希望在手机、电子书、PDA等移动设备上建立统一的Java接口。下场参考KVM。
　　3）Squawk 4）JavaInJava 5）maxine VM 等影响较小就不展开了。
　　4、BEA JRockit/IBM J9
　　　　BEA和IBM应该是为数不多的拥有优秀自主的JVM厂商了。BEA旗下最著名产品的就是JRockit VM了，当时号称最快虚拟机，特点是没有解释器，纯即时编译后执行。原因是这款虚拟机是服务器“特供”，JIT编译有一个缺点就是应用启动特别慢（相对于解释器执行来说编译时间长），但是由于是在服务器的情况下，启动慢并没有多大关系，所以这种完全抛弃解释器的JVM性能也是杠杠的。
　　　　J9的名头同样很大，作为IBM的独立研发的主力JVM，从定位上来说和HotSpot比较接近，应用从服务器到桌面、嵌入式系统都有涉及。被使用的对象也是IBM自家的产品。比如IBM WebSphere等。
　　5、Apache Harmony
　　　　这款虚拟机的命运就比较悲惨了，Harmony VM并不能被称为Java虚拟机，因为虽然它能够让基于jdk 1.5\1.6的应用在其上运行，但是由于没有通过TCK完全认证（只通过Java SE认证，Sun 对于其他厂商出品的Java兼容平台需要通过TCK认证） ，直到Oracle收购Sun后，Apache愤然退出JCP组织。
　　　　这其中一个十分关键的原因是Harmony VM率先将JVM进行了模块化设计，从设计思路上来说是这种模式十分先进的。但是对于Sun来说，这必将导致Java社区的分裂，出此下策也是无奈之举。如今Oracle也将在最新的Java中运用模块化的设计，真是让人对当年的Harmony感到可惜。
　　6、Google Android Dalvik VM
　　　　Android Dalvik VM的知名度应该完全不亚于HotSpot VM，虽然Android是使用Java编写的，但是 Dalvik VM和普通版JVM大不相同。。Dalvik 并没有遵循JVM标准，他最终生成的可执行文件也不是jar文件，而是dex文件。实际上Dalvik对前端编译器生成的class文件重新做了一次重构，大大提高了Android程序的运行速度。其次JVM是基于栈的架构，而Dalvik VM是基于寄存器的架构。基于栈的机器必须使用指令来载入栈上的数据，相对于基于寄存器架构来说，指令数量会多很多。然而，在寄存器的指令必须编码源和目的地寄存器，因此往往指令更大。
　　　　其中分发指令这个环节对性能的影响最大。在基于寄存器的Dalvik VM中，可以更有效的减少冗余指令的分发，减少内存的读写访问。 从JVM和Dalvik VM的区别上来说，Dalvik VM主要是针对Android这个嵌入式操作系统的特点进行了各种优化，使其更省电、更省内存、运行效率更高，但是牺牲了一些JVM的与平台无关的特性。实际上，Dalvik VM本就是为Android设计的，无需考虑其它平台的问题。
　　总结：
　　　　JVM的科技树有开了许多分叉，不同类型的JVM针对不同的硬件、操作系统环境都会有不同的特点。而java字节码的执行、编译方式的组合与优化是它们间差异化的根本原因。接下来马上进入到JVM的编译世界。