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

简介: 本身实现一个专门操作系统。运行在自家Hypervisor系统上

image.png


内容基本来自《深入理解JVM虚拟机》。算是对于发展历史的一点个人总结。


概述:


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


思维导图:


image.png


虚拟机发展历史


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得到一定的跨平台能力
相关文章
|
3天前
|
监控 算法 Java
Java虚拟机(JVM)使用多种垃圾回收算法来管理内存,以确保程序运行时不会因为内存不足而崩溃。
【6月更文挑战第20天】Java JVM运用多种GC算法,如标记-清除、复制、标记-压缩、分代收集、增量收集、并行收集和并发标记,以自动化内存管理,防止因内存耗尽导致的程序崩溃。这些算法各有优劣,适应不同的性能和资源需求。垃圾回收旨在避免手动内存管理,简化编程。当遇到内存泄漏,可以借助VisualVM、JConsole或MAT等工具监测内存、生成堆转储,分析引用链并定位泄漏源,从而解决问题。
12 4
|
2天前
|
存储 监控 Java
JVM:Java虚拟机探秘
JVM:Java虚拟机探秘
8 1
|
5天前
|
算法 Java
Java垃圾回收(Garbage Collection,GC)是Java虚拟机(JVM)的一种自动内存管理机制,用于在运行时自动回收不再使用的对象所占的内存空间
【6月更文挑战第18天】Java的GC自动回收内存,包括标记清除(产生碎片)、复制(效率低)、标记整理(兼顾连续性与效率)和分代收集(区分新生代和老年代,用不同算法优化)等策略。现代JVM通常采用分代收集,以平衡性能和内存利用率。
31 3
|
11天前
|
存储 Java 编译器
JVM系列7-虚拟机字节码执行引擎
JVM系列7-虚拟机字节码执行引擎
11 1
|
24天前
|
存储 算法 Java
深入理解Java虚拟机(JVM)的垃圾回收机制
【5月更文挑战第30天】 在Java开发领域,垃圾回收(Garbage Collection, GC)是确保应用程序性能和内存效率的关键因素。本文将深入探讨Java虚拟机(JVM)的垃圾回收机制,解析其工作原理、不同算法的特点以及如何通过调优来提高应用性能。我们将透过JVM的内存结构,探索垃圾回收过程中涉及的关键技术点,并讨论现代Java应用中常见的垃圾回收器实现。
|
3天前
|
算法 Java 程序员
JVM虚拟机的故事
JVM虚拟机的故事
3 0
|
23天前
|
存储 安全 Java
深入探究Java虚拟机(JVM)的技术细节
深入探究Java虚拟机(JVM)的技术细节
|
27天前
|
存储 Java 开发者
深入理解Java虚拟机:JVM内存模型解析
【5月更文挑战第27天】 在Java程序的运行过程中,JVM(Java Virtual Machine)扮演着至关重要的角色。作为Java语言的核心执行环境,JVM不仅负责代码的执行,还管理着程序运行时的内存分配与回收。本文将深入探讨JVM的内存模型,包括其结构、各部分的作用以及它们之间的相互关系。通过对JVM内存模型的剖析,我们能够更好地理解Java程序的性能特征,并针对性地进行调优,从而提升应用的执行效率和稳定性。
jvm虚拟机中运行时数据区域介绍
jvm虚拟机中,运行时数据区域包括七大部分 i. 程序计算器 i. 定义 1) 极小的内存空间; 2) 行号指示器,程序的分支、循环、跳转、异常处理、线程恢复等基本功能都需要依赖程序计算器; 3) 线程私有的。
6187 0
|
25天前
|
存储 SQL 数据挖掘
服务器数据恢复—误删除VMware虚拟机vmdk文件的数据恢复案例
服务器数据恢复环境: 某大厂PS4000服务器,服务器上部署VMware ESXi虚拟化平台。 服务器故障: 机房断电,重启后服务器中的某台虚拟机不能正常启动。管理员查看虚拟机配置文件,发现无法启动的虚拟机的配置文件除了磁盘文件以外其他配置文件全部丢失,xxx-flat.vmdk磁盘文件和xxx-000001-delta.vmdk快照文件还存在。联系VMware原厂工程师进行诊断,VMware原厂工程师尝试新建一个虚拟机,但发现存储空间不足,于是将故障虚拟机下的xxx-flat.vmdk磁盘文件删除了。VMware工程师重新建了一个虚拟机,分配了固定大小的虚拟磁盘,为虚拟机安装了Window
服务器数据恢复—误删除VMware虚拟机vmdk文件的数据恢复案例