引言

虚拟机是一种抽象化的计算机，通过在实际的计算机上仿真模拟各种计算机功能来实现的。Java虚拟机有自己完善的硬体架构，如处理器、堆栈、寄存器等，还具有相应的指令系统。Java虚拟机屏蔽了与具体操作系统平台相关的信息，使得Java程序只需生成在Java虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改地运行。

Java虚拟机

Java 技术体系

从广义上讲，Clojure、JRuby、Groovy 等运行于 Java 虚拟机上的语言及其相关的程序都属于 Java 技术体系中的一员。如果仅从传统意义上来看，Sun官方所定义的 Java 技术体系包括以下几个组成部分

Java 程序设计语言。

各种硬件平台上的 Java 虚拟机。

Class 文件格式。

Java API 类库。

来自商业机构和开源社区的第三方 Java 类库。

我们可以将 Java 程序设计语言、Java 虚拟机、Java API 类库这三部分统称为 JDK（Java Development Kit），JDK 是用于支持 Java 程序开发的最小环境。另外，可以把 Java API 类库中的 Java SE API 子集和 Java 虚拟机这两部分统称为 JRE（Java Runtime Environment），JRE 是支持 Java 程序运行的标准环境。

JVM 结构图如下所示

Java Language 体系图如下所示

ava 技术体系可以分为4个平台，分别是

Java Card：支持一些 Java 小程序（Applets）运行在小内存设备（如智能卡）上的平台。

JavaME（Micro Edition）：支持 Java 程序运行在移动终端（手机、PDA）上的平台。

JavaSE（Standard Edition）：支持面向桌面级应用（如 Windows 下的应用程序）的 Java 平台，提供了完整版的 Java 核心 API，这个版本以前也称为 J2SE。

JavaEE（Enterprise Edition）：支持使用多层架构的企业应用（如 ERP、CRM 应用）的 Java 平台，除了提供 JavaSE API 外，还对其做了大量的扩充并提供了相关的部署支持，这个版本以前称为 J2EE。

Java 虚拟机发展史

上一节从整个 Java 技术的角度观察了 Java 技术的发展，许多 Java 程序员都会潜意识地把它与 Sun 公司的 HotSpot 虚拟机等同看待，也许还有一些人会注意到 BEA JRockit 和 IBM J9，但对 JVM 的认识不仅仅只有这些。

从 1996 年初 Sun 公司发布的 JDK 1.0 中所包含的 Sun Classic VM 到今天，曾经涌现、湮灭过许多经典或优秀或有特色的虚拟机实现，在这一节中我们一起来回顾一下 Java 虚拟机家族的发展轨迹和历史变迁。

1.4.1 - Sun Classic / Exact VM

从今天的视角来看，Sun Classic VM 的技术可能很原始，这款虚拟机的使命也早已终结。但仅凭它 世界上第一款商用 Java 虚拟机 的头衔，就足够有让历史记住它的理由。

1996-01-23：Sun 公司发布 JDK 1.0，Java 语言首次拥有了商用的正式运行环境，这个 JDK 中所带的虚拟机就是 Classic VM。这款虚拟机只能使用纯解释器方式来执行 Java 代码，如果要使用 JIT 编译器，就必须进行外挂。但是加入外挂了 JIT 编译器，JIT 编译器就完全接管了虚拟机的执行系统，解释器便不再工作了。用户在这款虚拟机上执行 java -version 命令，将会看到类似下面这行输出

java version "1.2.2"

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

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

