本文详细介绍了Java虚拟机（JVM）的概述、整体结构和架构模型，强调了栈式指令集架构的跨平台性和性能特点。探讨了JVM的生命周期，从启动、执行到退出的各个阶段。此外，文章回顾了JVM的发展历程，如ClassicVM、HotSpotVM和GraalVM等。重点讲解了类加载器子系统的功能、类加载的全过程，包括加载、链接（验证、准备、解析）和初始化。最后，阐述了双亲委派模型的工作原理及其重要性。
本jvm系列文章来源B站尚硅谷康师傅的视频，该系列文章作为学习笔记持续更新。视频地址：尚硅谷宋红康JVM全套教程（详解java虚拟机）_哔哩哔哩_bilibili
JVM概述
- JVM是一个跨语言的平台
2.JVM整体结构
JVM 的架构模型
- java 编译器输入的指令流基本上是一种基于栈的指令集架构，另外一种指令集架构则是基于寄存器的指令集架构。
- 具体来说，这两种架构之间的区别：
-
- 基于栈式架构的特点
设计和实现更简单，适用于资源受限的系统。
指令流中的指令大部分是零地址指令，其执行过程依赖于操作栈，指令集更小，编译器容易实现。
不需要硬件支持，可移植性更好，更好的实现跨平台。
-
- 基于寄存器架构的特点
指令集架构则完全依赖硬件，可移植性差。
性能优秀和执行更高效。
花费更少的指令去完成一项操作。
在大部分情况下，基于寄存器架构的指令集往往都以一地址指令、二地址指令和三地址指令为主，而基于栈式架构的指令集却是以零地址指令为主。
总结：
-
- 由于跨平台性的设计，java的指令都是根据栈来设计的。不同平台CPU架构不同，所以不能设计为基于寄存器的。优点是跨平台，指令集小，编译器容易实现。缺点是性能下降，实现同样的功能需要更多的指令。
- 时至今日，尽管嵌入式平台已经不是java程序的主流运行平台了（准确来说应该是HotSpotVM 的宿主环境已经不局限于嵌入式平台了），那么为什么不将架构更换为基于寄存器的架构呢？
- 栈：跨平台性、指令集小、指令多；执行性能比寄存器差。
JVM的生命周期
- 虚拟机的启动
java虚拟机的启动是通过引导类加载器（bootstrap class loader）创建一个初始类（initial class）来完成的，这个类是由虚拟机的具体实现指定的。
- 虚拟机的执行
一个运行中的Java虚拟机有着一个清晰的任务：执行Java程序。
程序开始执行时它才运行，程序结束时他就停止。
执行一个所谓的Java程序时，真真正正在执行的是一个叫做Java虚拟机的进程。
- 虚拟机的退出
程序正常执行结束。
程序在执行过程中遇到了异常或错误而异常终止。
由于操作系统出现错误而导致Java虚拟机进程终止。
某线程调用Runtime类或System类的exit方法，或Runtime类的halt方法，并且Java安全管理器也允许这次halt或exit操作。
JVM发展历程
- Classic VM
1996年Java1.0版本时，sun公司发布了一款名为Sun Classic VM的Java虚拟机。也是世界上第一款商用Java虚拟机，JDK1.4时完全被淘汰。
这款虚拟机内部只提供解释器，如果使用JIT编译器，就需要进行外挂，一旦使用了JIT编译器，解释器就不再工作，解释器和编译器不能配合工作。
- Exact VM
jdk1.2时，sun提供了此虚拟机。只在sun公司内部的Solaris平台短暂使用，其他平台上还是Classic vm，最终被Hotspot vm替代。
- HotSpot VM（被oracle收购）
Hotspot vm最初是由一家longview technologies的小公司设计，1997年该公司被sun公司收购。
JDK1.3时，hotspot vm称为默认的虚拟机。
从服务器端，桌面到移动端，嵌入式都有应用。
- JRockit VM （被oracle收购）
专注于服务器端应用，JRockit VM内部不包含解释器实现，全部代码都靠即使编译器编译后执行。
JRockit VM是世界上最快的JVM。
- J9 (IBM出品)
市场定位与HotSpot接近，服务器端，桌面应用，嵌入式等多用途VM。
在IBM出品的硬件服务器上性能卓越，在其他厂商的硬件上性能一般。像ios软硬件高度耦合。
- Graal VM
2018年4月，Oracle公开了Graal VM号称“Run Programs Faster Anywhere”，在HotSpot VM基础上增强而成的跨语言全栈虚拟机，可以作为任何语言的运行平台使用，语言包括Java、Scala、Python、C、C++、JavaScript、Ruby等等。
如果说HotSpot VM 有一天真的被取代，Graal VM希望最大。
类加载器
- 类加载器子系统作用
类加载器子系统负责从文件系统或者网络中加载class文件。 ClassLoader只负责class文件的加载，至于它是否 可以运行，则由Execution engine(执行引擎)决定。 加载的类信息存放于一块称为方法区的内存空间，除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是class文件中常量池部分的内存映射）.
- 类加载器角色
class file 存在于本地硬盘上，可以理解为设计师画在纸上的模板，而最终这个模板在执行的时候是要加载到JVM当中来根据这个文件实例化出n个一模一样的实例。
class file 加载到JVM中，被称为DNA元数据模板，放在方法区。
在.class文件-->JVM-->最终成为元数据模板，此过程就要一个运输工具（类装载器Class Loader），扮演一个快递员的角色。
类的加载过程
加载
1.通过一个类的全限定名获取定义此类的二进制字节流。
2.将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3.在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问的入口。
链接
验证
-
- 目的在于确保class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全。
- 主要包括四种验证，文件格式验证、元数据验证、字节码验证、符号引用验证。
准备
-
- 为类变量（静态变量），分配内存并且设置该变量的默认初始值，即零值。
- 这里不包含用final修饰的static，因为final在编译的时候就会分配了，准备阶段会显式初始化。
- 这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中。
解析
-
- 将常量池内的 符号引用转换为直接引用的过程。
- 事实上，解析操作往往会伴随着JVM在执行完初始化之后再执行。
- 符号引用就是一组符号来描述所引用的目标，符号引用的字面量形式明确定义在《java虚拟机规范》的Class文件格式中，直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
- 解析动作主要针对类或接口、字段、类方法接口方法、方法类型等。对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等。
初始化
1.初始化阶段就是执行类构造器方法<clinit>()的过程。
2.此方法不需定义，是Javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。
3.构造器方法中指令按语句在源文件中出现的顺序执行。
4.<clinit>()不是类的构造器，类的构造器为<init>()方法。（关联：构造器是虚拟机视角下的<init>()）。
5.若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕。
6.虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁。
1.类加载过程理解Demo
以下代码是合法的，静态代码块中先对变量赋值，下边定义该静态变量并赋值。
因为在类加载过程中，链接阶段的准备阶段会为静态变量分配内存并赋初始值，在该阶段，num静态变量就已经被分配到内存中了。
当到了下一个初始化阶段，静态变量的赋值，和静态代码块的语句会被整合到<clinit>（）方法中顺序执行，此时，则会先给已存在的num变量赋值20，然后再给num变量赋值10。
public class Demo1 {
static {
num = 20;
System.out.println(num); //报错，非法的前向引用。可以为下文声明的静态变量赋值，但是不能调用下文声明的静态变量。
}
private static int num = 10;
public static void main(String[] args) {
System.out.println(num);
}
}类加载器的分类
1.JVM支持两种类型的类加载器，分别为引导类加载器（Bootstrap Classloader，C和C++语言编写）和自定义类加载器（User-Defined ClassLoader，Java语言编写）
2.java虚拟机的定义是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。即JVM中自带的扩展类加载器和系统类加载器也属于自定义加载器。
3.在java的继承关系中，新的类称为子类，也叫派生类。
4.上图四种类加载器之间的关系是包含关系，不是上层下层，也不是子父类的继承关系。
5.各加载器详情
-
- 启动类加载器（引导类加载器 Bootstrap ClassLoader）
这个类加载器是用C/C++实现的，嵌套在JVM内部。
它用来加载Java的核心类库，（JAVA_HOME/jre/lib/rt.jar、resource.jar或sun.boot.class.path路径下的内容），用于提供JVM自身需要的类。
并不继承自java.lang.ClassLoader，没有父类加载器
加载扩展类和应用程序类加载器，并指定为他们的父类加载器。
出于安全考虑，Boobstrap启动类加载器只加载包名为java、javax、sun等开头的类。
-
- 扩展类加载器(Extension ClassLoader)
java语言编写，派生于ClassLoader类。
父类加载器为启动类加载器。
从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录（扩展目录）下加载类库，如果用户创建的JAR文件放在此目录下，也会自动由扩展类加载器加载。
-
- 应用程序类加载器（系统类加载器，AppClassLoader）
java语言编写，派生于ClassLoader类。
父类加载器为扩展类加载器。
它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库。
该类加载是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载的。
双亲委派机制
1.名词解释
java虚拟机对class文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象。而且加载某个类的class文件时，java虚拟机采用的是双亲委派模式，即把请求交由父类处理，他是一种任务委派模式。
2.工作原理
-
- 如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行；
- 如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器；
- 如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式。
package java.lang;
//由于双亲委派机制的存在，String类会被向上委托给引导类加载器加载java核心包中的String类。而java核心包中的String类里并没有main方法，所以会报如下错误
public class String {
static {
System.out.println("自定义的String类的静态代码块");
}
/**
* 错误: 在类 java.lang.String 中找不到 main 方法, 请将 main 方法定义为:
* public static void main(String[] args)
* 否则 JavaFX 应用程序类必须扩展javafx.application.Application
*/
public static void main(String[] args) {
System.out.println("hello");
}
}package java.lang;
//java.lang.Demo类会通过双亲委派机制被委托给根加载器加载，根加载器检测到该类包名为java开头，属于根加载器加载范畴，而Demo类是用户自定义类，引导类加载器直接抛出异常，阻止用户使用java开头的包名。
public class Demo {
/**
*Exception in thread "main" java.lang.SecurityException: Prohibited package name: java.lang
*/
public static void main(String[] args) {
System.out.println("hello");
}
}
类加载器其他知识点
1.在JVM中表示两个class对象是否为同一个类，有两个必要条件：
类的完整类名必须一致，包括包名。
加载这个类的ClassLoader(指ClassLoader实例对象)必须相同。
2.换句话说，在JVM中，即使这两个类对象（Class对象）来源同一个Class文件，被同一个虚拟机所加载，但只要加载他们的ClassLoader实例对象不同，那么这两个类对象也是不相等的。
3.JVM必须知道一个类是由启动类加载器加载的还是由用户类加载器加载的。如果一个类是由用户类加载器加载的，那么JVM会将这个类加载器的一个引用作为类信息的一部分保存在方法区中。当解析一个类到另一个类的引用的时候,JVM需要保证这两个类的类加载器是相同的。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
