Java 虚拟机的起源与构造  

　　当我们说到“ Java ”这个词的时候，指的是四个相互关联的概念： Java 语言、 Java API 、 Java Class 文件格式、 Java 虚拟机。整个 Java 体系是基于 Java 虚拟机构造的，正因为如此，才能实现 Java 的安全性和网络移动性。 Java 并非是第一个采用“虚拟机”概念的体系，但却是第一个得到广泛运用的虚拟机平台。 “虚拟”，是一种隔离物理资源与逻辑资源的手段。 Java 虚拟机的“虚拟”，则是用来隔离物理机器、底层操作系统与 Java 语言规范实现的手段。  

　　虽然 Java 是一种面向对象的语言，我们平时大量使用的，是对象间的多态、组合 (Composition) 、委派（ Delegation ） , 但当我们讨论虚拟机的时候，我们看见的基本概念却是“栈 (Stack) ”和“堆 (Heap) ”。根据冯诺依曼的“存储计算”模型，所有的代码都保存在代码空间中，随着程序计数器指针的变化进行程序的执行、跳转。 Java 虚拟机中没有寄存器的概念，方法调用是采用“栈”进行的，这是一种安全、简洁的方法。  

　　 Java 虚拟机通过类装载器支持对类的隔离，这也是 Java 实现安全性的基础。每个类都具有自己的命名空间，在具有不同安全级别的沙箱中运行，因此不会产生低安全级别的代码来越权访问高级别代码的机会。类装载器的出现是 Java 虚拟机与大部分用 C 实现的虚拟机的显著不同之处。  

　　 Java 虚拟机的另外一个显著特点就是实现了自动的垃圾收集。在往常，写程序的时候要牢记对象之间的关联，在每个程序块中假若申请了对象空间，就必须在出口释放掉，方法调用往往同时也就是对象的边界。而自动垃圾收集带给开发者的最大好处，就是可以非常方便地从整体上把系统的对象组织成一张对象图，只需往这张图中添加对象，维护对象之间的关联，却不需要自己做复杂的清扫工作。正是有了这种思维单纯的对象图的支持， OR Mapping( 关系数据库与对象映射）技术在最近得以大行其道，设计模式也更容易被 Java 群体所接受。  

　　虚拟机的优化  

　　 1995 年第一代的 Java 出台之时，其虚拟机执行是依靠“字节码解释器（ Byte Code Interceptor ）”的，也就是说每条指令都由虚拟机来当场解释执行，这造成速度令人抓狂地缓慢。更有甚者有人开始总结许多的“速度优化经验”，比如说：“尽量把所有的代码都放在较大的方法中执行”与“少用接口”等等，这完全与 Java 语言的设计目的背道而驰，现在看起来是多么可笑的奇谈怪论，当时却是很多程序员津津乐道的经验之谈。无他， Java 本身执行太慢了。 Java 生命的前十分之三就是如此缓慢地渡过的。  

　　于是， Sun 的工程师开始拼命想着提高执行速度。 JIT 静态编译器的出现是在 1996 年十月， Sun 放出了第一个编译器。 JIT 编译器在每段代码执行前进行编译，编译的结果为本地静态机器码，执行速度有了质的提高。 Symantec 公司当时凭借其傲人的 JIT 编译器，在整个 Java 界受到热烈的追捧。在其后的 1998 年， Java 1.2 发布的时候，附带了 JIT 编译器，从此 Java 的使用者终于可以抛开上面说的那些奇怪的“速度优化经验”了。  

　　 JIT 静态编译器虽然可以解决一些问题，但是性能仍然和 C/C++ 有很大的差距。对一段程序而言，一名优秀的程序员是如何来改进运行速度的呢？首先，他不会傻到把所有的代码都来优化，他会观察、思考到底哪段代码对整体性能影响最大？然后集中精力来优化这一段代码。按照经验，整个程序 10%-20% 的代码，会占据 80%-90% 的运行时间。用这种方法，在同样的时间、付出同样程度的努力后，这名优秀的程序员使整个程序的性能得到了很大程度的优化。 HotSpot 引擎，就是模仿人工的这种方法进行优化的。在程序运行的开始， Java 代码仍然解释执行，但 HotSpot 引擎开始进行采样（ Profiling) 。  

　　根据采样的结果，决定某段程序是占用较多运行时间的，就认为它是“ HotSpot ”，它也就是目前程序的瓶颈， 引擎开始启动一个单独的线程进行优化。因为不象原始的 JIT 编译器那样无差别的编译所有代码， HotSpot 引擎可以集中精力来对 HotSpot 代码进行深度优化，这样这部分代码执行起来更加迅捷。之前的静态编译器只能按照预定的策略进行编译优化，而 HotSpot 引擎的优化是基于采样的结果的，因此这种方法对所有的应用程序都有效。 1999 年 3 月 27 日SPAN style="FONT-FAMILY: 宋体; mso-ascii-font-family: " mso-hansi-font-family:="" roman??="" new="" ?times="" roman?;="" times="">，Sun放出了第一个HotSpot引擎。在随后的2000年5月的JDK 1.3中，包含了HotSopt引擎，这也使1.3成了一个具有里程碑意义的发行版本。到这里，Java的十年生命，已经过去了一半。  

