深入理解jvm笔记（走进jvm）
绝大多数java程序员潜意识的把java虚拟机与oracle jdk的hotspot虚拟机等同看待，也许还有一些程序员会注意到 bea jrockit和ibm的j9虚拟机
但绝大多数人对java虚拟机的认识就仅限于此了
虚拟机始祖（sub classic、Exact VM）
sub classic
1996年发布，的jdk1.0中，java语言首次拥有了商用的正式运行虚拟，这个jdk自带的虚拟机就是classic vm。这款虚拟机使用纯解释的方法来执行java代码，如果要使用即时编译那就必须进行外挂，但是如果外挂了及时编译器的话，及时编译器就会完全接管虚拟机的执行系统，解释器便不再工作了。这就意味着如果要是用变异执行，编译器就不得不对每一个方法，每一行代码，都进行编译，无论它们执行的频率是否具有编译的价值。基于程序响应时间的压力，这些编译器根本不敢应用编译好事稍高的优化技术，因此这格阶段虚拟机虽然用了及时编译器输出本地代码，其执行效率也和传统的c/c++有很大的差距，java语言很慢，的映象就是在这阶段开始在用户心中树立起来的。
Exact VM
在jdk1.2时，为了提升运行效率，曾在solaris平台发不过去名为一款exact vm虚拟机，它的编译执行系统已经具备现代高性能虚拟机的雏形，如热点探测，俩级即时编译，编译器与解释器混合工作模式等。
exact vm因为它使用准确式内存管理而得名。准确式内存管理是指虚拟机可以知道内存中某个位置的数据具体是什么类型。譬如内存中有一个32bit的整数123456，虚拟机将有能力分辨出，它到底是指向了123456的内存地址的引用类型还是一个数值为123456的整数，混却分辨出哪些内存是引用类型，这也是在垃圾收集时准确判断堆上的数据是否还可能被使用的前提。
由于使用了准确式内存管理，exact vm可以抛弃掉之前classic vm基于句柄（handle）的对象查找方式
原因是垃圾收集后，对象讲可能会被移动位置，如果地址为123456的对象移动到654321在没有明确信息表明内存中哪些数据引用数据类型的前提下，那虚拟机肯定是不敢把内存中所有未123456的值改为654321的，所以要是用句柄来保持引用值的稳定，这样每次定位对象都少了一次间接查找的开销，显著的提升了虚拟机的性能
虽然Exact VM的技术相比于classic vm现进了许多，但是它的命运显得十分英雄气短，在商业没来得及发布windows和linux下的商用版本，就被hotspot取代。
相比这下classic的生命周期就要长许多了，它在jdk1.2之前是唯一的虚拟机，在jdk1.2时与hotpspot并存，打死默认使用的是classic，在jdk1.3的时候，hotspot成为默认虚拟机，classic vm仍作为虚拟机的备用选择，直到jdk1.4它才完全退出历史舞台。
武林盟主hospot VM
相信所有的java程序员都听说过hotspot虚拟机，它是sub/oracle jdk和openjdk中的默认虚拟机，也是目前使用最广的java虚拟机。
hotspot集成了sun之前俩款商用虚拟机的优点，（如前面提到的准确式内存管理 ）也有许多自己的新技术优势，如它名称中的hotspot指的是就是它的热点代码探测技术（其实hotspot和exact VM几乎同时期出现,而exact虚拟机上也有类似的热点探测技术）
hotspot vm的任店代码探测可以通过执行计数器找出最有编译价值的代码，然后通知即使编译器以方法为单位进行编译。如果一个方法频繁被调用或方法中有效循环次数很多，将会分别触发标准即使编译器和栈上替换编译行为。通过编译器与解释器恰当协同工作，可以在最优化程序响应时间最佳执行性能上取得平衡而且无需等待本地代码输出才能执行程序，即使编译的时间压力也相对较小，这样更有助于引入更复杂的代码优化技术，输出质量更高的本地代码
2006年，sub陆续将sunjdk的各个部分在gplv2协议下开放了源代码，形成了openjdk这个项目，其中当然也包括hotspot虚拟机。hotspot从此成为sub、oraclejdk和openjdk俩个实现极度相近的虚拟机。到了2014年的jdk8时期，里面的hotspot就已是俩这融合的结果，hotspot在这个过程中移除掉了永久代，吸收了jrocket的java mission Control监控工具功能。
得益于sun/OracleJDK在java中的统治地位，hotspot理所当然的成为了全世界使用最广发你的java虚拟机。
天下第二BEA JROcit/IBM J9 VM
前面介绍的都是由sub、oracle公司研发的虚拟机，历史上除了sun，oracle公司以外，也有其他组织开发过虚拟机实现。Jorckit与IBM j9。
Jrocit
jrockit曾经的称号是世界上最快的java虚拟机，BEA公司将其发展为一款专门为服务器硬件和服务器端应用场景高度优化的虚拟机，由于专注于服务端应用，它可以不太关注程序启动的速度，因此krockit内部不包含解释器的实现，全部代码都靠及时编译器编译后执行。除此之外，Jrockit的垃圾收集器和java Mision Control故障处理套件等部分的实现，在当时众多的java虚拟机中也处于领先水平。jrockit随着EBA被Oracle收购现在已经不继续发展，永远停留在r28版本，这是jdk6版jrockit的代号。
IBM J9
与BEA Jrockit只专注于服务端不同，IBM J9虚拟机的市场定位于Hotspot十分接近，它是一款在设计上全面考虑服务端应用，桌面端应用，再到嵌入式的多用途虚拟机，开发J9的目的是作为IBM公司各种java产品的执行平台，在IBM产品搭配自己在IBM和z、OS这些平台上部署java应用。
IBM j9至今十分活跃它的职责分离模块化作的比hotspot更加优秀。
从2016年起，IBM逐步将ORM项目和J9虚拟机进行开源，完全开源后便将它们捐献给了eclipse基金会管理，并重命名为Eclipse MR和Open J9。如果是为了学习虚拟机技术而去阅读源码，更加模块化的open j9谁是一个更好的选择。
除了BEA和IBM公司外，其他一些大公司也有号称专属的JDK和专属的虚拟机，但是要么是通过sun/Oracle购买版权的方式获得的，要么是基于OpenJdk改进而来，（如阿里巴巴，推特等），都并非自己独立研发
软硬合璧：BEA Liquid VM / Azul VM
liquid vm也被成为jroct ve，她是BEA公司开发的可以直接运行在自家Hypervisor系统上的Jrockit虚拟机的虚拟化版本，不需要操作系统支持
Azul VM是Azul Systems公司在Hot spot基础上进行大量改进，运行于Azul Systems公司的专有硬件Vega系统上的java虚拟机，每个Azul VM实力都可以管理数十个CPU和数百GB的内存的硬件资源。并提供巨大内存范围内停顿时间的可控垃圾收集器（PGC和C4垃圾收集器），为硬件优化的线程调度等优秀性。
2010年，AzulSystems公司开始从硬件转向软件，发布了自己的zing JVM，可以在通用x86平台上提供接近于Vega系统的特性