JVM 类加载器详解

类加载器作用：

类加载器子系统作用：

1. 类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。

2. ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。

3. 加载的类信息存放于一块称为方法区的内存空间。

 

类加载器ClassLoader作用：

1. class file，可以理解为设计师画在纸上的模板，而最终这个模板在执行的时候是要加载到JVM当中来根据这个文件实例化出n个一模一样的实例。

2. class file加载到JVM中，被称为DNA元数据模板，放在方法区。

3. 在.class文件–>JVM–>最终成为元数据模板，此过程就要一个运输工具（类装载器Class Loader），扮演一个快递员的角色。

 

---

---

类加载过程：

public class HelloLoader {

    public static void main(String[] args) {

        System.out.println("谢谢ClassLoader加载我....");

        System.out.println("你的大恩大德，我下辈子再报！");

    }

}

它的加载过程是怎么样的呢?

1、执行 main() 方法（静态方法）就需要先加载承载类 HelloLoader

2、加载成功，则进行链接、初始化等操作，完成后调用 HelloLoader 类中的静态方法 main

3、加载失败则抛出异常

完整的流程图如下所示： 加载 --> 链接（验证 --> 准备 --> 解析） --> 初始化

一、加载阶段:

加载流程:

1. 通过一个类的全限定名获取定义此类的二进制字节流

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

3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

加载class文件的方式:

1. 从本地系统中直接加载

2. 通过网络获取，典型场景：Web Applet

3. 从zip压缩包中读取，成为日后jar、war格式的基础

4. 运行时计算生成，使用最多的是：动态代理技术

5. 由其他文件生成，典型场景：JSP应用从专有数据库中提取.class文件，比较少见

6. 从加密文件中获取，典型的防Class文件被反编译的保护措施

---

二、链接阶段:

链接分为三个子阶段：验证 --> 准备 --> 解析

验证(Verify)：

1. 目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全

2. 主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证。

准备(Prepare)：

1. 为类变量（static）分配内存并且设置该类变量的默认初始值

2. 这里不包含用final修饰的static，因为final在编译的时候就会分配好了默认值，准备阶段会显式初始化

3. 注意：这里不会为实例变量分配初始化

案例：

代码：变量a在准备阶段会赋初始值，但不是1，而是0，在初始化阶段会被赋值为 1

public class HelloApp {

    private static int a = 1;

    public static void main(String[] args) {

        System.out.println(a);

    }

}

解析(Resolve)：

1. 将常量池内的符号引用转换为直接引用的过程

2. 符号引用就是一组符号来描述所引用的目标。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄

在编译的时候一个每个java类都会被编译成一个class文件， 但在编译的时候虚拟机并不知道所引用类的地址，所以就用符号引用来代替，而在这个解析阶段就是为了把这个符号引用转化成为真正的地址的阶段。

String str = "abc";  编译时候没有分配内存，不知道在内存哪里所以先用符号代替，解析阶段把符号引用替换为直接引用。

---

三、初始化阶段：(重点)

1. 初始化阶段就是执行" 类构造器方法" <clinit>()</clinit> 的过程

2. 此方法不需定义，是javac编译器自动收集类中的所有 类变量的赋值动作和静态代码块中的语句合并而来 。也就是说， 当我们代码中包含static变量的时候，就会有clinit方法,  <clinit>()</clinit> 方法中的指令按语句在源文件中出现的顺序执行

3. <clinit>()</clinit>不同于类的构造器。（关联：构造器是虚拟机视角下的 <init>()</init>）

4. 若该类具有父类，JVM会保证子类的 <clinit>()</clinit> 执行前，父类的 <clinit>()</clinit> 已经执行完毕

5. 虚拟机必须保证一个类的 <clinit>()</clinit> 方法在多线程下被同步加锁

初始化案例：

当我们代码中包含static变量的时候，就会有clinit方法

1、无 static 变量：

2、有static变量：

3、构造器方法中指令按语句在源文件中出现的顺序执行

静态变量 number 的值变化过程如下

1、prepare准备阶段时：0

2、 执行静态变量初始化：10

3、 执行静态代码块：20

静态变量 number 的值变化过程如下

1、准备阶段时：0

2、执行静态代码块：20

3、执行静态变量初始化：10

4、若该类具有父类，JVM会保证子类的 <clinit>()</clinit> 执行前，父类的 <clinit>()</clinit> 已经执行完毕

加载流程如下：

1、首先，执行 main() 方法需要加载 ClinitTest5 类

2、 获取 Son.B 静态变量，需要加载 Son 类

3、Son 类的父类是 Father 类，所以需要先执行 Father 类的加载，再执行 Son 类的加载

---

---

---

类加载器的分类：

类加载器的分类

1. JVM支持两种类型的类加载器 。分别为: 1、引导类加载器（Bootstrap ClassLoader）和2、自定义类加载器（User-Defined ClassLoader）

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

