JVM-类加载过程

更新时间浏览

TIP

本文主要是介绍 JVM-类加载过程。

JVM——类的加载过程
- 附一张图方便理解，一个类的执行过程
类的加载过程，简明的来说
一、加载
二、验证
三、准备
四、解析
五、初始化
【----------------------------】
JVM——三个ClassLoader详解
ClassLoader重要方法
【----------------------------】
JVM——类加载器的双亲委派模型
类加载器双亲委派模型，如下图所示：
- 双亲委派模型的工作过程
- 好处
【----------------------------】
面试官：java双亲委派机制及作用
什么是双亲委派机制
- 类加载器的类别
- 委派机制的流程图
双亲委派机制的作用
参考文章

# JVM——类的加载过程

# 附一张图方便理解，一个类的执行过程

# 类的加载过程，简明的来说

类装饰器就是寻找类的字节码文件并构造出类在JVM内部表示的对象组件。在Java中，类装载器把一个类装入JVM中，要经过以下步骤：

1. 装载：查找和导入Class文件；
1. 链接：执行校验、准备和解析步骤，其中解析步骤是可以选择的：
2. 校验：检查载入Class文件数据的正确性；
3. 准备：给类的静态变量分配存储空间；
4. 解析：将符号引用转成直接引用；
1. 初始化：对类的静态变量、静态代码块执行初始化工作。

类装载工作由ClassLoader及其子类负责，ClassLoader是一个重要的Java执行时系统组件，它负责在运行时查找和装入Class字节码文件。JVM在运行时会产生三个ClassLoader：根装载器、ExtClassLoader（扩展类装载器）和AppClassLoader（系统类装载器）。其中，根装载器不是ClassLoader的子类，它使用C++编写，因此我们在Java中看不到它，根装载器负责装载JRE的核心类库，如JRE目标下的rt.jar、charsets.jar等。ExtClassLoader和AppClassLoader都是ClassLoader的子类。其中ExtClassLoader负责装载JRE目录ext中的JAR类包；AppClassLoader负责装载ClassPath路径下的类包。

关于这三个ClassLoader的详解博客链接 (opens new window)

# 一、加载

“加载” 是“类加载”过程的一个阶段。在加载阶段，虚拟机需要完成以下3件事情：

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

虚拟机规范的这3点要求其实并不算具体，因此虚拟机实现与具体应用的灵活度都是相当大的。

相对于类加载过程的其他阶段，一个非数组类的加载阶段（准确地说，是加载阶段中获取类的二进制字节流的动作）是开发人员可控性最强的，因为加载阶段既可以使用系统提供的引导类加载器来完成，也可以由用户自定义的类加载器区完成，开发人员可以通过定义自己的类加载器去控制字节流的获取方式（即重写一个类加载器的loadClass()方法）。

对于数组类而言，数组类本身不通过类加载器创建，它是由Java虚拟机直接创建的。但数组类与类加载器任然有很密切的关系，因为数组类的元素类型最终是要靠类加载器去创建。

加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，方法区中的数据存储格式由虚拟机实现自行定义，虚拟机规范未规定此区域的具体数据结构。然后在内存中实例化一个java.lang.Class类的对象（并没有明确规定是在Java堆中，对于HotSpot虚拟机而言，Class对象比较特殊，它虽然是对象，但是存放在方法区里面），这个对象将作为程序访问方法区中的这些类型数据的外部接口。

加载阶段与连接阶段的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。

# 二、验证

验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

Java语言本身是相对安全的语言，使用纯粹的Java代码无法做到注入访问数组边界意外的数据、将一个对象转型为它并未实现的类型、跳转到不存在的代码行之类的事情，如果这样做了，编译器将拒绝编译。

但前面已经说过，Class文件并不一定要求用Java源码编译而来，可以使用任何途径产生，甚至包括用十六进制编辑器直接编写来产生Class文件。在字节码语言层面上，上述Java代码无法做到的事情都是可以实现的，至少语义上是可以表达出来的。