Sun 的虚拟机团队努力去解决 Classic VM 所面临的各种问题，提升运行效率。在 JDK 1.2 时，曾在 Solaris 平台上发布过一款名为 Exact VM 的虚拟机，它的执行系统已经具备现代高性能虚拟机的雏形：如 两级即时编译器、编译器与解释器混合工作模式 等。Exact VM 因它使用 准确式内存管理（Exact Memory Management）而得名，即虚拟机可以知道内存中某个位置的数据具体是什么类型。例如内存中有一个 32 位的整数 123456，它到底是 reference 类型指向 123456 的内存地址还是一个数值为 123456 的整数，虚拟机将有能力分辨出来，这样才能在 GC（垃圾收集）的时候准确判断堆上的数据是否还可以被使用。由于使用了准确式内存管理，Exact VM 可以抛弃以前 Classic VM 基于 handler 的对象查找方式（原因是进行 GC 后对象将可能会被移动位置，如果将地址为 123456 的对象移动到 654321，在没有明确信息表明内存中哪些数据是 reference 的前提下，虚拟机是不敢把内存中所有 123456 的值改为 654321 的，所以要使用句柄来保持 refrence 值的稳定），这样每次定位对象都少了一次间接查找的开销，提升执行性能。

虽然 Exact VM 的技术相对 Classic VM 来说先进了许多，但是在商业应用上只存在了很短暂的时间就被更为优秀的 HotSpot VM 所取代，甚至还没有来得及发布 Windows 和 Linux 平台下的商用版本。而 Classic VM 的生命周期则相对长了许多，它在 JDK 1.2 之前是 Sun JDK 中唯一的虚拟机，在 JDK 1.2时，它与 HotSpot VM 并存，但默认使用的是 Classic VM，而在 JDK 1.3 时，HotSopt VM 成为默认虚拟机，但 Classic VM 仍作为虚拟机的 “备用选择” 发布，直到 JDK 1.4 的时候，Classic VM 才完全退出商用虚拟机的历史舞台，与 Exact VM 一起进入了 Sun Labs Research VM 中 。

1.4.2 - Sun HotSpot VM

提起 HotSpot VM，相信所有 Java 程序员都知道，它是 Sun JDK 和 OpenJDK 中所带的虚拟机，也是目前 使用范围最广的 Java 虚拟机。但不一定所有人都知道的是，这个目前看来 ”血统纯正” 的虚拟机在最初并非由 Sun 公司开发，而是一家名为 Longview Technologies 的小公司设计的；设置这个虚拟机最初并非是为 Java 语言而开发的，它来源于 Strongtalk VM，而这款虚拟机中相当多的技术又是来源于一款 Self 语言实现 “可能达到 C 语言 50% 以上的执行效率” 的目标而设计的虚拟机，Sun 公司注意到了这款虚拟机在 JIT 编译上有许多优秀的理念和实际效果，在 1997 年收购了 Longview Technologies 公司，从而获得了 HotSpot VM。

HotSpot VM 继承了 Sun 之前两款商用虚拟机的优点 => 准确式内存管理，也有许多自己新的技术优势，如它名称中的 HotSpot 指的就是它的 热点代码探测技术（其实两个 VM 基本上是同时期的独立产品，HotSpot 还稍早一些，HotSpot 一开始就是准确式 GC，而 Exact VM 中也有与之几乎一样的热点探测。为了 Exact VM 和 HotSpot VM 哪个成为 Sun 主要支持的 VM 产品，在 Sun 公司内部还有过争论，HotSpot 打败 Exact 并不能算技术上的胜利），HotSpot VM 的热点代码探测能力可以通过执行计数器找出最具有编译价值的代码，然后通知 JIT 编译器以方法为单位进行编译。如果一个方法被频繁调用，或方法中有效循环次数很多，将会被分别触发 标准编译 和 OSR（栈上替换） 编译动作。通过编译器与解释器恰当地协同工作，可以在最优化的程序相应时间与最佳执行性能中取得平衡，而且无须等待本地代码输出才能执行程序，即时编译的时间压力也相对减小，这样有助于引入更多的代码优化技术，输出质量更高的本地代码。

在 2006 年的 JavaOne 大会上，Sun 公司宣布最终会把 Java 开源，并在随后的一年，陆续将 JDK 的各个部分（其中当然也包括了 HotSpot VM）在 GPL 协议下公开了源码，并在此基础上建立了 OpenJDK。这样，HotSpot VM 便成为了 Sun JDK 和 OpenJDK 两个实现极度接近的 JDK 项目的共同虚拟机。

