JVM理解（上）：classloader加载class文件的原理和机制

Posted 2021-03-03 haojile

转自：https://www.jianshu.com/p/52c38cf2e3d4

JVM理解（上）：classloader加载class文件的原理和机制

安东尼_Anthony关注

12018.11.10 10:16:40字数 4,361阅读 3,731

1 JVM架构整体架构

在进入classloader分析之前，先了解一下jvm整体架构：

 

JVM架构

JVM被分为三个主要的子系统

（1）类加载器子系统（2）运行时数据区（3）执行引擎

1. 类加载器子系统

 

Java的动态类加载功能是由类加载器子系统处理。当它在运行时（不是编译时）首次引用一个类时，它加载、链接并初始化该类文件。

1.1 加载：类由此组件加载。启动类加载器 (BootStrap class Loader)、扩展类加载器(Extension class Loader)和应用程序类加载器(Application class Loader) 这三种类加载器帮助完成类的加载。1. 启动类加载器 – 负责从启动类路径中加载类，无非就是rt.jar。这个加载器会被赋予最高优先级。2. 扩展类加载器 – 负责加载ext 目录(jrelib)内的类.3. 应用程序类加载器 – 负责加载应用程序级别类路径，涉及到路径的环境变量等etc.上述的类加载器会遵循委托层次算法（Delegation Hierarchy Algorithm）加载类文件，这个在后面进行讲解。

加载过程主要完成三件事情：

• 通过类的全限定名来获取定义此类的二进制字节流

• 将这个类字节流代表的静态存储结构转为方法区的运行时数据结构

• 在堆中生成一个代表此类的java.lang.Class对象，作为访问方法区这些数据结构的入口。

1.2 链接：

1. 校验 字节码校验器会校验生成的字节码是否正确，如果校验失败，我们会得到校验错误。

文件格式验证：基于字节流验证，验证字节流符合当前的Class文件格式的规范，能被当前虚拟机处理。验证通过后，字节流才会进入内存的方法区进行存储。

元数据验证：基于方法区的存储结构验证，对字节码进行语义验证，确保不存在不符合java语言规范的元数据信息。

字节码验证：基于方法区的存储结构验证，通过对数据流和控制流的分析，保证被检验类的方法在运行时不会做出危害虚拟机的动作。

符号引用验证：基于方法区的存储结构验证，发生在解析阶段，确保能够将符号引用成功的解析为直接引用，其目的是确保解析动作正常执行。换句话说就是对类自身以外的信息进行匹配性校验。

2. 准备 – 分配内存并初始化默认值给所有的静态变量。

public static int value=33;

这据代码的赋值过程分两次，一是上面我们提到的阶段，此时的value将会被赋值为0；而value=33这个过程发生在类构造器的<clinit>()方法中。

3. 解析所有符号内存引用被方法区(Method Area)的原始引用所替代。

举个例子来说明，在com.sbbic.Person类中引用了com.sbbic.Animal类，在编译阶段，Person类并不知道Animal的实际内存地址，因此只能用com.sbbic.Animal来代表Animal真实的内存地址。在解析阶段，JVM可以通过解析该符号引用，来确定com.sbbic.Animal类的真实内存地址（如果该类未被加载过，则先加载）。

主要有以下四种：类或接口的解析，字段解析，类方法解析，接口方法解析

1.3 初始化：这是类加载的最后阶段，这里所有的静态变量会被赋初始值, 并且静态块将被执行。

java中，对于初始化阶段，有且只有**以下五种情况才会对要求类立刻初始化：

• 使用new关键字实例化对象、访问或者设置一个类的静态字段（被final修饰、编译器优化时已经放入常量池的例外）、调用类方法，都会初始化该静态字段或者静态方法所在的类；

• 初始化类的时候，如果其父类没有被初始化过，则要先触发其父类初始化；

• 使用java.lang.reflect包的方法进行反射调用的时候，如果类没有被初始化，则要先初始化；

