JVM详解——类的加载

类的加载

1、Java程序如何运行

• 首先通过Javac命令将.java文件编译生成.class字节码文件。
  Javac是Java编译命令，编译过程分为四步。

  1. 词法解析，通过空格分隔出单词、操作符、控制符等信息，形成信息流传递给语法解析器。
  2. 语法解析，将信息流按照Java语法规则组装成语法树。
  3. 语义分析，检查类型是否匹配、关键词是否使用合理、作用域是否正确等。
  4. 字节码生产，将经过1、2、3步骤生产的新型转换为字节码。

• .class文件加载到JVM中经过一系列类加载流程，由解释器解释执行和JIT即时编译器将字节码文件编译成本地机器码执行。

  字节码必须通过类加载机制加载到JVM后方能执行，执行有三种模式，解释执行、JIT编译执行、JIT编译和解释器混合执行（主流JVM默认执行的方式）。混合模式优势在于解释器在启动时先解释执行，节省编译时间。
  解释执行： 来一行代码，解释一行，大部分不常用的代码，采用此种方式
  即时编译： 对于部分热点代码，虚拟机将该部分字节码编译生成机器指令，以提高Java虚拟机的运行效率

• CPU调度线程执行本地机器码

---

2、Java字节码文件

Class文件本质上是一个以字节为基础单位的二进制流，各个数据项目严格按照顺序紧凑的排列在class文件中。JVM根据其特定的规则解析该二进制数据，从而得到相关信息。Class文件采用一种伪结构来存储数据，它有两种类型：无符号数和表。

Class文件的结构属性：

1. 魔数与class文件的版本：class文件头4个字节称为魔数，是class文件的标识
2. 常量池：class文件的资源仓库，存储变量的属性、类型和名称；方法的属性、类型和名称等。
3. 访问标志：表示该class的属性和访问类型，比如class是类还是接口，访问类型是public、private，类型是否被标记为final
4. 类索引、父类索引、接口索引：一种描述的数据项目，class文件凭此确定类的继承和实现关系
5. 字段表属性：描述类或接口中声明的变量。比如变量的作用域（public、private、protected）、是否是静态变量（static）、可变性（final）、数据类型（基本数据类型、对象、数组）等
6. 方法表属性：描述方法的类型、作用域、返回值、参数、是否是重写或重载
7. 属性表属性：描述某些场景专有的信息。比如字段表中的特殊属性、方法表中的特殊属性。

---

3、类加载

Class 文件中描述的各类信息都需要加载到虚拟机后才能使用。JVM 把描述类的数据从 Class 文件加载到内存，并对数据进行加载、验证、解析和初始化，最终形成可以被虚拟机直接使用的 数据类型，这个过程称为虚拟机的类加载过程。

与编译时需要连接的语言不同，Java 中类型的加载、连接和初始化都是在运行期间完成的，这增加了性能开销，但却提供了极高的扩展性，Java 动态扩展的语言特性就是依赖运行期动态加载和连接实现的。

---

4、类加载的过程

一个类从被加载到虚拟机内存开始，到卸载出内存为止，整个生命周期经历加载、验证、准备、解析、初始化、使用和卸载七个阶段，其中验证、解析和初始化三个部分称为连接。加载、验证、准备、初始化阶段开始的先后顺序是确定的，解析则不一定：可能在初始化之后再开始，这是为了支持 Java 语言的动态绑定。

1. 加载：查找并加载类的二进制数据
   在加载阶段，虚拟机需要完成以下三个步骤：

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

2. 验证： 确保被加载类的正确性
   确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。验证分为4个阶段：文件格式验证、元数据验证、字节码验证、符号引用验证。

验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

3. 准备：为类的静态变量分配内存，并将其初始化为默认值
   准备阶段是正式为类变量分配内存并设置类变量初始值零值的阶段，这些内存都将在方法区中分配。
   注： 此时分配的是类变量（static），不包括实例变量。初始化的值是数据类型的默认零值，比如0、0L、null、false 等。

4. 解析：把类中的符号引用转换为直接引用
   解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。符号引用就是一组符号来描述目标，可以是任何字面量。

直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄

5. 初始化：JVM对类进行初始化赋值
   为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要对类变量进行初始化。

在Java中对类变量进行初始值设定有两种方式：

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

JVM初始化步骤：

• 假如这个类还没有被加载和连接，则程序先加载并连接该类
• 假如该类的直接父类还没有被初始化，则先初始化其直接父类
• 假如类中有初始化语句，则系统依次执行这些初始化语句

6. 使用：使用类的对象实例
   类访问方法区内的数据结构的接口， 对象是堆区的数据。
7. 卸载：类被卸载出内存
   Java虚拟机结束，类被卸载出内存。
   Java虚拟机结束生命周期的情况：
   • 执行了System.exit()方法
   • 程序正常执行结束
   • 程序在执行过程中遇到了异常或错误而异常终止
   • 由于操作系统出现错误而导致Java虚拟机进程终止

