全盘负责委托机制 ：
如果A类调用了B类,则B类由A类的加载器进行加载
代码演示
public class Test {
public static void main(String[] args) throws ClassNotFoundException {
ClassLoader loader1 = Test.class.getClassLoader();
System.out.println(loader1);
ClassLoader loader2 = Class.forName("com.lb.springboot_simple_starter.entity.User").getClassLoader();
System.out.println(loader2);
ClassLoader loader3 =Thread.currentThread().getContextClassLoader();
System.out.println(loader3);
}
}
执行结果：
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$AppClassLoader@18b4aac2
在Test类中去加载User类，发现两者的类加载器是都是一样的，正好验证了全盘负责委托机制
双亲委派模型 ：
下级加载器要加载某个类时，会先委托给上级加载器,并且询问上架加载器是否加载过此类,如果加载过就不加载这个类了,直接返回上级加载器加载过的那个class对象,如果上级没有加载过,则会尝试加载,无法加载(无法加载特定目录之外的其他类)时则由自己加载器进行加载。 如果上级还有上级以此类推。
JAVA提供的类加载器
启动类加载器(Bootstrap ClassLoader),它是属于虚拟机自身的一部分，用C++实现的，主要负责加载
\lib目录中或被-Xbootclasspath指定的路径中的并且文件名是被虚拟机识别的文件。它等于是所有类加载器的爸爸。 扩展类加载器(Extension ClassLoader),它是Java实现的，独立于虚拟机，主要负责加载
\lib\ext目录中或被java.ext.dirs系统变量所指定的路径的类库。 应用程序类加载器(Application ClassLoader),它是Java实现的，独立于虚拟机。主要负责加载用户类路径(classPath)上的类库，如果我们没有实现自定义的类加载器那这玩意就是我们程序中的默认加载器。
源码：
java.lang.ClassLoader.loadClass()方法
protected Class loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// First, check if the class has already been loaded
//检查类是否被当前加载器加载过
Class c = findLoadedClass(name);
//没有加载过
if (c == null) {
long t0 = System.nanoTime();
try {
//有上级对象嘛
if (parent != null) {
//如果有上级对象,让上级对象尝试加载,上级对象还是这个方法，递归的,逻辑一样
c = parent.loadClass(name, false);
} else {
//没有上级对象,自己加载吧
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
//还是没有，那就抛ClassNotFound异常
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
//加载好了，返回
return c;
}
}
可以看出,jdk自带的ClassLoader的实现是完全符合双亲委派模型的。
为什么说JDBC破坏了双亲委派？
首先需要注意一点,
JDBC4.0之前使用Class.forName("")方式加载驱动是不会破坏双亲委派的。
JDBC4.0之后使用spi机制才会破坏双亲委派机制。
Class.forName("")方式不破坏双亲委派机制：
由于这段代码是写在我们调用方，由我们自己来加载驱动类,由于遵循全盘负责委托机制，他使用的必定是和我们调用类的加载器一样的 ApplicationClassLoader这个加载器。从 ApplicationClassLoader由下而上进行委派加载。
SPI方式加载驱动：
java.sql.DriverManagement这个类的静态代码块去加载驱动类
public class DriverManager {
//省略多余代码
static {
loadInitialDrivers();
println("JDBC DriverManager initialized");
}
}
loadInitialDrivers();这个方法的具体逻辑则是从驱动包下META-INF/services文件中，加载里面写好的Driver的实现类。
但是,加载这个类的加载器使用的是线程上下文中的AppClassLoader,
这个加载器是由jvm启动时，调用Launcher的构造方法放入当前线程的
1. 为什么说他破坏了双亲委派原则？
而这个类加载器加载驱动包下的Driver实现类时,根本没有遵循双亲委派机制,并没有直接去向上级加载器委派,直接就由AppClassLoader加载器加载好了。
为啥不向上委派呢
应该是Bootstrap ClassLoader和Extension ClassLoader,他们只能加载自己指定目录下的类，无法加载运行时的，其他目录下的类
2.甚至同时破坏了全盘负责委托机制
之前的代码知道，是由DriverMangement是在rt.jar包中的，肯定是由Bootstrap ClassLoader加载器加载的,而DriverMangement加载Driver实现类则是直接由线程上下文中的AppClassLoader加载的，违背了全盘负责委托机制中A类调用B类,B类则由A类加载器加载的原则。
同样的，是因为Bootstrap ClassLoader肯定是无法加载jdbc驱动包下的。
JDBC嘛，就是接口都是由jdk提供，具体实现是由第三方数据库产商提供的,所以也只能采用这种方式去加载驱动实现类了。
看到网上很多博客都说，由于DriverMangement和驱动实现类的类加器不同,所以违法了双亲委派机制，我刚开始看了很是懵逼,个人觉得是不太对劲的，这样应该是违反了全盘负责委托机制吧。