• 虚拟机启动时，用户会先初始化要执行的主类（含有main）；

• jdk 1.7后，如果java.lang.invoke.MethodHandle的实例最后对应的解析结果是 REF_getStatic、REF_putStatic、REF_invokeStatic方法句柄，并且这个方法所在类没有初始化，则先初始化；

2.运行时数据区（Runtime Data Area）

The 运行时数据区域被划分为5个主要组件：

① 方法区 (线程共享) 常量 静态变量 JIT(即时编译器)编译后代码也在方法区存放

② 堆内存(线程共享) 垃圾回收的主要场地

③ 程序计数器 当前线程执行的字节码的位置指示器

④ Java虚拟机栈(栈内存) :保存局部变量,基本数据类型以及堆内存中对象的引用变量

⑤ 本地方法栈 (C栈):为JVM提供使用native方法的服务

 

3. 执行引擎

分配给运行时数据区的字节码将由执行引擎执行。执行引擎读取字节码并逐段执行。3.1 解释器: 解释器能快速的解释字节码，但执行却很慢。 解释器的缺点就是,当一个方法被调用多次，每次都需要重新解释。

3.2 编译器：JIT编译器消除了解释器的缺点。执行引擎利用解释器转换字节码，但如果是重复的代码则使用JIT编译器将全部字节码编译成本机代码。本机代码将直接用于重复的方法调用，这提高了系统的性能。a. 中间代码生成器– 生成中间代码b. 代码优化器– 负责优化上面生成的中间代码c. 目标代码生成器– 负责生成机器代码或本机代码d. 探测器(Profiler) – 一个特殊的组件，负责寻找被多次调用的方法。

3.3 垃圾回收器: 收集并删除未引用的对象。可以通过调用"System.gc()"来触发垃圾回收，但并不保证会确实进行垃圾回收。JVM的垃圾回收只收集哪些由new关键字创建的对象。所以，如果不是用new创建的对象，你可以使用finalize函数来执行清理。Java本地接口 (JNI): JNI会与本地方法库进行交互并提供执行引擎所需的本地库。本地方法库:它是一个执行引擎所需的本地库的集合。

下面，通过一个小程序认识JVM：

package com.spark.jvm;

/**

* 从JVM调用的角度分析java程序堆内存空间的使用：

* 当JVM进程启动的时候，会从类加载路径中找到包含main方法的入口类HelloJVM

* 找到HelloJVM会直接读取该文件中的二进制数据，并且把该类的信息放到运行时的Method内存区域中。

* 然后会定位到HelloJVM中的main方法的字节码中，并开始执行Main方法中的指令

* 此时会创建Student实例对象，并且使用student来引用该对象（或者说给该对象命名），其内幕如下：

* 第一步：JVM会直接到Method区域中去查找Student类的信息，此时发现没有Student类，就通过类加载器加载该Student类文件；

* 第二步：在JVM的Method区域中加载并找到了Student类之后会在Heap区域中为Student实例对象分配内存，

* 并且在Student的实例对象中持有指向方法区域中的Student类的引用（内存地址）；

* 第三步：JVM实例化完成后会在当前线程中为Stack中的reference建立实际的应用关系，此时会赋值给student

* 接下来就是调用方法

* 在JVM中方法的调用一定是属于线程的行为，也就是说方法调用本身会发生在线程的方法调用栈：

* 线程的方法调用栈（Method Stack Frames），每一个方法的调用就是方法调用栈中的一个Frame，

* 该Frame包含了方法的参数，局部变量，临时数据等 student.sayHello();

 */

public class HelloJVM {

 //在JVM运行的时候会通过反射的方式到Method区域找到入口方法main

