Java-JVM-分类
转载声明：
本文系转载自以下文章：
- RednaxelaFX对主流Java虚拟机讲解
作者：RednaxelaFX
来源：知乎
转载仅为方便学习查看，一切权利属于原作者，本人只是做了整理和排版，如果带来不便请联系我删除。
摘要
Wikipedia那个Comparison of Java virtual machines页面给JVM实现分得还挺细。利益相关：Azul System的员工，参与Zing VM的研发；之前在Oracle参与HotSpot VM的研发。
要说主流JVM是什么，首先得区分清楚场景。光谈部署量的话，搞不好现在部署量最多的JVM是Dalvik / ART…虽然Google会告诉大家Dalvik和ART不是“JVM”，但大家都知道骨子里它就是不折不扣的JVM，毫无疑问。它们的设计处处有标注对JVM规范的参考，以保证语义符合JVM规范的要求；那个基于寄存器的字节码设计只是一种实现优化而已。
0x01 J2SE与JVM
Java EE是以Java SE为基础的。所以并没有“JVM for Java EE”这么一说，只有“JVM for Java SE”，可以用于Java SE与Java EE。
在这个类别下，主流选择有：（按流行程度递减）
- HotSpot VM
- J9 VM
- Zing VM
0x02 HotSpot VM
2.1 流行度
HotSpot VM是绝对的主流。大家用它的时候很可能就没想过还有别的选择，或者是为了迁就依赖了Oracle/Sun JDK某些具体实现的烂代码而选择用HotSpot VM省点心。
Oracle / Sun JDK、OpenJDK的各种变种（例如IcedTea、Zulu），用的都是相同核心的HotSpot VM。
从Java SE 7开始，HotSpot VM就是Java规范的“参考实现”（RI，Reference Implementation）。也就是说，把HotSpot称为做“标准JVM”完全不为过。可参考：
Java Platform, Standard Edition 7 Reference Implementations
Java Platform, Standard Edition 8 Reference Implementations
当大家说起“Java性能如何如何”、“Java有多少种GC”、“JVM如何调优”云云，经常默认说的就是特指HotSpot VM。可见其“主流性”。（其实这不是件好事；具体到JVM实现才可以讨论的问题还是应该指明讨论是基于哪个实现）
2.2 简介
JDK8的HotSpot VM已经是以前的HotSpot VM 与JRockit VM的合并版，也就是传说中的HotRockit，只是产品里名字还是叫HotSpot VM。
- HotSpot最初并非Sun公司开发的，而是由一家名为“LongviewTechnologies”的小公司设计的，甚至这款虚拟机一开始也不是为Java语言开发的，Sun公司注意到了这款虚拟机在JIT编译技术(Just In Time，即时编译技术)上有许多优秀的理念，在1997年收购了这家公司，获得了HotSpot VM。
HotSpot VM的最大特点，正如其名，就是热点代码探测能力。具体来说HotSpot VM的热点代码探测能力可以通过执行计数器找出最具有编译价值的代码，然后通知JIT编译器以方法为单位进行编译。如果一个方法被频繁调用，或方法中有效循环次数很多，将会分别触发标准编译和OSR（栈上替换）编译动作。通过编译器与解释器恰当地协同工作，可以在最优化的程序响应时间与最佳执行性能中取得平衡，而且无须等待本地代码输出才能执行程序，即时编译的时间压力也相对减小，这样有助于引入更多的代码优化技术，输出质量更高的本地代码。 - JRockit VM曾经号称“世界上速度最快的Java虚拟机”（广告词，貌似J9 VM也这样说过），它是BEA公司在2002年从Appeal Virtual Machines公司收购的虚拟机。BEA公司将其发展为一款专门为服务器硬件和服务器端应用场景高度优化的虚拟机，由于专注于服务器端应用，它可以不太关注程序启动速度，因此JRockit内部不包含解析器实现，全部代码都靠即时编译器编译后执行。除此之外，JRockit的垃圾收集器和MissionControl服务套件等部分的实现，在众多Java虚拟机中也一直处于领先水平。
这个合并并不是简单地把JRockit的部分代码插进HotSpot里，而是把前者一些有价值的功能在后者里重新实现一遍。如移除PermGen、Java Flight Recorder、jcmd等都属于合并项目的一部分。
不过要留意的是，这里我说的HotSpot VM特指正常配置版，而不包括Zero / Shark版。Wikipedia那个页面上把后者称为Zero Port。用这个版本的人应该相当少，很多时候它的release版都build不成功…
0x03 J9 VM
J9 VM是IBM开发的一个高度模块化的JVM。
3.1 简介
在许多平台上，IBM J9 VM都只能跟IBM产品一起使用。这不是技术限制，而是许可证限制。例如说在Windows上IBM JDK不是免费公开的，而是要跟IBM其它产品一起捆绑发布的；使用IBM Rational、IBM WebSphere的话都有机会用到J9 VM（也可以自己选择配置使用别的Java SE JVM）。
根据许可证，这种捆绑在产品里的J9 VM不应该用于运行别的Java程序…大家有没有自己“偷偷的”拿来跑别的程序IBM也没力气管（咳咳而在一些IBM的硬件平台上，很少客户是只买硬件不买配套软件的，IBM给一整套解决方案，里面可能就包括了IBM JDK。这样自然而然就用上了J9 VM。
所以J9 VM得算在主流里，虽然很少是大家主动选择的首选。
3.2 性能
J9 VM的性能水平大致跟HotSpot VM是一个档次的。有时HotSpot快些，有时J9快些。不过J9 VM有一些HotSpot VM在JDK8还不支持的功能，最显著的一个就是J9支持AOT编译和更强大的class data sharing。
0x04 Zing VM
4.1 简介
Zing VM是一个由Azul Systems公司从Sun HoSpot VM fork出来的一个高性能JVM，可以运行在Linux/x86-64平台上。
Azul 公司为它重新写了一套GC，也修改了VM内的许多实现细节，所以从我们自己的角度看，与其说它是HotSpot VM的一个变种，还不如把它看作“一个全新的JVM、只是凑巧与HotSpot VM很像”更合适。
4.2 性能
在要求低延迟、快速预热等的场景里，Zing VM都会比HotSpot VM表现更好：
- 支持内存大，GC STW时间短
Zing的C4 GC目前可以支持1TB的-Xmx，而且GC暂停时间仍然可以维持在< 10ms的范围里。实际上Zing现在能支持接近2TB的-Xmx，但我们还没能用来测试2TB场景的机器…据说再过一段时间这个测试服务器就要到货了。 - 快速预热
Zing的ReadyNow!功能可以利用之前收集到的profile数据，引导JVM在启动后快速达到稳定的高性能水平，减少启动后从解释执行到JIT编译的等待时间。 - 更全面的JVM监控
-Zing自带的ZVision / ZVRobot功能可以方便用户监控JVM的运行状态，从找出代码热点到对象分配监控、锁竞争监控等都可以做到。 - 性能更优
最关键的是，Zing能让普通没有为GC之类的底层方向调优的Java应用享有低延迟、快速预热、易于监控的功能，为用户节省苦苦调优的精力和时间。这是Zing的主要价值——很多Java应用都可以通过长期努力在应用/框架层面优化来提升性能，但使用Zing的话就可以更多把精力集中在业务方面。
0x05 Java SE Embedded(嵌入式定制版)
这是Oracle造出来的比较新的概念。硬件发展得很快，现在很多所谓“嵌入式”场景用的机器其实跟普通台式机的配置没差多少，完全足以运行Java SE，侵蚀了以前高端Java ME（例如Java ME CDC Profile）的地盘。
Oracle Java SE Embedded里带的JVM自然还是HotSpot VM，不过是Java SE Embedded定制版：简化了JVM内的某些部件，尽可能在支持完整的Java SE功能的前提下向着减少内存消耗的方向优化；只留下了Client Compiler（C1）而去掉了Server Compiler（C2）；GC以前好像是只留下了Serial GC但后来有没有支持更多GC种类我不太清楚。
IBM在这个领域照样可以用J9 VM应对。其它还算主流Java SE Embedded JVM的话，可能JamVM可以算进来吧。它是一个小巧的、能支持完全OpenJDK类库和Java SE规范的JVM。
0x06 Java ME
主流有俩：
- CLDC-HI
- J9 VM
6.1 CLDC-HI
CLDC-HIOracle/Sun系的话，现在主流的Java ME JVM只有CLDC HotSpot Implementation（CLDC-HI，或者叫Monty VM）了。很明显这是用于支撑Java ME CLDC Profile的JVM。
以前还有CDC HotSpot Implementation（CDC-HI，或者叫CVM），但Oracle调整了Java ME战略之后这个VM也炮灰了。目前可能只有在Oracle ADF Mobile在iOS上的版本里还活着吧。（没错，iOS上可以跑Java程序的！）
战略调整后的Java ME CLDC都快能赶上以前的Java ME CDC了。夹在Java ME CLDC与Java SE Embedded之间的Java ME CDC自然得炮灰。Sun以前在Java ME CLDC还有一个KVM，本来应该早就被CLDC-HI替代，但现在可能还有些小厂商在基于KVM定制自己的Java ME方案，毕竟更加简单而且资源消耗更少。
6.2 J9 VM
IBM在Java ME领域对应的仍然是J9 VM。高度模块化不是吹的。
0x07 Android / Android兼容系统
如同开头说的，Android上的Dalvik / ART虽然名字不叫JVM，但骨子里就是不折不扣的JVM。这俩VM都能支持几乎完整的Java SE功能。跟一般Java SE相比，可能也就ClassLoader、动态生成字节码之类的方案比较坑爹。
Dalvik VM自身也有不少变种就是了。例如说Intel版的Dalvik x86版重写了许多组件，JIT性能比原版Dalvik VM好。
此外，阿里云OS的LemurVM是一个可以兼容Android的Java应用的JVM。
0x08 JavaCard
Oracle/Sun有JCVM。其它支持JavaCard的JVM我还真没怎么留意。会用到这种解决方案的都是政府或者企业用户吧…不是我能接触到的领域。
0x09 Sun SPOT
Sun SPOT上有个Squawk VM，是一个非常小巧、专门为小型嵌入式环境设计的JVM。
0x10 研究性质的JVM
去找比较新的、跟JVM相关的学术界的研究论文，基本上就下面几个JVM可选：
- Jikes RVM
- Maxine VM
- Graal VM
这仨就算是现在的主流研究性JVM吧。
10.1 Jikes RVM
Jikes RVM是IBM开发的专门用来研究JVM实现技术的项目。曾用名Jalapeño。它是一个元循环虚拟机（metacircular VM），整个JVM都是用Java实现的。
最有趣的地方是它有一个名为MMTk的框架：Jikes RVM - MMTk，可以很方便的编写新的GC算法插入到Jikes RVM里去，而且已有的实现的选择也很丰富。所以很多研究GC算法的论文会选择基于Jikes RVM/MMTk来做初步实现，不但做起来容易，还可以很方便的与别的算法对比。
10.2 Maxine VM
Maxine VM是Oracle/Sun Labs开发的研究项目。跟Jikes RVM一样是元循环虚拟机。
Maxine VM自从有了C1X/T1X编译器之后，性能似乎就超过了Jikes RVM；有了Graal编译器之后更加压倒Jikes RVM。做JIT编译器研究的话我会选择用Maxine VM。
10.3 Graal VM
Graal VM就是Maxine VM的Graal编译器插在HotSpot VM上。现在Oracle Labs和一些大学做JIT编译器研究都是基于Graal VM来做的，效果出奇的好，性能基本跟HotSpot Server Compiler（C2）持平甚至有所超越。势头正猛。
以前百家争鸣的时候，研究性JVM或配套的JIT编译器那也是多得要命。ORP、OpenJIT、Moxie、Joeq、CACAO、SableVM、VMKit、Sun ExactVM / ResearchVM…随便列几个。
更多文章
这里不是转载的。