虚拟机如果不检查输入的字节流，对其完全信任的话，很可能会因为载入了有害的字节流而导致系统崩溃，所以验证是虚拟机对自身保护的一项重要工作。

# 三、准备

准备阶段是正式为类变量分配内存并设置类变量初始值得阶段，这些变量所使用的内存都讲在方法区中进行分配。这时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。其次，这里所说的初始值“通常情况”下是数据类型的零值，假设一个类变量的定义为：

public static int value = 123;

那变量value在准备阶段过后的初始值为0而不是123，因为这时候尚未开始执行任何Java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器<clinit>()方法之中，所以把value赋值为123的动作将在初始化阶段才会执行。

# 四、解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。

# 五、初始化

类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的Java程序代码（或者说是字节码）。

在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度来表达：初始化阶段是执行类构造器<clinit()>方法的过程。

# 【----------------------------】

# JVM——三个ClassLoader详解

启动类加载器（Bootstrap ClassLoader）：这个类加载器负责将存放在<JAVA_HOME>\lib目录中的。启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null代替即可。
扩展类加载器（Extension ClassLoader）：这个加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
应用程序类加载器（Application ClassLoader）：这个类加载器由sun.misc.Launcher$AppClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义自己的类加载器，一般情况下这个就是程序中默认的类加载器。

我们的应用程序都是由这3种类加载器互相配合进行加载的，如果有必要，还可以加入自己定义的类加载器。这些类加载器之间的关系一般为：

上图展示的类加载器之间的这种层次关系，称为类加载器的双亲委派模型。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承的关系来实现，而是都使用组合关系来复用父加载器的代码。

类加载器的双亲委派模型详解博客链接 (opens new window)

这三个类装载器之间存在父子层级关系，即根装载器是ExtClassLoader的父装载器，ExtClassLoader是父类装载器。默认情况下，使用AppClassLoader装载应用程序的类，用以下代码证明：

 1 /**
 2  * @author zhengbinMac
 3  */
 4 public class ClassLoaderTest {
 5 
 6     public static void main(String[] args) {
 7         ClassLoader loader = Thread.currentThread().getContextClassLoader();
 8         System.out.println("current loader:" + loader);
 9         System.out.println("parent loader:" + loader.getParent());
10         System.out.println("grandparent loader:" + loader.getParent().getParent());
11     }
12     /*
13      * output:
14      *    current loader:sun.misc.Launcher$AppClassLoader@1b6d3586
15      *    parent loader:sun.misc.Launcher$ExtClassLoader@1540e19d 
16      *    grandparent loader:null // 因为根类装载器在Java中访问不到，所有返回null
17      */
18 }

Thread.currentThread():返回对当前正在执行的线程对象的引用。

getContextClassLoader():返回该线程的上下文 ClassLoader。

通过以上的输出信息，可以明白，ClassLoader是AppClassLoader，父ClassLoader是ExtClassLoader，祖父ClassLoader是根类装载器，因为在Java中无法获得它的句柄，所以直接返回null。

除了JVM默认的三个ClassLoader以外，可以编写自己的第三方类装载器，以实现一些特殊的需求。类文件被装载并解析后，在JVM内将拥有一个对应的java.lang.Class类描述对象，该类的实例都拥有指向这个类描述对象的引用，而类描述对象又拥有指向关联ClassLoader的引用。如下图所示：

# ClassLoader重要方法

在Java中，ClassLoader是一个抽象类，位于java.lang包中。下面对该类的一些重要接口方法进行介绍：

Class loadClass(String name)

name参数指定类装载器需要装载类的名字，必须使用全限定类名，如com.zhengbin.entity.Student。该方法有一个重载方法loadClass(String name, boolean resolve)，resolve参数告诉类装载器是否需要解析该类。在初始化类之前，应考虑进行类解析的工作，但并不是所有的类都需要解析，如果JVM只需要知道该类是否存在或找出该类的超类，那么就不需要进行解析。

Class defineClass(String name, byte[] b, int off, int len)

将类文件的字节数组转换成JVM内部的java.lang.Class对象。字节数组可以从本地文件系统、远程网络获取。name为字节数组对应的全限定类名。