1.4.3 - Sun Mobile-Embedded VM / Meta-Circular VM

Sun 公司所研发的虚拟机可不仅有前面介绍的服务器、桌面领域的商用虚拟机，除此之外，Sun 公司面对 移动 和 嵌入式市场，也发布过虚拟机产品，另外还有一类虚拟机，在设计之初就没报有商用目的，仅仅是用于研究、验证某种技术和观点，又或者是作为一些规范的标准实现。这些虚拟机对于大部分不从事相关领域开发的 Java 程序员来说可能比较陌生，Sun 公司发布的其他 Java 虚拟机有

KVM：K 是 Kilobyte 的意思，它强调简单、轻量、高度可移植，但是运行速度比较慢。在 Android、iOS 等智能手机操作系统出现前曾经在手机平台上得到非常广泛的应用。

CDC/CLDC HotSpot Implementation：CDC/CLDC全称是 Connected（Limited）Device Configuration，在 JSR-136、JSR-218 规范中进行定义，它希望在手机、电子书、PDA 等设备上建立统一的 Java 编程接口，而 CDC-HI VM 和 CLDC-HI VM 则是它们的一组参考实现。CDC/CLDC 是整个 JavaME 的重要支柱，但从目前 Android 和 iOS 二分天下的移动数字设备市场看来，在这个领域中，Sun 的虚拟机所面临的局面远不如服务器和桌面领域乐观。

Squawk VM：Squawk VM 由 Sun 公司开发，运行于 Sun SPOT（Sun Small Programmable Object Technology，一种手持的 WiFi 设备），也曾经运用于 Java Card。这是一个 Java 代码比重很高的嵌入式虚拟机实现，其中诸如类加载器、字节码验证器、垃圾回收器、解释器、编译器和线程调度都是 Java 语言本身完成的，仅仅靠 C 语言来编写设备 I/O 和必要的本地代码。

JavaInJava：JavaInJava 是 Sun 公司于 1997-1998 年间研发的一个实验室性质的虚拟机，从名字就可以看出，它试图以 Java 语言来实现 Java 语言本身的运行环境，即所谓的 “元循环”（Meta-Circular，是指使用语言自身来实现其运行环境）。它必须运行在另外一个宿主虚拟机之上，内部没有 JIT 编译器，代码只能以解释模式执行。在 20世纪末主流 Java 虚拟机都未能很好解决性能问题的时代，开发这种项目，其执行速度可想而知。

Maxine VM：Maxine VM 和上面的 JavaInJava 非常相似，它也是一个几乎全部以 Java 代码实现（只有用于启动 JVM 的加载器使用 C 语言编写）的元循环 Java 虚拟机。这个项目于 2005 年开始，到现在仍然在发展之中，比起 JavaInJava，Maxine VM 就显得 “靠谱” 很多，它有先进的 JIT 编译器和垃圾回收器（但没有解释器），可以在宿主模式或独立模式下执行，其执行效率已经接近了 HotSpot Client VM 的水平。

1.4.4 BEA JRockit / IBM J9 VM

前面介绍了 Sun 公司的各种虚拟机，除了 Sun 公司以外，其他组织、公司也研发过不少虚拟机实现，其中规模最大、最著名的就是 BEA 和 IBM 公司了。

JRockit VM 曾经号称 世界上速度最快的 Java 虚拟机（广告词，貌似 J9 VM 也这样说过），它是 BEA 公司在 2002 年从 Appeal Virtual Machines 公司收购的虚拟机。BEA 公司将其发展为一款 专门为服务器硬件和服务器端应用场景高度优化的虚拟机，由于专注于服务器端应用，它可以不太关注程序启动速度，因此 JRockit 内部不包含解析器实现，全部代码都靠即时编译器编译后执行。除此之外，JRockit 的垃圾收集器和 MissionControl 服务套件等部分的实现，在众多 Java 虚拟机中也一直处于领先水平。