 public static void main(String[] args) {//main方法也是放在Method方法区域中的

 /**

 * student(小写的)是放在主线程中的Stack区域中的

 * Student对象实例是放在所有线程共享的Heap区域中的

 */

 Student student = new Student("spark");

 /**

 * 首先会通过student指针（或句柄）（指针就直接指向堆中的对象，句柄表明有一个中间的,student指向句柄，句柄指向对象）

 * 找Student对象，当找到该对象后会通过对象内部指向方法区域中的指针来调用具体的方法去执行任务

 */

 student.sayHello();

 }

}

class Student {

 // name本身作为成员是放在stack区域的但是name指向的String对象是放在Heap中

 private String name;

 public Student(String name) {

 this.name = name;

 }

 //sayHello这个方法是放在方法区中的

 public void sayHello() {

 System.out.println("Hello, this is " + this.name);

 }

}

classloader加载class文件的原理和机制

下面部分内容，整理自《深入分析JavaWeb技术内幕》

Classloader负责将Class加载到JVM中，并且确定由那个ClassLoader来加载（父优先的等级加载机制）。还有一个任务就是将Class字节码重新解释为JVM统一要求的格式

1.Classloader 类结构分析

(1) 主要由四个方法，分别是 defineClass ， findClass ， loadClass ， resolveClass

• <1>defineClass(byte[] , int ,int) 将byte字节流解析为JVM能够识别的Class对象（直接调用这个方法生成的Class对象还没有resolve，这个resolve将会在这个对象真正实例化时resolve）
• <2>findClass，通过类名去加载对应的Class对象。当我们实现自定义的classLoader通常是重写这个方法，根据传入的类名找到对应字节码的文件，并通过调用defineClass解析出Class独享
• <3>loadClass运行时可以通过调用此方法加载一个类（由于类是动态加载进jvm，用多少加载多少的？）
• <4>resolveClass手动调用这个使得被加到JVM的类被链接（解析resolve这个类？）

(2) 实现自定义 ClassLoader 一般会继承 URLClassLoader 类，因为这个类实现了大部分方法。

2. 常见加载类错误分析

(1)ClassNotFoundException ：

通常是jvm要加载一个文件的字节码到内存时，没有找到这些字节码(如forName，loadClass等方法)

(2)NoClassDefFoundError ：

通常是使用new关键字，属性引用了某个类，继承了某个类或接口，但JVM加载这些类时发现这些类不存在的异常

(3)UnsatisfiedLinkErrpr:

如native的方法找不到本机的lib

3. 常用 classLoader （书本此处其实是对 tomcat 加载 servlet 使用的 classLoader 分析）

(1)AppClassLoader ：

加载jvm的classpath中的类和tomcat的核心类

(2)StandardClassLoader:

加载tomcat容器的classLoader，另外webAppClassLoader在loadclass时，发现类不在JVM的classPath下，在PackageTriggers(是一个字符串数组，包含一组不能使用webAppClassLoader加载的类的包名字符串)下的话，将由该加载器加载(注意：StandardClassLoader并没有覆盖loadclass方法，所以其加载的类和AppClassLoader加载没什么分别，并且使用getClassLoader返回的也是AppClassLoader)(另外，如果web应用直接放在tomcat的webapp目录下该应用就会通过StandardClassLoader加载，估计是因为webapp目录在PackageTriggers中？)

(3)webAppClassLoader 如：

Servlet等web应用中的类的加载（loadclass方法的规则详见P169）

4. 自定义的 classloader

(1) 需要使用自定义 classloader 的情况

• <1>不在System.getProperty("java.class.path")中的类文件不可以被AppClassLoader找到（LoaderClass方法只会去classpath下加载特定类名的类），当class文件的字节码不在ClassPath就需要自定义classloader
• <2>对加载的某些类需要作特殊处理
• <3>定义类的实效机制，对已经修改的类重新加载，实现热部署

(2) 加载自定义路径中的 class 文件

• <1>加载特定来源的某些类：重写find方法，使特定类或者特定来源的字节码 通过defineClass获得class类并返回(应该符合jvm的类加载规范，其他类仍使用父加载器加载)
• <2>加载自顶一个是的class文件(如经过网络传来的经过加密的class文件字节码)：findclass中加密后再加载