Class findSystemClass(String name)

从本地文件系统载入Class文件，如果本地文件系统不存在该Class文件，将抛出ClassNotFoundException异常。该方法是JVM默认使用的装载机制。

ClassLoader getParent()

获取类装载器的父装载器，除根装载器外，所有的类装载器都有且仅有一个父装载器，ExtClassLoader的父装载器是根装载器，因为根装载器非Java编写，所以无法获得，将返回null。

# 【----------------------------】

# JVM——类加载器的双亲委派模型

# 类加载器双亲委派模型，如下图所示：

# 双亲委派模型的工作过程

如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。

# 好处

使用双亲委派模型来组织类加载器之间的关系，有一个显而易见得好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写一个称谓java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。

# 【----------------------------】

# 面试官：java双亲委派机制及作用

# 什么是双亲委派机制

当某个类加载器需要加载某个.class文件时，它首先把这个任务委托给他的上级类加载器，递归这个操作，如果上级的类加载器没有加载，自己才会去加载这个类。

# 类加载器的类别

# BootstrapClassLoader（启动类加载器）

c++编写，加载java核心库 java.*,构造ExtClassLoader和AppClassLoader。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作

# ExtClassLoader （标准扩展类加载器）

java编写，加载扩展库，如classpath中的jre ，javax.*或者 java.ext.dir 指定位置中的类，开发者可以直接使用标准扩展类加载器。

# AppClassLoader（系统类加载器）

java`编写，加载程序所在的目录，如`user.dir`所在的位置的`class

# CustomClassLoader（用户自定义类加载器）

java编写,用户自定义的类加载器,可加载指定路径的class文件

# 源码分析

protected Class<?> loadClass(String name, boolean resolve)
            throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // 首先检查这个classsh是否已经加载过了
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    // c==null表示没有加载，如果有父类的加载器则让父类加载器加载
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        //如果父类的加载器为空 则说明递归到bootStrapClassloader了
                        //bootStrapClassloader比较特殊无法通过get获取
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {}
                if (c == null) {
                    //如果bootstrapClassLoader 仍然没有加载过，则递归回来，尝试自己去加载class
                    long t1 = System.nanoTime();
                    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;
        }
    }

# 委派机制的流程图

image.png

# 双亲委派机制的作用

1、防止重复加载同一个.class。通过委托去向上面问一问，加载过了，就不用再加载一遍。保证数据安全。
2、保证核心.class不能被篡改。通过委托方式，不会去篡改核心.clas，即使篡改也不会去加载，即使加载也不会是同一个.class对象了。不同的加载器加载同一个.class也不是同一个Class对象。这样保证了Class执行安全。

# 参考文章

https://www.cnblogs.com/zhengbin/p/5631363.html#autoid-0-1-0
https://www.cnblogs.com/zhengbin/p/5631987.html
https://www.cnblogs.com/zhengbin/p/5632691.html
https://www.jianshu.com/p/1e4011617650

← JVM-类加载机制 JVM-类加载器区别 →

# JVM——类的加载过程

# 附一张图方便理解，一个类的执行过程

# 类的加载过程，简明的来说

# 一、加载

# 二、验证

# 三、准备

# 四、解析

# 五、初始化

# 【----------------------------】

# JVM——三个ClassLoader详解

# ClassLoader重要方法

# 【----------------------------】

# JVM——类加载器的双亲委派模型

# 类加载器双亲委派模型，如下图所示：

# 双亲委派模型的工作过程

# 好处

# 【----------------------------】

# 面试官：java双亲委派机制及作用

# 什么是双亲委派机制

# 类加载器的类别

# BootstrapClassLoader（启动类加载器）

# ExtClassLoader （标准扩展类加载器）

# AppClassLoader（系统类加载器）

# CustomClassLoader（用户自定义类加载器）

# 源码分析

# 委派机制的流程图

# 双亲委派机制的作用

# 参考文章

可分享给好友和朋友圈

公众号:智能后端和架构

PS 备注:智能后端和架构