　　 HotSpot 代表的是一种动态编译的技术。对 Java 这种大量使用委派、组合等面向对象特性的程序来说，动态编译比起静态编译来有显著的优势。比如 Method Inlining 。方法的调用是一个很耗时的操作，假若可以把方法调用直接内嵌到调用者的代码中，就可以节省大量的时间， 这被称为“ Method Inlining ”。因为涉及到类的重载，静态优化很难确切知道哪些属性、方法被重载，因此很难对 method 进行合并，只好在方法内部进行静态编译，假若每个方法都很小，静态优化能起到的作用也就比较小。而动态编译因为可以完全随时掌握类的重载情况，就可以把相关的方法合并进行深度优化。现代的 Java 程序，特别是在设计模式教育得到普及之后，大量使用类的继承、委派，形成了很多短小的方法，动态编译的优势就更加明显。  

　　自从出现了 HotSpot 之后，整个 Java 界为之一振。  

　　最近的五年，就是继续优化的五年。继续进行优化的方法有几条路，一是研究新的采样算法。因为采样关系到不同的优化策略，会对整体性能有比较大的影响。二是研究深度优化的方法。三是研究垃圾收集的算法。垃圾收集会带来程序短暂的停顿，这会带来负面的用户体验。于是，如何提高垃圾收集的效率，减少延迟，出现了五花八门的算法，比如渐进式收集、火车算法等。在多处理器的时候，如何利用多处理器进行并行收集也是研究的一个热点。这方面， BEA 的 JRocket 走在了前面。  

　　现实生活中的虚拟机  

　　最后，让我们来盘点一下目前市面上可见的各个虚拟机。  

　　首先要提到的，毫无疑问是 Sun 的虚拟机。作为大众心目中的“官方实现”， Sun 拥有最大的用户群，并且拥有“兼容基准”的地位，其他虚拟机都必须要考虑和 Sun 虚拟机的兼容性问题。比如 JRocket 就会在某些特殊情况下表现出和 Sun 不同的特性，可能对程序运行有影响。不过 Sun 也的确没有让广大用户失望，虽然在早期性能比不上 Symantec, 后来在 1.2 的时候性能又被 IBM 超越，但 Sun 一直在努力革新，特别是 1.4.2/SPAN>之后，性能有了长足的进步。虽然JDK 1.5的虚拟机在性能上没有什么提高，但是增强了稳定性，据说修改了8000处bug，真是让人汗流不止。原来我们在1.4.2下面一直在享受这么多bug啊。

　　其次是老牌劲旅 IBM 。 IBM 的 JDK 在 1.3 的时代创下了最好的性能记录，从此树立了高端形象。特别是在其 WebSphere 产品中得到了很好的评价。其 JDK 也是最早支持 64bit 的 JDK 之一。到了现在， IBM JDK 在高端仍然是和 BEA 可以一拼的。  

　　然后是后起之秀， BEA 的 JRocket 。说到 BEA 突然在 JVM 领域一夜之间异军突起，多少让人有些瞠目，不过它采取的战略特别简单：自己没有，索性花钱买了在此领域深有研究的 JRocket ，在前面加上 BEA 的标志就可以了。 JRocket 瞄准高端服务器市场，在多处理器环境下有不俗的表现。  

　　除此之外，还有几个开放源代码的 JVM 值得一提。首先就是大名鼎鼎的 JikesRVM 。说起其大名，大多数人都知道 Jikes 编译器是 IBM 开发的，效率比同等的 javac 编译器高得多，很多开发者都使用 Jikes 编译器来取代 javac 。而 JikesRVM 则是 IBM 开源出来的一整套虚拟机技术，包含了 JIT ， GC 的完整实现，在其网站上也有众多的论文，实在是想要深入研究 JVM 者的绝佳资源 (http://jikesrvm.sourceforge.net) 。  

　　 Kaffe 是一个老牌的 JVM, 不过现在已经很少听到了。作者撰写此文时， www.kaffe.org 网站已经没有响应，也不知道现在的情况如何了。  

　　 GNU 则有两个计划： GCJ 和 GNU classpath 。 GNU classpath 是一个底层实现，而 GCJ 是支持 java 的预编译器。  

　　结束语  

　　时光流转，轰轰烈烈的 Java 虚拟机性能争论仿佛还在耳边回响，现在新的争论却已经是“ Java 的性能是否已经超越 C/C++ ”。  

　　 Joakim Dahlstedt 是 JRockit 的主要架构设计师之一，他坚持认为， Java 绝不是一种速度慢，效率低的语言， JVM 是一个关键的组件，确保了系统的部署与运行和开发一样快速、轻松。特别是在目前开发趋势是采用大量预制的框架时，动态编译有可能比 C/C++ 这样的静态优化获得更好的性能。

注：转自《程序员》