《深入理解 Java 虚拟机 JVM 高级特性与最佳实践(第3版)》_求知之路漫漫_1.4 Java 虚拟机家族

【摘要】 本书摘自《深入理解 Java 虚拟机 JVM 高级特性与最佳实践(第3版)》一书中第1章，第4节，周志明著。

1.4 Java 虚拟机家族

上一节我们以JDK 版本演进过程为线索，回顾了Java 技术的发展历史，体会过其中企 业与技术的成败兴衰，现在，我们将聚焦到本书的主题 “Java 虚拟机”。许多Java 程序员 都会潜意识地把Java 虚拟机与 OracleJDK 的 HotSpot 虚拟机等同看待，也许还有一些程序 员会注意到 BEA JRockit 和 IBMJ9 虚拟机，但绝大多数人对Java 虚拟机的认识就仅限于此 了。从1996年初Sun 发布的JDK 1.0中包含的 Sun Classic 虚拟机到今天，曾经涌现、湮灭 过许多或经典，或优秀，或有特色，或有争议的虚拟机实现，在这一节中，我们仍先把代 码与技术放下， 一起来回顾Java 虚拟机家族的发展轨迹和历史变迁。

1.4.1 虚拟机始祖： Sun Classic/Exact VM

以今天的视角来看，Sun Classic 虚拟机的技术已经相当原始，这款虚拟机的使命也早已 终结。但仅凭它“世界上第一款商用Java 虚拟机”的头衔，就足够有令历史记住它的理由。

1996年1月23日，Sun 发布JDK1.0,Java 语言首次拥有了商用的正式运行环境，这 个JDK 中所带的虚拟机就是 Classic VM。这款虚拟机只能使用纯解释器方式来执行 Java 代 码，如果要使用即时编译器那就必须进行外挂，但是假如外挂了即时编译器的话，即时编 译器就会完全接管虚拟机的执行系统，解释器便不能再工作了。在JDK 1.2及之前，用户 用Classic 虚拟机执行java -version 命令，将会看到类似下面这行的输出：

java version "1.2.2"

Classic VM(build JDK-1.2.2-001,green threads,sunwjit)

其中的 “sunwjit”(Sun Workshop JIT) 就是 Sun 提供的外挂编译器，其他类似的外挂 编译器还有 Symantec JIT 和 shuJIT 等。由于解释器和编译器不能配合工作，这就意味着如果要使用编译执行，编译器就不得不对每一个方法、每一行代码都进行编译，而无论它们 执行的频率是否具有编译的价值。基于程序响应时间的压力，这些编译器根本不敢应用编 译耗时稍高的优化技术，因此这个阶段的虚拟机虽然用了即时编译器输出本地代码，其执 行效率也和传统的C/C++ 程序有很大差距，“Java 语言很慢”的印象就是在这阶段开始在 用户心中树立起来的。

Sun的虚拟机团队努力去解决Classic 虚拟机所面临的各种问题，提升运行效率，在 JDK 1.2 时，曾在 Solaris 平台上发布过一款名为 Exact VM的虚拟机，它的编译执行系统已 经具备现代高性能虚拟机雏形，如热点探测、两级即时编译器、编译器与解释器混合工作 模式等。

Exact VM因它使用准确式内存管理 (Exact Memory Management, 也可以叫 Non-Con- servative/Accurate Memory Management) 而得名。准确式内存管理是指虚拟机可以知道内 存中某个位置的数据具体是什么类型。譬如内存中有一个32bit 的整数123456,虚拟机将 有能力分辨出它到底是一个指向了123456的内存地址的引用类型还是一个数值为123456 的整数，准确分辨出哪些内存是引用类型，这也是在垃圾收集时准确判断堆上的数据是否 还可能被使用的前提。由于使用了准确式内存管理，Exact VM可以抛弃掉以前 Classic VM 基于句柄 (Handle) 的对象查找方式(原因是垃圾收集后对象将可能会被移动位置，如果地 址为123456的对象移动到654321,在没有明确信息表明内存中哪些数据是引用类型的前 提下，那虚拟机肯定是不敢把内存中所有为123456的值改成654321的，所以要使用句柄 来保持引用值的稳定),这样每次定位对象都少了一次间接查找的开销，显著提升执行性能。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们 18664393530@aliyun.com 处理，核实后本网站将在24小时内删除侵权内容。