JVM双亲委派机制！

双亲委派类加载过程

当App尝试加载一个类时，它不会直接尝试加载这个类

  • 首先会在自己的命名空间中查询是否已经加载过这个类
    • 如果没有会先将这个类加载请求委派给父类加载器Ext完成

当Ext尝试加载一个类时，它也不会直接尝试加载这个类

  • 也会在自己的命名空间中查询是否已经加载过这个类
    • 没有的话也会先将这个类加载请求委派给父类加载器Bootstrap完成

如果Bootstrap加载失败，这个需要被加载的类不在Bootstrap的加载范围内

  • 那么Bootstrap会重新将这个类加载请求交由子类加载器Ext完成

如果Ext加载失败，这个类也不在Ext的加载范围内

  • 最后会重新将这个类加载请求交给子类加载器App完成

如果App加载器也加载失败这个类根据全限定名无法查找到

  • 则会抛出ClassNotFoundException异常。

此处的父子关系并非继承关系，而是采用组合关系来实现

image-20231026171802543

双亲委派机制的优势

可以避免一个类在不同层级的类加载器中重复加载

  • 如果父类加载器已经加载过该类了，那么就不需要子类加载器再加载一次

沙箱安全机制:

可以保障Java核心类的安全性问题

  • 比如通过网络传输过来一个java.lang.String类，需要被加载时，通过这种双亲委派的方式
    • 最终找到Bootstrap加载器后，发现该类已经被加载
    • 从而就不会再加载传输过来的java.lang.String类，而是直接返回Bootstrap加载的String.class

这样可以有效防止Java的核心API类在运行时被篡改

  • 从而保证所有子类共享同一基础类，减少性能开销和安全隐患问题

双亲委派的实现原理

所有的类加载器都间接的继承自ClassLoader类

  • 包括Ext、App类加载器（Bootstrap除外，因为它是C++实现的）

双亲委派模型的实现逻辑全在于loadClass()方法

  • 而ExtClassLoader加载器是没有重写loadClass()方法，
  • AppClassLoader加载器虽然重写了loadClass()方法，但其内部最终还是调用父类的loadClass()方法

无论是ExtClassLoader还是AppClassLoader加载器

  • 其本身都未打破ClassLoader.loadClass()方法中定义的双亲委派逻辑
  • Bootstrap、Ext、App这些JVM自带的类加载器都默认会遵守双亲委派模型
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// sun.misc.Launcher类 → AppClassLoader内部类 → loadClass()方法
 public Class loadClass(String name, boolean resolve)
     throws ClassNotFoundException
 {
     int i = name.lastIndexOf('.');
     if (i != -1) {
         SecurityManager sm = System.getSecurityManager();
         if (sm != null) {
             sm.checkPackageAccess(name.substring(0, i));
         }
     }
     // 依旧调用的是父类loadClass()方法
     return (super.loadClass(name, resolve));
 }

打破双亲委派机制

需要重写loadClass方法，在loadClass方法中不委托给父类尝试着进行加载，直接在当前的类加载器进行加载。

打破双亲委派机制的场景:

  • 一个Tomcat可能部署多个应用，不同的应用可能依赖的同一个第三方类库的不同版本（会造成很多大量的文件路径相同的类）
  • 这种情况下就不能通过双亲委派机制去加载，要保证每个应用的类库是独立的，相互隔离。