类加载机制、双亲委派机制深度解析以及如何自定义类加载器

文章目录

1.类加载运行的全过程
2. JVM类加载器的初始化
3.双亲委派机制
4.编写自定义类加载器
5.（Tomcat）如何打破双亲委派机制

当我们运行一个类的时候，首先要通过类加载机制把类加载到JVM中

1.类加载运行的全过程

从JVM创建到类被加载的步骤：

①：c++程序先创建java虚拟机
②：c++程序创建引导类加载器
③：c++创建JVM启动器 Launcher 实例
④：在Launcher实例中获取其他类加载器（扩展、应用类加载器）
⑤：通过双亲委派机制，决定哪个类加载器加载
⑥：找到合适的类加载器后，通过loadClass的类加载过程：加载 >> 验证 >> 准备 >> 解析 >> 初始化等步骤把类加载到JVM

类加载步骤详解：

加载：从硬盘上读取字节码文件，使用到的时候才会加载
验证：检验字节码文件的正确性
准备：给类的静态变量分配内存，并赋一个默认值（0，null等）
解析：将符号引用转换为直接引用。在类加载时属于静态链接的过程，与之对应的还有一个动态链接
- 符号引用：一个 java 文件会编译成一个class文件。class文件中的每个方法、属性等内容都可以被视为一个符号，存储在constant pool静态常量池中，在准备阶段之前，由于没有在jvm中为其分配堆栈内存，所以没有具体的引用地址，因此只能使用符号引用来代替。
- 直接引用：在准备阶段之后，由于class被加载到方法区中，constant pool静态常量池变为运行时常量池！同时该class中的属性和方法都已经分配好内存。有具体指针指向该块内存取域，被称为直接引用。所以在解析阶段会把之前的符号引用都转换成直接引用！
- 静态链接：在类加载过程中，只会把静态方法的符号引用转换为直接引用，而一些非静态的方法在此时不会转换。因为该阶段只是加载，并没有运行，只有在运行时才会把非静态方法的符号引用转换为直接引用。
- 动态链接：在程序运行时，且执行到某个非静态方法时，才会把该方法的符号引用转换为直接引用，这个过程被称为动态链接！
初始化：对类的静态变量初始化为指定的值，此时会执行静态代码块，修改准备阶段时静态变量的默认值为初始值

1.1 java程序运行的时候是不是一开始就把所有的类加载到内存？

不会。 Java程序启动时，并不是一次把所有的类全部加载后再运行，它总是先把保证程序运行的基础类一次性加载到jvm中，其它类等到jvm用到的时候再加载。如果一开始就把所有的、用不到的类加载到jvm中，势必会占用很多宝贵的内存空间，而有些class可能在整个运行过程中都不会使用。

new User() 由于使用到了User类，因此会加载User类，执行静态代码块和构造器
User user = null 只是定义一下User类，并没有使用，因此不会加载User类，也不会执行静态代码块和构造器

2. JVM类加载器的初始化

类的加载主要通过类加载器来实现，java中有以下几种类加载器

2.1 类加载器分类

①：引导类加载器：负责加载JVM运行的位于jre/lib目录下的核心库（String类等），比如rt.jar等
②：扩展类加载器：负责加载JVM运行的位于jre/ext/lib目录下jar包
③：应用类加载器：负责加载ClassPath路径下的类包，主要是加载你自己写的那些类
④：自定义类加载器：负责加载用户自定义路径下的类包

2.2类加载器初始化过程

1）类加载器由jvm启动器实例Launcher所创建。 Launcher初始化使用了单例模式设计，保证一个JVM虚拟机内只有一个sun.misc.Launcher实例。
2）在Launcher构造方法内部，其创建了两个类加载器，分别是 sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)。
3）JVM默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们的应用程序

类加载器初始化过程源码：

3.双亲委派机制

双亲委派机制：说简单点就是，先找父亲加载，不行再由儿子自己加载

比如我们自己写的User类，会遵循以下的加载步骤：

加载时会先找到 应用类加载器进行加载，应用类加载器会把这个加载请求委托给父亲扩展类加载器，扩展类加载器再委托给引导类加载器。
引导类加载器在自己的类加载路径里找了半天没找到User类，则向下退回User的加载请求
扩展类加载器收到回复就自己加载，在自己的类加载路径里找了半天也没找到User类，又向下退回Math类的加载请求给应用程序类加载器
应用程序类加载器于是在自己的类加载路径里找User类，结果找到了就自己加载了。。

问题一：为什么会先由应用程序类加载器加载类？为什么不直接由启动类加载器加载，而是选择从下往上，往返两次？

首先从源码层面看一下为什么先由应用程序类加载器加载类：源码中首先把程序类加载器赋值给了this.loader，说明第一个使用的就是程序类加载器！

问题二：那么为什么要往返两次，直接由启动类加载器加载岂不是更省事?

答：在生产应用中，95%的类其实都是由应用类加载器加载的，如果类已经被加载过一次，就会被保存在应用类加载器中，下次使用可直接从应用类加载器中获取。

