深入探索JVM类加载机制 — 类加载器之破坏双亲委派模型

破坏双亲委派模型

双亲委派模型的第⼀次“被破坏”其实发⽣在双亲委派模型出现之前——即JDK 1.2⾯世以

前的“远古”时代。由于双亲委派模型在JDK 1.2之后才被引⼊，但是类加载器的概念和抽

象类java.lang.ClassLoader则在Java的第⼀个版本中就已经存在，⾯对已经存在的⽤户⾃

定义类加载器的代码，Java设计者们引⼊双亲委派模型时不得不做出⼀些妥协，为了兼

容这些已有代码，⽆法再以技术⼿段避免loadClass()被⼦类覆盖的可能性，只能在JDK

1.2之后的java.lang.ClassLoader中添加⼀个新的protected⽅法findClass()，并引导⽤户

编写的类加载逻辑时尽可能去重写这个⽅法，⽽不是在loadClass()中编写代码。上节我们

已经分析过loadClass()⽅法，双亲委派的具体逻辑就实现在这⾥⾯，按照loadClass()⽅法

的逻辑，如果⽗类加载失败，会⾃动调⽤⾃⼰的findClass()⽅法来完成加载，这样既不

影响⽤户按照⾃⼰的意愿去加载类，⼜可以保证新写出来的类加载器是符合双亲委派规则

的。

双亲委派模型的第⼆次“被破坏”是由这个模型⾃身的缺陷导致的，双亲委派很好地解决了各个类加载器协作时基础类型的⼀致性问题(越基础的类由越上层的加载器进⾏加载)，基础类型之所以被称为“基础”，是因为它们总是作为被⽤户代码继承、调⽤的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类型⼜要调⽤回⽤户的代码，那该怎么办呢? 为了解决这个困境，Java的设计团队只好引⼊了⼀个不太优雅的设计: 线程上下⽂类加载器 (Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()⽅法进⾏设置，如果创建线程时还未设置，它将会从⽗线程中继承⼀个，如果在应⽤程序的全局范围内都没有设置过的话，那这个类加载器默认就是应⽤程序类加载器。JNDI服务使⽤这个线程上下⽂类加载器去加载所需的SPI服务代码，这是⼀种⽗类加载器去请求⼦类加载器完成类加载的⾏为，这种⾏为实际上是打通了双亲委派模型的层

次结构来逆向使⽤类加载器，已经违背了双亲委派模型的⼀般性原则，但也是⽆可奈何的

事情。Java中涉及SPI的加载基本上都采⽤这种⽅式来完成，例如JNDI、JDBC、JCE、

JAXB和JBI等