5. 实现类的热部署：

• (1)同一个classLoader的两个实例加载同一个类，JVM也会识别为两个
• (2)不能重复加载同一个类（全名相同，并使用同一个类加载器），会报错
• (3)不应该动态加载类，因为对象呗引用后，对象的属性结构被修改会引发问题

注意：使用不同classLoader加载的同一个类文件得到的类，JVM将当作是两个不同类，使用单例模式，强制类型转换时都可能因为这个原因出问题。

6 类加载器的双亲委派模型

当一个类加载器收到一个类加载的请求，它首先会将该请求委派给父类加载器去加载，每一个层次的类加载器都是如此，因此所有的类加载请求最终都应该被传入到顶层的启动类加载器(Bootstrap ClassLoader)中，只有当父类加载器反馈无法完成这个列的加载请求时（它的搜索范围内不存在这个类），子类加载器才尝试加载。其层次结构示意图如下：

 

不难发现,该种加载流程的好处在于：

可以避免重复加载，父类已经加载了，子类就不需要再次加载

更加安全，很好的解决了各个类加载器的基础类的统一问题，如果不使用该种方式，那么用户可以随意定义类加载器来加载核心api，会带来相关隐患。

接下来,我们看看双亲委派模型是如何实现的：

 protected Class<?> loadClass(String name, boolean resolve)

 throws ClassNotFoundException

 {

 synchronized (getClassLoadingLock(name)) {

 // 首先先检查该类已经被加载过了

 Class c = findLoadedClass(name);

 if (c == null) {//该类没有加载过，交给父类加载

 long t0 = System.nanoTime();

 try {

 if (parent != null) {//交给父类加载

 c = parent.loadClass(name, false);

 } else {//父类不存在，则交给启动类加载器加载

 c = findBootstrapClassOrNull(name);

 }

 } catch (ClassNotFoundException e) {

 //父类加载器抛出异常，无法完成类加载请求

 }

 if (c == null) {//

 long t1 = System.nanoTime();

 //父类加载器无法完成类加载请求时，调用自身的findClass方法来完成类加载

 c = findClass(name);

 sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);

 sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);

 sun.misc.PerfCounter.getFindClasses().increment();

 }

 }

 if (resolve) {

 resolveClass(c);

 }

 return c;

 }

 }

这里有些童鞋会问,JVM怎么知道一个某个类加载器的父加载器呢?如果你有此疑问,请重新再看一遍.

7 类加载器的特点

运行任何一个程序时，总是由Application Loader开始加载指定的类。

一个类在收到加载类请求时，总是先交给其父类尝试加载。

Bootstrap Loader是最顶级的类加载器，其父加载器为null。

8 类加载的三种方式

通过命令行启动应用时由JVM初始化加载含有main()方法的主类。

通过Class.forName()方法动态加载，会默认执行初始化块（static{}），但是Class.forName(name,initialize,loader)中的initialze可指定是否要执行初始化块。

通过ClassLoader.loadClass()方法动态加载，不会执行初始化块。

9 自定义类加载器的两种方式

1、遵守双亲委派模型：继承ClassLoader，重写findClass()方法。 2、破坏双亲委派模型：继承ClassLoader,重写loadClass()方法。 通常我们推荐采用第一种方法自定义类加载器，最大程度上的遵守双亲委派模型。 自定义类加载的目的是想要手动控制类的加载,那除了通过自定义的类加载器来手动加载类这种方式,还有其他的方式么?

利用现成的类加载器进行加载:

1. 利用当前类加载器

Class.forName();

2. 通过系统类加载器

Classloader.getSystemClassLoader().loadClass();

3. 通过上下文类加载器

Thread.currentThread().getContextClassLoader().loadClass();

l 利用URLClassLoader进行加载:

URLClassLoader loader=new URLClassLoader();

loader.loadClass();

类加载实例演示： 命令行下执行HelloWorld.java