但是如果由启动类加载器加载，大部分的类的获取都要走一个启动类加载器 >> 扩展类加载器 >> 应用类加载器的过程，下次使用时也要走一遍上述过程，效率显然比直接从应用类加载器中获取要慢不少，所以为了后续调用节省时间，宁可第一次加载浪费点时间，也要选择应用程序类加载器。

3.2 双亲委派机制核心源码

首先看一下类加载器的继承关系图，而双亲委派的源码就在顶层父类ClassLoader类中的loadClass()方法实现的。

ClassLoader类中的loadClass()方法源码如下：

3.3 为什么要设计双亲委派机制？

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

4.编写自定义类加载器

自定义类加载器需要继承承 java.lang.ClassLoader 类。
该类有两个核心方法:

①：loadClass(String, boolean) 实现了双亲委派机制（继承即可起作用）
②：findClass 默认实现是空方法，所以我们自定义类加载器主要是重写findClass方法

public class MyLoadClass {//自定义类加载器MyClassLoadeTest   extends ClassLoaderstatic class MyClassLoadeTest extends ClassLoader {private String classPath;  //定义要加载的类的路径public MyClassLoadeTest(String classPath) {this.classPath = classPath;}//把路径下的文件转化化为字节数组private byte[] loadByte(String name) throws Exception {name = name.replaceAll("\\.", "/");FileInputStream fis = new FileInputStream(classPath + "/" + name + ".class");int len = fis.available();byte[] data = new byte[len];fis.read(data);fis.close();return data;}protected Class<?> findClass(String name) throws ClassNotFoundException {try {byte[] data = loadByte(name);//defineClass将一个字节数组转为Class对象，这个字节数组是class文件读取后最终的字节 数组。 由native方法实现return defineClass(name, data, 0, data.length);} catch (Exception e) {e.printStackTrace();throw new ClassNotFoundException();}}}//测试public static void main(String[] args) throws ClassNotFoundException {//初始化自定义类加载器，会先初始化父类ClassLoader，其中会把自定义类加载器的父加载 器设置为应用程序类加载器AppClassLoaderMyClassLoadeTest classLoader = new MyClassLoadeTest("D:/test");//D盘创建 test/com/tuling/jvm 几级目录，将User类的复制类User.class丢入该目录Class clazz = classLoader.loadClass("com.chinalife.policy_manage.user.entity.User");//输出类加载器类型System.out.println(clazz.getClassLoader().getClass().getName());}
}

输出结果：

注意：由于自定义类加载器默认父亲是应用类加载器，如果不删除掉classpath下的user.class，打印的类加载器类型会是sun.misc.Launcher$AppClassLoader。

5.（Tomcat）如何打破双亲委派机制

打破双亲委派机制需要重写ClassLoader中的双亲委派方法loadClass（）

打破双亲委派机制代码：

protected Class<?> loadClass(String name, boolean resolve)throws ClassNotFoundException{synchronized (getClassLoadingLock(name)) {// First, check if the class has already been loadedClass<?> c = findLoadedClass(name);if (c == null) {long t0 = System.nanoTime();if (c == null) {long t1 = System.nanoTime();//如果不是这个包下的类,比如Object，使用 自定义类加载器的父亲 >> 应用类加载器，双亲委派if(!name.startsWith("com.chinalife.policy_manage.user.entity")){c = this.getParent().loadClass(name);}else {//如果是这个包下的类 ，比如User，打破双亲委派机制c = findClass(name);}// this is the defining class loader; record the statssun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);sun.misc.PerfCounter.getFindClasses().increment();}}if (resolve) {resolveClass(c);}return c;}}

5.1 打破双亲委派机制的应用：tomcat

以Tomcat类加载为例，Tomcat 如果使用默认的双亲委派类加载机制行不行？答案是不行的。为什么？

①：tomcat是一个web容器，可能需要部署多个应用程序。不同的应用程序可能会依赖同一个第三方类库的不同版本。
- 比如：一个应用依赖的spring4，另外一个应用依赖的spring5。spring4和spring5底层也会依赖大量相同得类，如果按照以前的双亲委派机制，这些相同的类只能存在一份，如果被加载的是spring4的类，那么当spring5去使用某个类时，只能加载到spring4的类，那就可能丢失了spring5中对这个类的扩展功能。因此要保证每个应用程序的类库都是独立的，保证相互隔离。所以tomcat需要打破双亲委派机制
②：web容器也有自己依赖的类库，不能与应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。

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

5.2 Tomcat自定义加载器详解

如上图所示：

tomcat 为了实现隔离性，打破了双亲委派机制，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器
当然，Tomcat的基础设施还是需要遵循双亲委派机制的，只是为了实现应用隔离这一功能，局部打破双亲委派机制。其实现原理如上代码所示，也是经过过滤，让tomcat基础设施目录下的类加载时遵循双亲委派，存放不同应用的目录在加载时自定义类加载器！