深入理解JVM虚拟机 - 虚拟机的发展历史

简介: 深入理解JVM虚拟机 - 虚拟机的发展历史

概述:



  1. JVM的发展历史以及历史进程
  2. Hotspot为什么可以称霸武林
  3. Hotspot和JRocket 合并,结果喜忧参半
  4. jvm面临的挑战以及未来的发展前瞻


思维导图:


网络异常,图片无法展示
|


虚拟机发展历史


classic VM - 第一台正式商用JAVA虚拟机


于1996年1月23日Sun发布jdk1.0诞生,是JAVA真正意义上第一台JVM虚拟机

特点:

  • 只支持纯解释器运行
  • 条件编译智能用外挂(Sun wjit)。解释器和编译器不能配合工作
  • 内部工作原理十分简单

意义:

  • jdk1.2之前唯一指定虚拟机
  • jdk1.2 存在hotspot和exact vm 混合的情况


媲美hotspot的虚拟机:Exact Vm


特点:

  • 准确的内存管理(可以知道那一块内存的精确数据类型)。抛弃基于句柄的对象查找方式
  • 热点探测,两级即时编译,编译和解释混合

意义:

  • 由于更优秀的HotSpot虚拟机出现,没有被正式商用,存在时间十分短暂
  • jdk1.2时,sun提供了此虚拟机配合classic使用


武林霸主:hotspot Vm


特点:

  • 具备exact vm虚拟机的所有特性
  • 支持热点代码探索
  • 精确的内存管理
  • 高频代码的标准即使编译和栈上替换(重要)

意义:

  • HotRocket:jdk8的Hotspot和JRocket进行合并
  • 实际效果并不好,JRocket的很多特性没有发挥出来。


手机端虚拟机:Embeded vm


专门为了移动智能手机设计的一款jvm,但是最终失败。被Andriod直接取代。


天下第二:JRocket 和 IBM J9VM


JRocket:

特点:
  • 2008年JRockit随着BEA被Oracle收购,现已不再 继续发展,永远停留在R28版本,这是JDK 6版JRockit的代号。
  • JRockit内部不包含解释器实现,全部代 码都靠即时编译器编译后执行
  • 专门为服务器硬件和服务端应用场景高度优化的虚拟机
意义:
  • 在JDK1.8当中oracle整合JRockit到HotSpot虚拟机上,但是由于两者的特性差异较大,只整合了部分特性,结果并不是十分理想
  • 作为一款优秀的JVM实现曾经领先JVM前列
  • 同时伴随着优秀的组件Java Mission Control故障处理套件诞生。

IBM J9VM

特点:
  • 原名叫做:IT4J,由于名字不好记J9更为广泛认知
  • 由k8扩展而来,名字来源于一个8bit的错误问题
  • 号称是世界上最快的Java虚拟机(官方定义)
  • 在商用虚拟机的领域极具影响力
意义:
  • 2017年左右,IBM发布了开源J9 VM,命名为openJ9,交给Eclipse基金会管理,也称为Ecilpse openJ9


需要特殊平台运行:Bea liquid / Azulejo VM (专用虚拟机)


Bea liquid:

特点:
  • 本身实现一个专门操作系统。运行在自家Hypervisor系统上
  • 由于JRocket的开发而终止。
意义:
  • 随着JRockit虚拟机终止开发,Liquid VM项目也停止了。

Azule VM:

特点:
  • 对于HotSpot进行大量的改进,运行与Azul System专有系统上面的Java虚拟机
  • 提供巨大的内存范围的停顿时间和垃圾收集时间:pic收集器c4收集器
意义:
  • 最终产线投入到Zing VM虚拟机
  • 低延迟
  • 快速预热
  • 易于监控


挑战:Apache Harmony / google android dalvik vm


Apache Harmony:

特点:
  • 对于HotSpot进行大量的改进,运行与Azul System专有系统上面的Java虚拟机
  • 提供巨大的内存范围的停顿时间和垃圾收集时间:pic收集器c4收集器
意义:
  • 曾经因为提交TCK和SUN矛盾而愤然退出JCP组织
  • 由于Open Jdk 的出现悄然退出市场。但是内部许多的代码吸收进ibm open jdk7的实现

google android dalvik vm

特点:
  • andriod 4之前是主流的虚拟机平台,5之后被支持提前编译ART虚拟机替代
  • 曾经非常强力的一个虚拟机
  • 不能直接运行class,但是和JAVA有着很密切的关系
  • DEX文件可以通过Class文件进行转化
意义:
  • andriod 5之后被支持提前编译ART虚拟机替代


其他JVM虚拟机


这里介绍一些书中没有提到的非重点的JVM虚拟机

  • Micronsoft JVM:曾经作为Window平台性能最好的虚拟机。被Sun公司进行侵权制裁之后,微软转而与JAVA为敌,开发后续的.net语言对抗JAVA生态。
  • KVM:强调轻量,简单,高度可移植。运行速度比较慢。在IOS和Android出现之前受到欢迎
  • JAVA Card VM:JAVA虚拟机的一个子集,负责Applet解释和执行
  • Squarewk VM:由Sun公司开发,运行于Sun SPot,也曾经用于java card。是一款JAVA比重十分高的虚拟机。
  • JavaInJava:Sun公司在97 - 98年开发一款实验性质的虚拟机,必须运行在一个宿主的JVM上面。价值在于自证元循环,具备一定的研究价值
  • Maxine VM: 和javainjava非常相似,几乎全部以JVM作为运行环境,Graal编辑器让他有了更进一步的发展,同时Graal也是作为graal编辑器的良好辅助虚拟机
  • Jikes RVM: ibm开发的专门研究JAVA虚拟机技术的项目。也是一个元循环虚拟机
  • IKVM.NET:基于.NET 框架的java虚拟机,借助MONO得到一定的跨平台能力