IBM J9 VM 并不是 IBM 公司唯一个 Java 虚拟机，不过是目前其主力发展的 Java 虚拟机。IBM J9 VM 原本是内部开发代号，正式名称是 “IBM Technology for Java Virtual Machine”，简称 IT4J，只是这个名字太拗口了一点，普及程度不如 J9。J9 VM 最初是由 IBM Ottawa 实验室一个名为 SmallTalk 的虚拟机扩展而来，当时这个虚拟机有一个 bug 是由 8k 值定义错误引起的，工程师花了很长时间终于发现并解决了这个错误，此后这个版本的虚拟机就称为 K8 了，后来扩展出支持 Java 的虚拟机就被称为 J9 了。与 BEA JRockit 专注于服务器端应用不同，IBM J9 的市场定位与 Sun HotSpot 比较接近，它是一款设计上 从服务器端到桌面应用再到嵌入式都全面考虑的多用途虚拟机，J9 的开发目的是做为 IBM 公司各种 Java 产品的执行平台，它的主要市场是和 IBM 产品（如 IBM WebSphere 等）搭配以及在 IBM AIX 和 z/OS 这些平台上部署 Java 应用。

1.4.5 - Azul VM / BEA Liquid VM

我们平时所提及的 “高性能 Java 虚拟机”，一般是指 HotSpot、JRockit、J9这类在通用平台上运行的商用虚拟机，但其实 Azul VM 和 BEA Liquid VM 这类特定硬件平台专有的虚拟机才是 高性能 的武器。

Azul VM 是 Azul Systems 公司在 HotSpot 基础上进行大量改进，运行于 Azul Systems 公司的专有硬件 Vega 系统上的 Java 虚拟机，每个 Azul VM 实例都可以管理至少数十个 CPU 和数百 GB 内存的硬件资源，并提供

在巨大内存范围内实现可控的 GC 时间的垃圾收集器、为专有硬件优化的线程调度 等优秀特征。在 2010 年，Azul System 公司开始从硬件转向软件，发布了自己的 Zing JVM，可以在通用的 x86 平台上提供接近于 Vega 系统的特性。

Liquid VM 即是现在的 JRockit VM 虚拟化版本，Liquid VM 不需要操作系统的支持，或者说它自己 本身实现了一个专有操作系统的必要功能，如文件系统、网络操作等。由虚拟机越过通用操作系统直接控制硬件 可以获得很多好处，如在线程调度时，不需要再进行内核态 / 用户态的切换等，这样可以最大限度地发挥硬件的功能，提升 Java 程序的执行性能。

1.4.6 - Apache Harmony / Google Android Dalvik VM

这节介绍的两个虚拟机只能称作 “虚拟机”，而不能称做 “Java 虚拟机”，但是这两款虚拟机（以及所代表的技术体系）对最近几年的 Java 世界产生了非常大的影响和挑战，甚至有些悲观的评论家认为成熟的 Java 生态系统有崩溃的可能。

Apache Harmony 是一个 Apache 软件基金会下以 Apache License 协议开源的实际兼容于 JDK 1.5 和 JDK 1.6 的 Java 程序运行平台，这个介绍相当拗口。它包含自己的虚拟机和 Java 库，用户可以在上面运行 Eclipse、Tomcat、Maven 等常见的 Java 程序，但是它没有通过 TCK 认证，所以我们不得不用那么长一串拗口的语言来介绍它，而不能用一句 “Apache 的 JDK” 来说明。如果一个公司要宣布自己的运行平台 “兼容于 Java 语言”，那就必须要通过 TCK（Technology Compatibility Kit）的兼容性测试。Apache 基金会曾经要求 Sun 公司提供 TCK 的使用授权，但是一直遭到拒绝，直到 Oracle 公司收购了 Sun 公司之后，双方关系越闹越僵，最终导致 Apache 愤然退出 JCP（Java Community Process） 组织，这是目前为止 Java 社区最严重的一次 “分裂”。