public class HelloWorld{

 public static void main(String[] args){

 System.out.println("Hello world");

 }

}

该段代码大体经过了一下步骤:

• 寻找jre目录，寻找jvm.dll，并初始化JVM.

• 产生一个Bootstrap ClassLoader；

• Bootstrap ClassLoader加载器会加载他指定路径下的java核心api，并且生成Extended ClassLoader加载器的实例，然后Extended ClassLoader会加载指定路径下的扩展java api，并将其父设置为Bootstrap ClassLoader。

• Bootstrap ClassLoader生成Application ClassLoader，并将其父Loader设置为Extended ClassLoader。

• 最后由AppClass ClassLoader加载classpath目录下定义的类——HelloWorld类。

我们上面谈到 Extended ClassLoader和Application ClassLoader是通过Launcher来创建,现在我们再看看源代码:

 public Launcher() {

 Launcher.ExtClassLoader var1;

 try {

 //实例化ExtClassLoader

 var1 = Launcher.ExtClassLoader.getExtClassLoader();

 } catch (IOException var10) {

 throw new InternalError("Could not create extension class loader", var10);

 }

 try {

 //实例化AppClassLoader

 this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);

 } catch (IOException var9) {

 throw new InternalError("Could not create application class loader", var9);

 }

 //主线程设置默认的Context ClassLoader为AppClassLoader.

 //因此在主线程中创建的子线程的Context ClassLoader 也是AppClassLoader

 Thread.currentThread().setContextClassLoader(this.loader);

 String var2 = System.getProperty("java.security.manager");

 if(var2 != null) {

 SecurityManager var3 = null;

 if(!"".equals(var2) && !"default".equals(var2)) {

 try {

 var3 = (SecurityManager)this.loader.loadClass(var2).newInstance();

 } catch (IllegalAccessException var5) {

 ;

 } catch (InstantiationException var6) {

 ;

 } catch (ClassNotFoundException var7) {

 ;

 } catch (ClassCastException var8) {

 ;

 }

 } else {

 var3 = new SecurityManager();

 }

 if(var3 == null) {

 throw new InternalError("Could not create SecurityManager: " + var2);

 }

 System.setSecurityManager(var3);

 }

 }

10 非常重要

在这里呢我们需要注意几个问题:
1. 我们知道ClassLoader通过一个类的全限定名来获取二进制流,那么如果我们需要通过自定义类加载其来加载一个Jar包的时候,难道要自己遍历jar中的类,然后依次通过ClassLoader进行加载吗?或者说我们怎么来加载一个jar包呢?
2. 如果一个类引用的其他的类,那么这个其他的类由谁来加载?
3. 既然类可以由不同的加载器加载,那么如何确定两个类如何是同一个类?

我们来依次解答这两个问题: 对于动态加载jar而言,JVM默认会使用第一次加载该jar中指定类的类加载器作为默认的ClassLoader.假设我们现在存在名为sbbic的jar包,该包中存在ClassA和ClassB这两个类(ClassA中没有引用ClassB).现在我们通过自定义的ClassLoaderA来加载在ClassA这个类,那么此时此时ClassLoaderA就成为sbbic.jar中其他类的默认类加载器.也就是,ClassB也默认会通过ClassLoaderA去加载.

那么如果ClassA中引用了ClassB呢?当类加载器在加载ClassA的时候,发现引用了ClassB,此时类加载如果检测到ClassB还没有被加载,则先回去加载.当ClassB加载完成后,继续回来加载ClassA.换句话说,类会通过自身对应的来加载其加载其他引用的类.

JVM规定,对于任何一个类,都需要由加载它的类加载器和这个类本身一同确立在java虚拟机中的唯一性,通俗点就是说,在jvm中判断两个类是否是同一个类取决于类加载和类本身,也就是同一个类加载器加载的同一份Class文件生成的Class对象才是相同的,类加载器不同,那么这两个类一定不相同.