---

5、类加载器

启动类加载器：
Bootstrap ClassLoader，负责加载存放在JDK的安装目录下的jre\lib中，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库(如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载)。启动类加载器是无法被Java程序直接引用的。

扩展类加载器：

Extension ClassLoader，该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载JDK安装目录下的jre\lib\ext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库(如javax.*开头的类)，开发者可以直接使用扩展类加载器。

应用程序类加载器：

Application ClassLoader，该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径(ClassPath)所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

---

6、类的加载方式

类加载有三种方式:

1、命令行启动应用时候由JVM初始化加载

2、通过Class.forName()方法动态加载

3、通过ClassLoader.loadClass()方法动态加载

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

• Class.forName(): ​将类的.class文件加载到JVM中，还会对类进行解释，执行类中的static块；
• ClassLoader.loadClass(): ​只会将.class文件加载到JVM中，不会执行static中的内容,只有在newInstance() 方法创建类对象时才会去执行static块。
• Class.forName(name, initialize, loader)带参函数也可控制是否加载static块。并且只有调用了newInstance()方法构造函数创建类的对象时才会加载static块 。

7、类的加载机制

1. 缓存机制，缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区寻找该Class，只有缓存区不存在，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓存区。（修改了class后，需要重启虚拟机，程序的修改才会生效）
2. 双亲委派机制， 如果一个类加载器收到了类加载的请求，首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上。因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，也就是无法完成该加载，子加载器才会尝试自己去加载该类。

8、双亲委派机制

1. 当AppClassLoader加载一个class时，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器ExtClassLoader去完成。

2. 当ExtClassLoader加载一个class时，它首先也不会自己去尝试加载这个类，而是把类加载请求委派给BootStrapClassLoader去完成。

3. 如果BootStrapClassLoader加载失败(例如在$JAVA_HOME/jre/lib里未查找到该class)，会使用ExtClassLoader来尝试加载；

4. 若ExtClassLoader也加载失败，则会使用AppClassLoader来加载，如果AppClassLoader也加载失败，则会报出异常ClassNotFoundException。

双亲委派机制的好处：

• 系统类防止内存中出现多份同样的字节码（比如自己写的String类与JDK中的String类会优先使用JDK中的系统API）
• 保证Java程序安全稳定运行
• 解决了各个类加载器的基础类统一问题

---

9、破坏双亲委派机制

为什么要破坏双亲委派？

举个🌰： 我们常用数据库驱动Driver接口，Driver定义在JDK中，但其实现是各个数据库服务商，比如：MySQL的MYSQL CONNECROR，因此DriverManger要加载各个Driver接口实现类进行管理，但是DriverManager是由启动类加载器进行加载的，而这个启动类加载器默认值加载JDK安装目录下面的lib文件下的类库，但我们真正要加载的是各个实现类，需要有应用程序类加载器进行加载，这个时候就需要启动类加载器委托应用程序类加载器去加载Driver实现类，从而破坏了双亲委派。

破坏方式：

1. 自定义类加载，重写loadclass方法。双亲委派的机制都是通过这个方法实现的，这个方法可以指定类通过什么类加载器来进行加载，所以如果改写他的加载规则，相当于打破双亲委派机制。
2. 线程上下文类加载器： 提供父类加载器访问子类加载器的行为。
   双亲委派很好的解决了各个类加载器的基础类统一问题，基础类总是被用户代码所调用，但是如果基础类又要重新调用用户代码，此时就与双亲委派模型的设计理念相违背。
   比如：JNDI服务（JDBC/JCE/JAXB/JBI）是Java的标准服务，它的代码是由启动类加载器进行加载的，但是JNDI的作用就是进行资源的集中管理和查找，它需要调用由(服务厂商提供的实现类)开发人员在classpath下的类代码，但是启动类加载器不会进行加载。
   所以引入线程上下类加载器，通过java.lang.Thread类的setContextClassLoader()方法进行设置。如果创建线程时还未设置，它会从父线程继承一个，如果在应用程序全局范围内没有设置，那么这个线程上下类加载器就是应用程序类加载器。
3. Java热部署
   Java热部署的规范化模块是OSGi提供的，热部署实现的关键就是OSGi自定义了类加载器，它为每个模块都配了一个类加载器。当需要动态地更换一个模块的时候，就把模块连通这个模块的类加载器一起替换，从而实现了热替换。此时类加载器从树状结构变为了网状结构，有大量的层与层之间的类加载器，所以就打破了双亲委派模型。

参考文章：

• https://pdai.tech/md/java/jvm/java-jvm-classload.html
• https://blog.csdn.net/Wangxichuan_Jack/article/details/123711799
• https://blog.csdn.net/Fqzzzzz/article/details/123989751
• https://blog.csdn.net/weixin_45629285/article/details/128050932