JVM基础-Java类加载机制

类的生命周期

类加载过程包括 加载、验证、准备、解析、初始化。

加载：查找并加载类的二进制数据

加载阶段，虚拟机需要完成三件事情：

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

连接

验证：确保被加载的类的正确性

确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。大致分为4个阶段：

• 文件格式验证 （是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理）
• 元数据验证 （对字节码描述的信息进行语意分析，以保证其描述的信息符合Java语言规范要求）
• 字节码验证 （保证被校验类的方法在运行时不会做出危害虚拟机安全的行为）
• 符号引用验证 （确保解析动作能正确执行，虚拟机将符号引用转化为直接引用时，解析阶段中发生）

准备：为类的静态变量分配内存，并将其初始化为默认值

• 本阶段进行内存分配的仅包含类变量(static)，不包含实例变量，实例变量会在对象实例化时随着对象一起分配在java堆中。
• 设置的初始值是数据类型默认的零值(如0，0L，null，false等)，而不是被在java代码中显式地赋予的值。
  假设一个类变量定义为：public static int a = 3，那么变量a在准备阶段被赋值0，而不是3。将a赋值为3的put static指令在程序编译后，存放于类构造器()方法中，所以把a赋值为3的动作在初始化阶段才会执行。
  需要注意：
• 基本数据类型，对于类变量(static)和全局变量，如果不显示的赋值，系统赋予默认值，对于局部变量来说，使用前必须显示赋值，否则编译不通过。
• 对于同时被static和final修饰的常量，必须在声明的时候就显示的赋值，否则编译不通过；只被final修饰的常量则可以在声明时显示的赋值，也可以在类初始化时显示赋值。
• 如果类字段的字段属性表中存在ConstantValue属性，即同时被final和static修饰，那么在准备阶段变量a就会被初始化为ConstantValue。public static final int a = 3，那么在准备阶段就赋值为3。

解析：把类中的符号引用转化为直接引用

直接引用和间接引用：https://blog.youkuaiyun.com/weixin_41490593/article/details/95110259?utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2_{aggregatepage}first_rank_ecpm_v1~rank_v31_ecpm-2-95110259-null-null.pc_agg_new_rank&utm_term=%E7%B1%BB%E7%9A%84%E7%AC%A6%E5%8F%B7%E5%BC%95%E7%94%A8%E6%98%AF%E4%BB%80%E4%B9%88&spm=1000.2123.3001.4430

初始化

为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要是对类变量进行初始化，对类变量进行初始化有两种方式：

• 声明类变量是指定的初始值
• 使用静态代码块为类变量指定初始值

类初始化时机

• 创建类实例，也就是new
• 访问某个类或者接口的静态变量，或者对该静态变量赋值
• 调用类的静态方法
• 反射
• 初始化某个子类，则其父类也会被初始化
• java虚拟机启动时被标明为启动类的类(java test)，直接使用java.exe命令来运行某个主类

使用

类访问方法区内的数据结构的接口，对象是heap区的数据

卸载

Java虚拟机结束生命周期的几种情况

• 执行了System.exit()方法
• 程序正常执行结束
• 抛出异常或者错误而终止
• 由于操作系统错误导致java虚拟器进程终止

类加载器，jvm类加载机制

类加载器的层次

BootStrapClassLoader <- ExtClassLoader <- AppClassLoader

站在虚拟机角度，存在两种类加载器：启动类加载器：使用c++实现，是虚拟机的一部分；其他类加载器都是使用java实现，独立于虚拟机之外，全部继承java.lang.ClassLoader，这些类加载器需要由启动类加载器加载到内存之后才能去加载其他类

站在java开发人员角度，可以分为：
启动类加载器： Bootstrap ClassLoader，负责加载存放在JDK\jre\lib\rt.jar下，或者被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库(所有java.*开头的类均被Bootstrop ClassLoader加载)。启动类加载器是无法被java程序直接引用的

扩展类加载器: Extension ClassLoader，负责加载JDK\jre\lib\ext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库（入javax.*开头的类），开发者可以直接使用扩展类加载器

应用程序类加载器: Application ClassLoader，负责加载用户类路径(ClassPath)所指定的类。CLASSPATH、-classpath、 -cp

可以加入自定义的类加载器：

1. 从特定的场所取得java class, 例如数据库和网络

寻找类加载器

类的加载

三种方式：

1. 命令行启动应用时，由JVM初始化加载
2. 通过Class.forName()方法动态加载
3. 通过ClassLoader.loadClass()方法动态加载

Class.forName()和ClassLoader.loadClass()区别？

• Class.forName() 将类的.class文件加载到jvm，还会对类进行解释，执行类的static块
• ClassLoader.loadClass() 只会将.class文件加载到jvm，不会执行static块

jvm类加载机制

双亲委派机制：
每⼀个类都有⼀个对应它的类加载器。系统中的 ClassLoder 在协同⼯作的时候会默认使⽤ 双亲委派模型 。即在类加载的时候，系统会⾸先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。加载的时候，⾸先会把该请求委派该⽗类加载器的 loadClass() 处理，因此所有的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader 中。当⽗类加载器⽆法处理时，才由⾃⼰来处理。当⽗类加载器为null时，会使⽤启动类加载器 BootstrapClassLoader 作为⽗类加载器。
双亲委派机制过程

1. 当AppClassLoader加载一个class时，先委派给父类加载器ExtClassLoader去完成
2. 当ExtClassLoader加载一个class时，先委派给BootstrapClassLoader去完成
3. 如果BootstrapClassLoader加载失败(例如在JDK\jre\lib里面没有找到class)，使用ExtClassLoader尝试加载
4. ExtClassLoader失败则使用AppClassLoader来加载，如果AppClassLoader加载失败，报异常：ClassNotFoundException
   双亲委派优势
5. 防止内存中出现同样的字节码
6. 保证java程序安全稳定运行
   破坏双亲委派机制
7. 重写loadClass方法
8. Tomcat 可以加载自己目录下的 class 文件，并不会传递给父类的加载器 https://blog.youkuaiyun.com/cristianoxm/article/details/124994534
9. java spi， 发起者 BootstrapClassLoader 已经是最上层了，它直接获取了 AppClassLoader 进行驱动加载，和双亲委派是相反的

自定义类加载器

通常，都是直接使用系统类加载器。有时候需要自定义类加载器。比如应用是通过网络传输java字节码，为了保证安全，这些字节码都经过加密处理，这个时候系统类加载器就无法进行加载，需要实现自定义类加载器，重写findClass方法。

参考文章