jvm双亲委派 vs 破坏双亲委派理解加载器的权责分配
作者：jacheut
双亲委派模型
对于任意一个类，都需要由加载它的类加载器和这个类本身来一同确立其在Java虚拟机中的唯一性。
为什么需要双亲委派
如果不是同一个类加载器加载，即使是相同的class文件，也会出现判断不相同的情况，从而引发一些意想不到的情况，为了保证相同的class文件，在使用的时候，是相同的对象，jvm设计的时候，采用了双亲委派的方式来加载类。
双亲委派好处
- 避免同一个类被多次加载；
- 每个加载器只能加载自己范围内的类；
缺点：
顶层的启动类加载器的代码无法访问到底层的类加载器。
每一个类都有一个对应它的类加载器。系统中的 ClassLoder 在协同工作的时候会默认使用双亲委派模型 。即在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。类加载的时候，首先会把该请求委派该父类加载器的 loadClass() 处理，因此所有的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader中。当父类加载器无法处理时，才由自己来处理。特别当父类加载器为null时，会使用启动类加载器 BootstrapClassLoader 作为父类加载器。
父类加载器有自己的加载范围，范围内没有找到，则不加载，并返回给子类。
jvm提供了三种系统加载器：
- 启动类加载器（Bootstrap ClassLoader）：C++实现，在java里无法获取，负责加载/lib下的类。
- 扩展类加载器（Extension ClassLoader）： Java实现，可以在java里获取，负责加载/lib/ext下的类。
- 系统类加载器/应用程序类加载器（Application ClassLoader）：是与我们接触对多的类加载器，我们写的代码默认就是由它来加载，ClassLoader.getSystemClassLoader返回的就是它。
破坏双亲委派
为什么需要破坏双亲委派？
因为在某些情况下父类加载器需要委托子类加载器去加载class文件。受到加载范围的限制，父类加载器无法加载到需要的文件，以Driver接口为例，由于Driver接口定义在jdk当中的，而其实现由各个数据库的服务商来提供，比如mysql的就写了MySQL Connector，那么问题就来了，DriverManager（也由jdk提供）要加载各个实现了Driver接口的实现类，然后进行管理，但是DriverManager由启动类加载器加载，只能记载JAVA_HOME的lib下文件，而其实现是由服务商提供的，由系统类加载器加载，这个时候就需要启动类加载器来委托子类来加载Driver实现，从而破坏了双亲委派，这里仅仅是举了破坏双亲委派的其中一个情况。
破坏双亲委派的实现
我们结合Driver来看一下在spi（Service Provider Inteface）中如何实现破坏双亲委派。
先从DriverManager开始看，平时我们通过DriverManager来获取数据库的Connection：
在调用DriverManager的时候，会先初始化类，调用其中的静态块：
可以看到，load方法调用获取了当前线程中的上下文类加载器，那么上下文类加载器放的是什么加载器呢？
在sun.misc.Launcher中，我们找到了答案，在Launcher初始化的时候，会获取AppClassLoader，然后将其设置为上下文类加载器，而这个AppClassLoader，就是之前上文提到的系统类加载器Application ClassLoader，所以上下文类加载器默认情况下就是系统加载器。
以上就是浅谈jvm双亲委派和破坏双亲委派的详细内容，更多关于jvm双亲委派的资料请关注脚本之家其它相关文章！