在 Sun 将 JDK 开源形成 OpenJDK 之后，Apache Harmony 开源的优势被极大地削弱，甚至连 Harmony 项目的最大参与者 IBM 公司也宣布辞去 Harmony 项目管理主席的职位，并参与 OpenJDK 项目的开发。虽然 Harmony 没有经历过真正大规模的商业运作，但是它的许多代码（基本上是 Java 库部分的代码）被吸纳进 IBM 的 JDK7 实现及 Google Android SDK 之中，尤其是对 Android 的发展起到了很大的推动作用。

说到 Android，这个时下最热门的移动数码设备平台在最近几年间的发展过程中所取得的成果已经远远超越了 Java ME 在过去十多年所取得的成果，Android 让 Java 语言真正走进了移动数码设备领域，只是走的并非 Sun 公司原本想象的那一条路。

Dalvik VM 是 Android 平台的核心组成部分之一，它的名字来源于冰岛一个名为 Dalvik 的小渔村。Dalvik VM 并不是一个 Java 虚拟机，它没有遵循 Java 虚拟机规范，不能直接执行 Java 的 Class 文件，使用的是 寄存器架构 而不是 JVM 中常见的 栈架构。但是它与 Java 又有着千丝万缕的联系，它执行的 dex（Dalvik Executable）文件可以通过 Class 文件转化而来，使用 Java 语法编写应用程序，可以直接使用大部分的 Java API 等。目前 Dalvik VM 随着 Android 一起处于一个迅猛发展阶段，在 Android 2.2 中已提供即时编译器实现，在执行性能上有了很大的提高。

1.4.7 - Microsoft JVM 及其他

在十几年的 Java 虚拟机发展过程中，除去上面介绍而那些被大规模商业应用过的 Java 虚拟机外，还有许多虚拟机是不为人知的或者曾经 “绚丽” 过但最终湮灭的。我们以其中微软公司的 JVM 为例来介绍一下。

也许 Java 程序员听起来可能会觉得惊讶，微软公司曾经是 Java 技术的铁杆支持者（也必须承认，与 Sun 公司争夺 Java 控制权，令 Java 从跨平台技术变为绑定在 Windows 上的技术是微软公司的主要目的）。在 Java 语言诞生初期（1996年-1998年，以 JDK1.2 发布为界），它的主要应用之一是在浏览器中运行 Java Applets 程序，微软公司为了在 IE3 中支持 Java Applets 应用而开发了自己的 Java 虚拟机，虽然这款虚拟机只有 Windows 平台的版本，却是当时 Windows 下性能最好的 Java 虚拟机，它在 1997年和1998年连续两年获得了《PC Magazine》杂志的 “编辑选择奖”。但好景不长，在 1997年10月，Sun 公司正式以侵犯商标、不正当竞争等罪名控告微软公司，在随后对微软公司的垄断调查之中，这款虚拟机也曾经作为证据之一被呈送法庭。这场官司的结果是微软公司赔偿 2000 万美金给 Sun 公司（最终微软公司因垄断赔偿给 Sun 公司的总金额高达 10 亿美元），承诺终止其 Java 虚拟机的发展，并逐步在产品中移除 Java 虚拟机相关功能。具有讽刺意味的是，在最后 Windows XP SP3 中 Java 虚拟机被完全抹去的时候，Sun 公司却又到处登报希望微软公司不要这样做。Windows XP 高级产品经理 Jim Cullinan 称：”我们花了 3 年时间和 Sun 打官司，当时他们试图阻止我们在 Windows 中支持 Java，现在我们这样做了，可他们又在抱怨，这太具有讽刺意味了。”

总结

以 上就是我对Java开发大型互联网-深入浅出Java虚拟机问题及其优化总结，分享给大家，希望大家知道什么是Java开发大型互联网-深入浅出Java虚拟机问题及其优化。觉得收获的话可以点个关注收藏转发一波喔，谢谢大佬们支持！

最后，每一位读到这里的网友，感谢你们能耐心地看完。希望在成为一名更优秀的Java程序员的道路上，我们可以一起学习、一起进步！都能赢取白富美，走向架构师的人生巅峰!

想了解学习以上课程内容可加群：722040762 验证码：头条（06 必过）欢迎大家的加入哟！