相关文章
|
2月前
|
监控 算法 Java
Java虚拟机(JVM)的垃圾回收机制深度解析####
本文深入探讨了Java虚拟机(JVM)的垃圾回收机制,旨在揭示其背后的工作原理与优化策略。我们将从垃圾回收的基本概念入手,逐步剖析标记-清除、复制算法、标记-整理等主流垃圾回收算法的原理与实现细节。通过对比不同算法的优缺点及适用场景,为开发者提供优化Java应用性能与内存管理的实践指南。 ####
|
1月前
|
监控 算法 Java
Java虚拟机(JVM)垃圾回收机制深度剖析与优化策略####
本文作为一篇技术性文章,深入探讨了Java虚拟机(JVM)中垃圾回收的工作原理,详细分析了标记-清除、复制算法、标记-压缩及分代收集等主流垃圾回收算法的特点和适用场景。通过实际案例,展示了不同GC(Garbage Collector)算法在应用中的表现差异,并针对大型应用提出了一系列优化策略,包括选择合适的GC算法、调整堆内存大小、并行与并发GC调优等,旨在帮助开发者更好地理解和优化Java应用的性能。 ####
44 0
|
1月前
|
存储 监控 算法
深入探索Java虚拟机(JVM)的内存管理机制
本文旨在为读者提供对Java虚拟机(JVM)内存管理机制的深入理解。通过详细解析JVM的内存结构、垃圾回收算法以及性能优化策略,本文不仅揭示了Java程序高效运行背后的原理,还为开发者提供了优化应用程序性能的实用技巧。不同于常规摘要仅概述文章大意,本文摘要将简要介绍JVM内存管理的关键点,为读者提供一个清晰的学习路线图。
|
1月前
|
存储 监控 算法
Java虚拟机(JVM)垃圾回收机制深度解析与优化策略####
本文旨在深入探讨Java虚拟机(JVM)的垃圾回收机制,揭示其工作原理、常见算法及参数调优方法。通过剖析垃圾回收的生命周期、内存区域划分以及GC日志分析,为开发者提供一套实用的JVM垃圾回收优化指南,助力提升Java应用的性能与稳定性。 ####
|
2月前
|
机器学习/深度学习 监控 算法
Java虚拟机(JVM)的垃圾回收机制深度剖析####
本文深入探讨Java虚拟机(JVM)的垃圾回收机制,揭示其工作原理、常见算法、性能调优策略及未来趋势。通过实例解析,为开发者提供优化Java应用性能的思路与方法。 ####
58 1
|
2月前
|
监控 Java 开发者
Java虚拟机(JVM)深度优化指南####
本文深入探讨了Java虚拟机(JVM)的工作原理及其性能优化策略,旨在帮助开发者通过理解JVM的内部机制来提升Java应用的运行效率。不同于传统的技术教程,本文采用案例分析与实战技巧相结合的方式,为读者揭示JVM调优的艺术。 ####
62 8
|
2月前
|
监控 算法 Java
深入理解Java虚拟机(JVM)的垃圾回收机制
【10月更文挑战第21天】 本文将带你深入了解Java虚拟机(JVM)的垃圾回收机制,包括它的工作原理、常见的垃圾收集算法以及如何优化JVM垃圾回收性能。通过本文,你将对JVM垃圾回收有一个全新的认识,并学会如何在实际开发中进行有效的调优。
61 0
|
2月前
|
Ubuntu 网络安全 虚拟化
VMware虚拟机ping不通原因排查及分析
下面以 VMware 虚拟机为例进行介绍。
1232 3
|
2月前
|
存储 SQL 数据库
虚拟化数据恢复—Vmware虚拟机误还原快照的数据恢复案例
虚拟化数据恢复环境: 一台虚拟机从物理机迁移到ESXI虚拟化平台,迁移完成后做了一个快照。虚拟机上运行了一个SQL Server数据库,记录了数年的数据。 ESXI虚拟化平台上有数十台虚拟机,EXSI虚拟化平台连接了一台EVA存储,所有的虚拟机都存放在EVA存储上。 虚拟化故障: 工组人员误操作将数年前迁移完成后做的快照还原了,也就意味着虚拟机状态还原到数年前,近几年数据都被删除了。 还原快照相当于删除数据,意味着部分存储空间会被释放。为了不让这部分释放的空间被重用,需要将连接到这台存储的所有虚拟机都关掉,需要将不能长时间宕机的虚拟机迁移到别的EXSI虚拟化平台上。
118 50
|
3月前
|
安全 虚拟化 数据中心
Xshell 连接 VMware虚拟机操作 截图和使用
Xshell 连接 VMware虚拟机操作 截图和使用
88 4