JVM知识总结（双亲委派机制）

文章收录在网站：http://hardyfish.top/

文章收录在网站：http://hardyfish.top/

文章收录在网站：http://hardyfish.top/

文章收录在网站：http://hardyfish.top/

双亲委派机制

双亲委派类加载过程

当App尝试加载一个类时，它不会直接尝试加载这个类，首先会在自己的命名空间中查询是否已经加载过这个类，如果没有会先将这个类加载请求委派给父类加载器Ext完成。

当Ext尝试加载一个类时，它也不会直接尝试加载这个类，也会在自己的命名空间中查询是否已经加载过这个类，没有的话也会先将这个类加载请求委派给父类加载器Bootstrap完成。

如果Bootstrap加载失败，这个需要被加载的类不在Bootstrap的加载范围内，那么Bootstrap会重新将这个类加载请求交由子类加载器Ext完成。

如果Ext加载失败，这个类也不在Ext的加载范围内，最后会重新将这个类加载请求交给子类加载器App完成。

如果App加载器也加载失败这个类根据全限定名无法查找到，则会抛出ClassNotFoundException异常。

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

双亲委派机制的优势

可以避免一个类在不同层级的类加载器中重复加载，如果父类加载器已经加载过该类了，那么就不需要子类加载器再加载一次。

沙箱安全机制:

可以保障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自带的类加载器都默认会遵守双亲委派模型。

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