《深入理解java虚拟机》第1章 走近Java
1.4 Java虚拟机发展史
上一节我们从整个Java技术的角度观察了Java 技术的发展，许多Java程序员都会潜意识地把它与Sun公司的HotSpot虚拟机等同看待，也许还有一些程序员会注意到BEA.JRockit和IBM J9，但对JVM的认识不仅仅只有这些。从1996年初Sun公司发布的JDK1.0中所包含的SunClassicVM到今天，曾经涌现、湮灭过许多或经典或优秀或有特色的虚拟机实现，在这一- 节中，我们先暂且把代码与技术放下， 一起来回顾- -下Java 虛拟机家族的发展轨迹和历史变迁。
1.4.1 Sun Classic / Exact VM以今天的视角来看，Sun Classic VM的技术可能很原始，这款虚拟机的使命也早已终结。
但仅凭它“世界上第-款商用Java虚拟机”的头衔，就足够有让历史记住它的理由。1996年1月23日，Sun公司发布JDK 1.0，Java 语言首次拥有了商用的正式运行环境，这个JDK中所带的虛拟机就是ClassicVM。这款虚拟机只能使用纯解释器方式来执行Java代码，如果要使用JIT编译器，就必须进行外挂。但是假如外挂了JIT编译器，JIT编译器就完全接管了虚拟机的执行系统，解释器便不再工作了。用户在这款虚拟机上执行java-version命令，将会看到类似下面这行输出:java version "1.2.2"Classic VM (build JDK-1.2.2-001. green threads, sunwjit)其中的“sunwjit"就是Sun提供的外挂编译器，其他类似的外挂编译器还有SymantecJIT和shuJIT等。由于解释器和编译器不能配合工作，这就意味着如果要使用编译器执行，编译器就不得不对每-一个方法、每一行代码都进行编译，而无论它们执行的频率是否具有编译的价值。基于程序响应时间的压力，这些编译器根本不敢应用编译耗时稍高的优化技术，
因此这个阶段的虚拟机即使用了JIT编译器输出本地代码，执行效率也和传统的C/C++程序有很大差距，“Java 语言很慢”的形象就是在这时候开始在用户心中树立起来的。
Sun的虚拟机团队努力去解决ClassicVM所面临的各种问题，提升运行效率。在JDK1.2时，曾在Solaris平台上发布过一-款名为ExactVM的虚拟机，它的执行系统已经具备现.代高性能虚拟机的雏形:如两级即时编译器、编译器与解释器混合工作模式等。ExactVM因它使用准确式内存管理( Exact Memory Management，也可以叫Non-Conservative/AccurateMemory Management)而得名，即虚拟机可以知道内存中某个位置的数据具体是什么类型。譬如内存中有一个32位的整数123456，它到底是-一reference 类型指向123456 的内存地址还是一一个数值为123456的整数，虚拟机将有能力分辨出来，这样才能在GC (垃圾收集)的时候准确判断堆上的数据是否还可能被使用。由于使用了准确式内存管理，ExactVM可以拋弃以前Classic VM基于handler的对象查找方式(原因是进行GC后对象将可能会被移动位置，如果将地址为123456的对象移动到654321，在没有明确信息表明内存中哪些数据是
reference的前提下，虚拟机是不敢把内存中所有为123456的值改成654321的，所以要使用句柄来保持reference值的稳定)，这样每次定位对象都少了一次间接查找的开销，提升执行性能。虽然Exact VM的技术相对Classic VM来说先进了许多，但是在商业应用上只存在了很短暂的时间就被更为优秀的HotSpotVM所取代，甚至还没有来得及发布Windows和Linux平台下的商用版本。而ClassicVM的生命周期则相对长了许多，它在JDK1.2之前是SunJDK中唯- -的虚拟机， 在JDK 1.2时，它与HotSpot VM并存，但默认使用的是Classic VM(用户可用java-hotspot参数切换至HotSpot VM)，而在JDK 1.3 时，HotSpot VM成为默认虚拟机，但Classic VM仍作为虚拟机的“备用选择”发布(使用java-classic参数切换)，直到JDK1.4的时候，ClassicVM才完全退出商用虚拟机的历史舞台，与ExactVM--起进人了Sun Labs Research VM之中。
1.4.2 Sun HotSpot VM
提起HotSpotVM，相信所有Java程序员都知道，它是SunJDK和OpenJDK中所带的虚拟机，也是目前使用范围最广的Java虚拟机。但不一定所有人都知道的是，这个目前看起来“血统纯正”的虚拟机在最初并非由Sun公司开发，而是由一-家名为“Longview
Technologies"的小公司设计的;甚至这个虚拟机最初并非是为Java语言而开发的，它来源于Strongalk VM，而这款虚拟机中相当多的技术又是来源于- - 款支持Self语言实现“达到C语言50%以上的执行效率”的目标而设计的虚拟机，Sun公司注意到了这款虚拟机在JIT编译.上有许多优秀的理念和实际效果，在1997年收购了Longview Technologies 公司，从而获得了HotSpot VM。
HotSpotVM既继承了Sun之前两款商用虚拟机的优点(如前面提到的准确式内存管理)，也有许多自己新的技术优势，如它名称中的HotSpot指的就是它的热点代码探测技术(其实两个VM基本上是同时期的独立产品，HotSpot 还稍早- -些，HotSpot 一开始就是准确式GC，而Exact VM之中也有与HotSpot几乎一样的热点探测。为了Exact VM和HotSpotVM哪个成为Sun主要支持的VM产品，在Sun公司内部还有过争论，HotSpot打败Exact并不能算技术上的胜利)，HotSpot VM的热点代码探测能力可以通过执行计数器找出最具有编译价值的代码，然后通知JIT编译器以方法为单位进行编译。如果--个方法被频繁调用，或方法中有效循环次数很多，将会分别触发标准编译和OSR (栈.上替换)编译动作。通过编译器与解释器恰当地协同工作，可以在最优化的程序响应时间与最佳执行性能中取得平衡，而且无须等待本地代码输出才能执行程序，即时编译的时间压力也相对减小，这样有助于引人更多的代码优化技术，输出质量更高的本地代码。
在2006年的JavaOne大会上，Sun公司宣布最终会把Java开源，并在随后的--年，陆续将JDK的各个部分(其中当然也包括了HotSpot VM)在GPL协议下公开了源码，并在此基础上建立了OpenJDK。这样，HotSpot VM便成为了Sun JDK和OpenJDK两个实现极度接近的JDK项目的共同虚拟机。在2008年和2009年，Oracle 公司分别收购了BEA公司和Sun公司，这样Oracle就同
时拥有了两款优秀的Java虚拟机: JRockit VM和HotSpot VM。Oracle 公司宣布在不久的将来(大约应在发布JDK 8的时候)会完成这两款虚拟机的整合工作，使之优势互补。整合的方式大致上是在HotSpot的基础上，移植JRockit的优秀特性，譬如使用JRockit 的垃圾回收器与MissionControl服务，使用HotSpot的JIT编译器与混合的运行时系统。
1.4.3 Sun Mobile-Embedded VM / Meta-Circular VM
Sun公司所研发的虚拟机可不仅有前面介绍的服务器、桌面领域的商用虚拟机，除此之外，Sun 公司面对移动和嵌人式市场，也发布过虚拟机产品，另外还有一-类虚拟机，在设计之初就没抱有商用的目的，仅仅是用于研究、验证某种技术和观点，又或者是作为一.些规范的标准实现。这些虚拟机对于大部分不从事相关领域开发的Java程序员来说可能比较陌生。Sun公司发布的其他Java虛拟机有:
(1) KVM
KVM中的K是“Kilobyte"的意思，它强调简单、轻量、高度可移植，但是运行速度比较慢。在Android、iOS等智能手机操作系统出现前曾经在手机平台上得到非常广泛的应用。
(2) CDC/CLDC HotSpot Implementation
CDC/CLDC全称是Connected (Limited) Device Configuration，在JSR-139/JSR-218规范中进行定义，它希望在手机、电子书、PDA等设备上建立统一的Java编程接口，而CDC-HI VM和CLDC-HI VM则是它们的一-组参考实现。CDC/CLDC是整个Java ME的重要支柱，但从目前Android和iOS二分天下的移动数字设备市场看来，在这个领域中，Sun 的虛拟机所面临的局面远不如服务器和桌面领域乐观。
(3) Squawk VM
Squawk VM由Sun公司开发，运行于Sun SPOT (Sun Small Programmable Object Technology,- -种手持的WiFi 设备)，也曾经运用于Java Card.这是-一个Java代码比重很高的嵌人式虚拟机实现，其中诸如类加载器、字节码验证器、垃圾收集器、解释器、编译器和线程调度都是 Java语言本身完成的，仅仅靠C语言来编写设备I/O和必要的本地代码。
(4) JavaInJava
JavalnJava是Sun公司于1997年~ 1998 年间研发的一个实验室性质的虚拟机，从名字就可以看出，它试图以Java语言来实现Java语言本身的运行环境，既所谓的“元循环”(Meta-Circular，是指使用语言自身来实现其运行环境)。它必须运行在另外一个宿主虚拟机之上，内部没有JIT编译器，代码只能以解释模式执行。在20世纪末主流Java虚拟机都未能很好解决性能问题的时代，开发这种项目，其执行速度可想而知。
(5) Maxine VM
Maxine VM和上面的JavalnJava非常相似，它也是一个几乎全部以Java代码实现(只有用于启动JVM的加载器使用C语言编写)的元循环Java虚拟机。这个项目于2005年开始，到现在仍然在发展之中，比起JavaInJava，Maxine VM就显得“靠谱”很多，它有先进
的JIT编译器和垃圾收集器(但没有解释器)，可在宿主模式或独立模式下执行，其执行效率.已经接近了HotSpot Client VM的水平。
1.4.4 BEA JRockit I IBM J9 VM
前面介绍了Sun公司的各种虚拟机，除了Sun公司以外，其他组织、公司也研发过不少虚拟机实现，其中规模最大、最著名的就是BEA和IBM公司了。
JRockit VM曾经号称“世界上速度最快的Java 虚拟机”(广告词，貌似J9 VM也这样说过)，它是BEA公司在2002年从Appeal Virtual Machines公司收购的虚拟机。BEA公司将其发展为一款专门为服务器硬件和服务器端应用场景高度优化的虚拟机，由于专注于服务器端应用，它可以不太关注程序启动速度，因此JRockit内部不包含解析器实现，全部代码都靠即时编译器编译后执行。除此之外，JRockit 的垃圾收集器和MissionControl服务套件等部分的实现，在众多Java虚拟机中也一- 直处于领先水平。IBMJ9VM并不是IBM公司唯一的Java虚拟机，不过是目前其主力发展的Java虚拟机。IBM J9 VM原本是内部开发代号，正式名称是"IBM Technology for Java VirtualMachine"，简称IT4J,只是这个名字太拗口了一点，普及程度不如J9。J9 VM最初是由IBMOttawa实验室一个 名为SmallTalk的虚拟机扩展而来的，当时这个虚拟机有一一个 bug是由8k值定义错误引起的，工程师花了很长时间终于发现并解决了这个错误，此后这个版本的虚拟机就称为K8了，后来扩展出支持Java的虚拟机就被称为J9了。与BEA JRockit专注于服务器端应用不同，IBM J9的市场定位与Sun HotSpot比较接近，它是- - 款设计上从服务器端到;桌面应用再到嵌人式都全面考虑的多用途虚拟机，J9的开发其的是作为IBM公司各种Javaifi产品的执行平台，它的主要市场是和IBM产品_(如IBMWebSphere等):搭配以及在IBMAIX和z/OS这些平台上部署Java应用。
1.4.5 Azul:VM /BEA Liquid:VM
的我们平时所提及的“高性能Java虚拟机”一般是指HotSpot、JRockit、J9这类在通用平rhe台上运行的商用虚拟机，但其实AzulVM和BEALiquidVM这类特定硬件平台专有的虚拟机才是“高性能”的武器。Azul VM是Azul Systems公司在HotSpot基础E进行大量改进，运行于Azul Systems公司的专有硬件Vega系统上的Java虚拟机，每个AzulVM实例都可以管理至少数十个CPU和数百GB内存的硬件资源，并提供在巨大内存范围内实现可控的GC时间的垃圾收集器、为专有硬件优化的线程调度等优秀特性。在2010年，Azul Systems公司开始从硬件转向软件，发布了自己的Zing JVM，可以在通用x86平台上提供接近于Vega系统的特性。Liquid VM即是现在的JRockit VE ( Virtual Edition)，它是BEA公司开发的，可以直接运行在自家Hypervisor系统上的JRockit VM的虚拟化版本，Liquid VM不需要操作系统的支持，或者说它自己本身实现了一个专用操作系统的必要功能，如文件系统、网络支持等。由虚拟机越过通用操作系统直接控制硬件可以获得很多好处，如在线程调度时，不需要再进行内核态/用户态的切换等，这样可以最大限度地发挥硬件的能力，提升Java程序的执行性能。
1.4.6 Apache Harmony / Google Android Dalvik VM
这节介绍的HarmonyVM和DalvikVM只能称做“虚拟机”，而不能称做“Java虚拟机”，但是这两款虚拟机(以及所代表的技术体系)对最近几年的Java世界产生了非常大的影响和挑战，甚至有些悲观的评论家认为成熟的Java生态系统有崩溃的可能ApacheHarmony是-一个Apache软件基金会旗下以ApacheLicense协议开源的实际兼容于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实现及GoogleAndroidSDK之中，尤其是对Android的发展起到了很大的推动作用。说到Android,这个时下最热门的移动数码设备平台在最近几年间的发展过程中所取得的成果已经远远超越了JavaME在过去十多年所获得的成果Android让Java语言真正走进了移动数码设备领域，只是走的并非Sun公司原本想象的那- - 条路。Dalvik VM是Android平台的核心组成部分之一，它的名字来源于冰岛-一个名为Dalvik的小渔村。Dalvik VM并不是-一个Java虚拟机，它没有遵循Java虚拟机规范，不能直接执行Java的Class文件，使用的是寄存器架构而不是JVM中常见的栈架构。但是它与Java又有着千丝万缕的联系，它执行的dex(DalvikExecutable)文件可以通过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年，以JDK 1.2 发布为分界)，它的主要应用之-一是在浏览器中运行Java Applets程序，微软公司为了在IE3中支持Java Applets应用而开发了自己的Java虚拟机，虽然这款虚拟机只有Windows平台的版本，却是当时Windows下性能最好的Java虚拟机，它在1997年和1998年连续两年获得了.《PC Magazine》杂志的“编辑选择奖”。但好景不长，在1997年10月，Sun 公司正式以侵犯商标、不正当竞争等罪名控告微软公司，在随后对微软公司的垄断调查之中，这款虚拟机也曾作为证据之一被呈送法庭。这场官司的结果是微软公司赔偿2000万美金给Sun公司(最终微软公司因垄断赔偿给Sun公司的总金额高达10亿美元)，承诺终止其Java虚拟机的发展，并逐步在产品中移除Java虚拟机相关功能。具有讽刺意味的是，到最后在WindowsXPSP3中Java虚拟机被完全抹去的时候，Sun公司却又到处登报希望微软公司不要这样做。WindowsXP高级产品经理Jim Cullinan称:“我们花费了3年的时间和Sun打官司，当时他们试图阻止我们在Windows中支持Java，现在我们这样做了，可他们又在抱怨，这太具有讽刺意味了。”我们试想一下，如果当年Sun公司没有起诉微软公司，微软公司继续保持着对Java，技术的热情，那Java的世界会变得怎么样呢? .NET 技术是否会发展起来?但历史是没有假设的。其他在本节中没有介绍到的Java虚拟机还有(当然，应该还有很多笔者所不知道的):
口 JamVM。
口 cacaovm。
口 SableVM。
口 Kaffe。
口 Jelatine JVM。
口 NanoVM。
口 MRP。
口 Moxie JVM.
口 Jikes RVM。
"HotRockit" 项目的相关介绍: http://hirt.se/presentations/WhatToExpect.ppt.
《深入理解java虚拟机》第1章 走近Java相关推荐
- 深入理解 Java 虚拟机（一）走近 Java
1.1 - 概述 •总述:Java 不仅是一门编程语言,还是一个由一系列 计算机软件 和 规范 形成的技术体系,这个技术体系提供了完整的用于软件开发和跨平台部署的支持环境,并广泛应用于 ◦嵌入式系统. ...
- 【Java虚拟机】第一章、Java虚拟机是如何产生的
先不讲java虚拟机,我们从最最基本的出发. 当我开始学习java之初,老是听我老师吹牛逼说java能跨平台,如何如何厉害,我一直有疑问,java可以跨平台,别的就不行?很惭愧,现在才正式开始总结一下 ...
- 深入理解java虚拟机：JVM高级特性与最佳实践第一部分走近Java第1章走近Java
世界上并没有完美的程序,但我们并不因此而沮丧,因为写程序本来就是一个不断追求完美的过程. 1.1 概述 Java不仅仅是一门编程语言,还是一个由一系列计算机软件和规范形成的技术体系,这个技术体系提供了 ...
- 读-深入理解Java虚拟机（1-2章）随笔
笔者花了一个星期的晚上时间看完了前面三章,由于之前在其他博客看过JVM的东西,所以看起来比较快. 前l两章内容分别是--走近Java:Java内存区域与内存溢出异常.其中部分除黑色内容属于扩展性内容或 ...
- JAVA虚拟机（JVM）划重点 第一章 走近Java
本博客参考<深入理解Java虚拟机>(第二版)一书,提取重点知识,再加以个人的理解编写而成.转载请标明来源. JVM划重点 第一章 走近Java 概述 Java技术体系 展望Java技术的 ...
- 深入理解java虚拟机gc_jvm GC收集器与内存分配（深入理解java虚拟机第三章）
jvm GC收集器与内存分配(深入理解java虚拟机第三章) 本篇是<深入理解java虚拟机第三章>的笔记记录. 一 为什么要关注GC和内存分配? 需要排查各种内存溢出.内存泄漏问题时,或 ...
- [深入理解Java虚拟机]第十一章 程序编译与代码优化-晚期(运行期)优化
概述 在部分的商用虚拟机(Sun HotSpot.IBM J9)中,Java程序最初是通过解释器(Interpreter)进行解释执行的,当虚拟机发现某个方法或代码块的运行特别频繁时,就会把这些代码认 ...
- 《深入理解Java虚拟机》（二）Java虚拟机运行时数据区
Java虚拟机运行时数据区 详解 2.1 概述 本文参考的是周志明的 <深入理解Java虚拟机>第二章 ,为了整理思路,简单记录一下,方便后期查阅. 2.2 运行时数据区域 Java虚拟机 ...
- 深入理解Java虚拟机（一）：Java内存模型
1.Java 虚拟机运行时数据区域 Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域.这些区域都有各自的用途,以及创建和销毁的时间,有的区域随着虚拟机进程的启动而存 ...
最新文章
- 程序员高薪盛宴背后：程序员正在消失？
- ARM64的启动过程之（三）：为打开MMU而进行的CPU初始化
- 《Kubernetes权威指南第2版》学习（二）一个简单的例子
- Linux 服务器注意事项
- 首批共享单车死于2019
- 4999元起！iQOO 9 Pro赛道版上架：迄今为止成本最高手机后盖
- 测试过程线上问题的定位分析问题处理总结
- 南华桌面计算机,南华大学计算机应用基础试题题.doc
- Go语言编程17课：切片，步入数组的窗口（附pdf百度云）
- 前端页面常用代码参考
- 中顶访客登记管理系统
- mac php pear pecl,MacOSX安装pecl - 米扑博客
- 卡方（χ2），四格表应用条件，理论频数
- greendao的使用
- Bootstrap3基础 table-striped 表格实现隔行换色（浅灰色与白色交替）
- 微信内置浏览器导出Excel表格功能
- B站：你阳了和我裁员有什么关系
- Crosswalk 运行报错问题
- Module Error (from ./node_modules/vue-loader/lib/loaders/templateLoader.js):(Emitted value instead o
- 软件测试标准GBT250,国家标准规范GBT 25063-2010.doc