JVM概述

返回主博客

 

目录

JVM特点

JVM为什么叫虚拟机（程序虚拟机）：

JVM位置结构

指令集架构：

JVM的生命周期

JVM发展历程

JVM内存结构

 

---

 

JVM特点

一次编译（可是是其他语言编译的，JVM只解释字节码就行），到处运行。

自动内存管理

自动垃圾回收

 

JVM为什么叫虚拟机（程序虚拟机）：

它管理一块内存，解释运行一段程序。

 

JVM位置结构

 

 

指令集架构：

• 1、基于栈的指令集架构：

需要操作数栈和局部变量表（零地址）

如：int a = 2; int b = 3; int c = a+b;这段代码对应的指令

Icounst_2

istore_1

Icounst_3

istore_2

iload_1

iload_2

add

istore_3

• 2、基于寄存器的指令集架构：

以地址+指令的方式（指令集大但是少）

如

move eax 2

add eax 3

• 3、二者的优缺点

由于跨平台的设计，jvm指令都是基于栈来设计的，不同CPU架构不同，不能设计为基于寄存器的。有点指令小，跨平台（和硬件的耦合度低），编译器容易实现。但是指令多，性能低。（但是安卓的JVM是基于 寄存器的指令集架构）

 

JVM的生命周期

• 1、虚拟机启动：

通过引导类加载器(bootStrap class loader) 创建一个初始类（initial class）这个类由虚拟机具体实现指定的。我们写的main方法的启动类是由系统类加载器加载的。

 

• 2、虚拟机执行：

一个运行中的java虚拟机有一个清晰的java任务，程序运行他才运行，程序结束他就停止了。执行java程序就是一个jvm进程。

• 3、虚拟机退出：

程序正常结束

异常没有catch

操作系统错误

System.exit方法和Runtime.halt 这里的Runtime其实就是虚拟机中的运行时数据区。

 

JVM发展历程

• Sun Classic VM

1996 jdk1.0开始 1.4淘汰

只提供了解释器（会一行行解释，就算是for 循环，也会一行行解释）

如果使用JIT即时编译器（如果只用JIT即时编译器就会程序启动相当慢卡顿），就不能使用解释器，JIT会接管虚拟机的执行系统。解释器不再工作，解释器和编译器不能配合工作。

什么是解释器，什么是即时编译器 ？

解释器可以对指令进行逐行解释运行，编译器可以从总体上把握进行解释。如果只有解释器，他就一行行解释，效率会很慢，如果只使用编译器，则程序必须将所有指令解释完才能运行，启动慢。

现在的hotSpot内置类Sun Classic VM

 

• Exact VM

为了解决以上问题，jdk1.2提供此虚拟机

1、Exact memory Management 准确试内存管理

虚拟机可以知道内存中某个位置的数据是什么类型

2、编译器和解释器混合工作，并且可以热点探测

只在Solaris平台暂用

还没等他在其他平台使用就被HotSpot替换

 

• HotSpot VM

被一家小公司设计，1997年被Sun收购，jdk 1.3  HotSpot VM 为默认虚拟机。现在不管是JDK6还是JDK8都是默认HotSpot，Sun/Oracle JDK 和 OpenJDK 都是HotSpot

在服务器，桌面，移动端和嵌入式都有应用。

HotSpot 名称意思就是热点代码探测技术

通过计数器找到最具编译价值的代码，开始就即时编译（CodeCache）和栈上替换（对象不一定在堆可以在栈，可以在栈由本地内存创建，这样GC效率高，后面会介绍，栈上替换其实并没有应用起来）

解释器和编译器同时工作，在最优化的程序响应和最佳执行性能取得平衡。

• BEA 的JRockit

专注于服务器端 ：不太关注程序启动速度，因此内部不包含解释器，全部代码都靠即时编译器编译后执行

大量行业测试显示 JRockit 是世界上最快的虚拟机：显著的性能提升（70%） 和 硬件成本减少。

优势：全面的java运行时解决方案组合：

      对于相对延迟敏感型的也有配套方案JRockit Real Time提供毫秒或微秒级的JVM响应。适合财务，军事指挥，电信网络

      MissionControl 服务套件，以一套极低开销的来监控，管理，分析生产环境的应用程序工具

     包括内存泄漏检测器，运行时分析器，管理控制台。

无永久代

BEA被收购 ，一些好的地方被HotSpot整合比如JMC

 

• IBM J9（IT4J）

用于服务器，桌面，嵌入式

无永久代

号称世界上最快，只是IBM自己的产品最快

17年 发布Open J9交给eclipse 基金会打理

 

• TAOBAO JVM

由于阿里很多都是服务应用，都是基于Spring框架的，其实Spring容器中的对象几乎是和JVM生命周期相同的。这些对象压根不会被GC，因此做了如下定制：

将生命周期长的对象移到了堆外的GCIH，GC不能管理GCIH对象，从而提升GC效率，GCIH的对象可以在多个JVM共享

• Graal VM

VM使得java在某些场景下运行效率不够高，有时想要提升效率，必须得定制，但是自己定制的和操作系统，硬件，以及应用场景耦合度高。oracel 再次响应口号 ：Run master annyWhere。意思是想在任何地方都能运行的更快。

可以多语言混合

• Dalvik VM

用于安卓，基于寄存器架构（因为手机端应用很注重用户体验），处理的是dex文件，还可以提前编译

• KVM CDC/CLDC

针对javaMe

• Azul VM

和特定硬件平台和软件耦合，从而高性能

• Liquit VM

BEA 研发，和自家硬件系统运行很快的

• Apache Harmony

大量类库吸入安卓SDK

JVM内存结构

先上一个详细的大图，后面一一解释