JVM--类加载子系统--01

最新推荐文章于 2025-03-30 22:01:25 发布

Jesslili

最新推荐文章于 2025-03-30 22:01:25 发布

阅读量268

点赞数 1

分类专栏： JVM 文章标签： jvm java

本文链接：https://blog.youkuaiyun.com/myjess/article/details/108508012

版权

JVM 专栏收录该内容

16 篇文章

订阅专栏

JVM

java虚拟机就是二进制字节码的运行环境，负责装载字节码到其内部，解释/编译为对应平台上机器指令的执行。每一条java指令，java虚拟机规范中都有详细定义，如怎么取操作数，处理结果放在哪里。

特点：

一次编译，到处运行
自动内存管理
自动垃圾回收功能

内存图：
在这里插入图片描述

一、类加载器ClassLoader

在这里插入图片描述

从字节码开始，后续的工作都由JVM负责。
类加载子系统负责从文件系统或者网络中加载Class文件，放在方法区------DNA元数据模板。Class文件在文件开头有特定的文件标识。
类加载子系统只负责class文件的加载，至于它是否可以运行，则由执行引擎发挥决定。
加载的类信息存放在一块称为方法区的内存空间。除了类信息外，方法区中还会存放运行时的常量信息。
通过调用构造方法创建的对象存放在堆空间中。

二、类的加载过程

在这里插入图片描述

step1. 加载

通过一个类的全限定名获取定义此类的二进制字节流。
将这个字节流所代表的的静态存储结构转化为方法区的运行时数据。
在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的访问接口。

step2. 链接

验证：目的在于确保Class文件的字节流中包含的信息符合当前虚拟机的要求，保证被加载类的正确性，不会危害虚拟机自身安全。主要包括四种验证：文件格式验证、元数据验证、字节码验证、符号引用验证。
准备：
- 为类变量分配内存并且设置该类变量的默认初始值，即零值。
- 不包括含用final修饰的static（常量），因为final在编译时就分配了，准备阶段会显示初始化。
- 不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到java堆中。
解析：
1. 将常量池内的符号引用转换为直接引用的过程。
2. 事实上，解析操作网晚会伴随着jvm在执行完初始化之后再执行。
3. 符号引用就是一组符号来描述所引用的目标。符号应用的字面量形式明确定义在《java虚拟机规范》的class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
4. 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT_Class_info/CONSTANT_Fieldref_info、CONSTANT_Methodref_info等。

step3.初始化

初始化阶段就是执行类构造器方法 clinit() 的过程。

如果没有静态变量c，那么字节码文件中就不会有clinit方法

此方法不需要定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。
构造器方法clinit()中指令按语句在源文件中出现的顺序执行。
<clinit>()不同于类的构造器
若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕。
虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁，即一个类只需被clinit一次，之后该类的内部信息就被存储在方法区。。

三、类加载器分类

JVM支持两种类型的类加载器，分别为引导类加载器、和自定义加载器。

从概念上来讲，自定义类加载器一般指的是程序中由程序开发人员自定义的一类类加载器，但Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。

常见的加载器种类：
在这里插入图片描述

虚拟机自带的加载器

启动类加载器（引导类加载器，Bootstrap ClassLoader）:

使用C/C++语言实现的，嵌套在JVM内部
用来加载Java的核心类库（JAVA_HOME/jre/lib/rt.jar、resource.jar或者sun.boot.class.path路径下的内容），用于提供JVM自身需要的类。
因为是C/C++语言实现的，所以并不继承自java.lang.ClassLoader，没有父加载器。
加载扩展类和应用程序类加载器，并指定为他们的父类加载器。出于安全考虑，Bootstrap
ClassLoader只加载包名为java、javax、sun等开头的类。

扩展类加载器（Extension ClassLoader）:

Java 语言编写，由sun.misc.Launcher$ExtClassLoader实现
派生于ClassLoader类
父类加载器为启动类加载器BootstrapClassloader
从java.ext.dirs系统属性指定的目录中，或者从JDK的安装目录JAVA_HOME/jre/lib/ext子目录下加载类库。如果用户创建的JAR放在此目录下，也会自动由扩展类加载器加载

应用程序类加载器（系统类加载器，AppClassLoader）：

Java 语言编写，由sun.misc.Launcher$AppClassLoader实现
派生于ClassLoader类
父类加载器为ExtensionClassloader
它负责加载环境变量classpath或者系统属性，java.class.path指定路径下的类库
该类加载器是程序中默认的类加载器，一般来说，java应用类都是由他来加载完成的
通过ClassLoader.getSystemClassLoader()可以获取到该类加载器

自定义类与核心类库的加载器

对于用户自定义类来说：将使用系统类System Class Loader加载器中的AppClassLoader进行加载
java核心类库都是使用引导类加载器BootStrapClassLoader加载的

用户自定义类加载器

在日常Java应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，必要时可以自定义类加载器来定制类的加载方式。
用户自定义类默认使用系统类加载器进行加载。

为什么要自定义类加载器呢？
隔离加载类
修改类加载方式
扩展加载源
防止源码泄露

类加载器之间的父子关系和管辖范围图：

四、ClassLoader的常用方法及获取方法

ClassLoader类，它是一个抽象类，其后所有的类加载器都继承自ClassLoader（不包括启动类加载器）
在这里插入图片描述

五、双亲委派机制

Java虚拟机对class文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的class文件加载到内存生成的class对象。而且加载某个类的class文件时，java虚拟机采用的是双亲委派模式，即把请求交由父类处理，它是一种任务委派模式。

在这里插入图片描述
例如：自定义一个java.lang包并自定义一个String类。从测试结果来看，加载String对象的时候并没有选择本工程下的这个自定义类，而依然选择的java核心类里的String，因为返回结果为null，说明使用的类加载器是BootstrapClassLoader。
在这里插入图片描述
如果自定义java.lang包下一个核心API没有的类，也会报错，是为了防止核心API被篡改，会对引导类加载器本身造成影响。

双亲委派机制的优势：

避免类的重复加载，如上。
保护程序安全，防止核心API被随意修改。即使篡改了也不会去加载，即使加载也不会是同一个.class对象了。不同的加载器加载同一个.class也不是同一个Class对象。这样保证了Class执行安全。

沙箱安全机制：

自定义String类，但是在加载自定义String类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载jdk自带的文件（rt.jar包中的java\lang\String.class），运行自定义String类中的main方法时报错信息说没有main方法，就是因为加载的是rt.jar包中的String类。这样就可以保证对java核心源代码的保护，这就是沙箱安全机制。