虚拟机类加载机制

1. 概述

Java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这个过程被称作虚拟机的类加载机制。

2. 类加载过程

类加载过程

加载 >> 验证 >> 准备 >> 解析 >> 初始化 >> 使用 >> 卸载

加载：在硬盘上查找并通过IO读入字节码文件，使用到类时才会加载，例如调用 类的main()方法，new对象等等

验证：校验字节码文件的正确性 准备：给类的静态变量分配内存，并赋予默认值

解析：将符号引用替换为直接引用，该阶段会把一些静态方法(符号引用，比如main()方法)替换为指向数据所存内存的指针或句柄等(直接引用)，这是所谓的静态链接过程(类加载期间完成)，动态链接是在程序运行期间完成的将符号引用替换为直接引用

初始化：对类的静态变量初始化为指定的值，执行静态代码块

2.1 初始化的几种情况

下面六种情况规定必须立即对类进行“初始化”

• 实例化对象、读取一个类的静态字段、设置一个类的静态字段、调用一个类的静态字段
• 使用反射时，如果未初始化，立即初始化
• 初始化一个类时，如果父类未被初始化，需要先初始化父类
• 虚拟机启动时，会先初始化包含main()方法的那个类
• 当使用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化。则需要先触发其初始化。
• 当一个接口中定义了JDK 8新加入的默认方法（被default关键字修饰的接口方法）时，如果有 这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

注：java.lang.invoke.MethodHandle是JDK7新增的反射

3. Java中类加载的种类

• 启动类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如 rt.jar、charsets.jar等
• 扩展类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中 的JAR类包
• 应用程序类加载器：负责加载ClassPath路径下的类包，主要就是加载你自己写的那些类
• 自定义加载器：负责加载用户自定义路径下的类包

4. 自定义一个类加载器

首先继承java.lang.ClassLoader类，如果不打破双亲委派机制，就重写findClass方法；如果需要打破该机制，就再重写loadClass方法。

5. 双亲委派机制

image

基本原理：加载某个类时会先委托父加载器寻找目标类，找不到再委托上层父加载器加载，如果所有父加载器在自己的加载类路径下都找不到目标类，则 在自己的类加载路径中查找并载入目标类。

代码逻辑：

• 首先，检查一下指定名称的类是否已经加载过，如果加载过了，就不需要再加载， 直接返回。
• 如果此类没有加载过，那么，再判断一下是否有父加载器；如果有父加载器，则由父加载器加载（即调用parent.loadClass(name, false);）.或者是调用bootstrap类加 载器来加载。
• 如果父加载器及bootstrap类加载器都没有找到指定的类，那么调用当前类加载器 的findClass方法来完成类加载。

5.1 目的

• 沙箱安全机制：自己写的java.lang.String.class类不会被加载，这样便可以防止核心API库被随意篡改
• 避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次，保证被加载类的唯一性

5.2 打破双亲委派机制

重写loadClass方法，去掉其中找父加载器加载的部分

5.3 Tomcat打破双亲委派机制

Tomcat 如果使用默认的双亲委派类加载机制行不行？ 我们思考一下：Tomcat是个web容器， 那么它要解决什么问题：

(1). 一个web容器可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的 类库都是独立的，保证相互隔离。

(2). 部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程序，那么要有10份相同的类库加载进虚拟机。

(3). web容器也有自己依赖的类库，不能与应用程序的类库混淆。

(4). web容器要支持jsp的修改，我们知道，jsp 文件最终也是要编译成class文件才能在虚拟 机中运行，但程序运行后修改jsp已经是司空见惯的事情， web容器需要支持 jsp 修改后不 用重启。

第一个问题，如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认的类加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。

第二个问题，默认的类加载器是能够实现的，因为他的职责就是保证唯一性。

第三个问题和第一个问题一样。

我们再看第四个问题，我们想我们要怎么实现jsp文件的热加载，jsp文件其实也就是class文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后 的jsp是不会重新加载的。那么怎么办呢？我们可以直接卸载掉这jsp文件的类加载器，所以你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载 这个jsp类加载器。重新创建类加载器，重新加载jsp文件。

5.4 Tomcat自定义加载器详解

image

tomcat的几个主要类加载器：

• commonLoader：Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容 器本身以及各个Webapp访问；
• catalinaLoader：Tomcat容器私有的类加载器，加载路径中的class对于Webapp不 可见；
• sharedLoader：各个Webapp共享的类加载器，加载路径中的class对于所有 Webapp可见，但是对于Tomcat容器不可见；
• WebappClassLoader：各个Webapp私有的类加载器，加载路径中的class只对当前 Webapp可见，比如加载war包里相关的类，每个war包应用都有自己的
  WebappClassLoader，实现相互隔离，比如不同war包应用引入了不同的spring版本， 这样实现就能加载各自的spring版本；

从图中的委派关系中可以看出： CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用， 从而实现了公有类库的共用，而CatalinaClassLoader和SharedClassLoader自己能加载的类则 与对方相互隔离。

WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader 实例之间相互隔离。

而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的目的 就是为了被丢弃：当Web容器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例， 并通过再建立一个新的Jsp类加载器来实现JSP文件的热加载功能。