3. 无论类加载器的类型如何划分，在程序中我们最常见的类加载器始终只有3个，如下所示

4. 这里的四者之间是 包含 关系，不是上层和下层，也不是子父类的继承关系。

为什么 ExtClassLoader 和 AppClassLoader 都属于自定义加载器？

规范定义： 所有派生于ClassLoader的类加载器都划分为自定义类加载器，所以ExtClassLoader和AppClassLoader也归类到自定义类加载器。

BootstrapClassLoader是用C、C++语言写的，其余都是Java写的。

双亲委派机制执行的流程：

自低而上检查类是否已经加载，首先是CumtomClassLoader自定义类加载器 有没有曾经加载过Student.class这个类 ，如果加载过直接返回，

如果没有加载过就委派给他的Parent就是AppClassLoader，看他有没有加载过这个类，如果也没有那么AppClassLoader又会

委派给ExtensionClassLoader，如果也没有就委派给最顶层的Bootstrap ClassLoader，  如果之前也没有加载过， 那么Bootstrap ClassLoader

就会尝试去JRE\lib\rt.jar或者Xbootclasspath(可以指定位置)选项指定的jar包下面有没有要加载的Student.class这个类， 如果发现了Class文件就

加载并返回，如果没有就会自顶向下委派给ExtensionClassLoader去到对应的目录看有没有对应的Class文件， 这样一直往下，最后CustomClassLoader

自定义的ClassLoader会按照findClass的方式去寻找有没有对应Class文件的字节byte数组，如果有 就直接装载到jvm中。

public  class  ClassLoaderTest {

     public  static  void  main(String[] args) {

         //获取系统类加载器

         ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();

         System.out.println(systemClassLoader); //sun.misc.Launcher$AppClassLoader@18b4aac2

         //获取其上层：扩展类加载器

         ClassLoader extClassLoader = systemClassLoader.getParent();

         System.out.println(extClassLoader); //sun.misc.Launcher$ExtClassLoader@45ee12a7

         //获取其上层：获取不到引导类加载器

         ClassLoader bootstrapClassLoader = extClassLoader.getParent();

         System.out.println(bootstrapClassLoader); //null （C、C++写的，我们拿不到）

         //对于用户自定义类来说：默认使用系统类加载器进行加载

         ClassLoader classLoader = ClassLoaderTest. class .getClassLoader();

         System.out.println(classLoader); //sun.misc.Launcher$AppClassLoader@18b4aac2

         //String类使用引导类加载器进行加载的。---> Java的核心类库都是使用引导类加载器进行加载的。

         ClassLoader classLoader1 = String. class .getClassLoader();

         System.out.println(classLoader1); //null

     }

}

sun.misc.Launcher$AppClassLoader@18b4aac2

sun.misc.Launcher$ExtClassLoader@45ee12a7

null

sun.misc.Launcher$AppClassLoader@18b4aac2

null

* 我们尝试获取引导类加载器，获取到的值为 null ，这并不代表引导类加载器不存在， 因为引导类加载器右 C/C++ 语言，我们获取不到

* 两次获取系统类加载器的值都相同：sun.misc.Launcher$AppClassLoader@18b4aac2 ，这说明系统类加载器是全局唯一的

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

1. 这个类加载使用C/C++语言实现的，嵌套在JVM内部

2. 它用来加载Java的核心库（JAVA_HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容），用于提供JVM自身需要的类

3. 并不继承自java.lang.ClassLoader，没有父加载器

4. 出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类

例如java.lang这个包，里面的类都是他负责加载的，通常这些核心类被签名，不能被替换掉。

扩展类加载器（Extension ClassLoader）

1. Java语言编写，由sun.misc.Launcher$ExtClassLoader实现

2. 派生于ClassLoader类

3. 父类加载器为启动类加载器

4. 从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录（扩展目录）下加载类库。

如果用户创建的JAR放在此目录下，也会自动由扩展类加载器加载

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

1. Java语言编写，由sun.misc.LaunchersAppClassLoader实现

2. 派生于ClassLoader类

3. 父类加载器为扩展类加载器

4. 它负责加载环境变量 classpath 或系统属性java.class.path指定路径下的类库

5. 该类是程序中默认的类加载器，一般来说，项目中自己写的类由应用程序类加载器加载

6. 通过classLoader.getSystemclassLoader()方法可以获取到该类加载器

---

双亲委派机制优势：

举例 1 ： 代码：我们自己建立一个 java.lang.String 类，写上 static 代码块

案例2： 在我们自己的 String 类中整个 main() 方法

举例 3 ： 在 java.lang 包下整个 Robot类

通过上面的例子，我们可以知道，双亲机制可以

1. 避免类的重复加载

2. 保护程序安全，防止核心API被随意篡改

    1. 自定义类：java.lang.String 没有用

    2. 自定义类：java.lang. Robot （报错：阻止创建 java.lang开头的类）