java 委托原则_为什么说 Java SPI 的设计违反双亲委派原则

一、双亲委派模型

1、类加载器可以细分为如下三类

启动类加载器(Bootstrap ClassLoader)，负责将所有存放在\lib目录中的，或者被-Xbootclasspath参数所指定路径中，并且别虚拟机识别的(仅按照文件名识别，如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载)类库加载到虚拟机内存中，启动类记载器无法被java程序直接引用，用户自编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，直接使用null代替即可，如下代码清单所示

ClassLoader cl = getClassLoader();

if( cl == null ) {

return null;

}

SecurityManager sm = System.getSecurityManager();

if(sm == null) {

ClassLoader ccl = ClassLoader.getSystemClassLoader();

if(ccl != null && ccl != cl ) {

sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION);

}

}

return cl;

}

扩展类加载器(Extension ClassLoader)，由sum.misc.Launcher&ExtClassLoader实现，负责加载\lib\ext\目录中的，或者被java.ext.dirs系统变量所指定的路径中所有的类库，开发者可以直接使用扩展类加载器。

应用程序类加载器(Application ClassLoader),由sum.misc.Launcher&AppClassLoader实现，由于这个类记载器是ClassLoader中的getSystemClassLoader()方法方法的返回值，所以一般称为系统类记载器，它负责加载用户类路径(ClassPath)上所指定的类库，开发者可以直接使用这个类加载器。通常是程序默认类加载器。

应用程序都是由这3种类加载器互相配合进行加载的，如有必要，还可加入自定义的类加载器，类加载器的模型如下图：

类加载器双亲委派模型

如图展示的层次关系，称为类加载器的双亲委派模型，双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。 类加载器之间的父子关系一般不会以继承关系实现，而是以组合关系复用父类加载器的代码 ， 它不是一个强制性的模型，是java设计者推荐给开发者的一种类加载器实现方式。

2、双亲委派模型的工作方式

如果一个类加载器收到了类加载请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求，都应该传送到顶层的启动类记载器，只有当父加载器反馈自己无法完成这个记载请求(它的搜索范围中没有找到所需的类)，子加载器才会尝试自己去加载。

3、主要价值

采用双亲委派模型，一个显而易见的好处，java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，存放在\lib\rt.jar，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有双亲委派模型，由各个类加载器去自行加载的话，如果用户编写了一个java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，java类型体系中最基本的行为也无法保证。

判断两个类是否相等，只有这两个类是由同一个类加载器加载的前提下才有意义，否则，即使来自于同一个class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

双亲委派模型缺陷

双亲委派模型很好的解决了各个类记载器的基础类统一问题(越基础的类由越上层的类加载器加载)，基础类之所以称为基础，是因为它们总是作为被用户调用的API，但如果基础类又要回调用户的代码，那该怎么办呢。

假定 A 作为 B 的 parent，A 加载的类 对 B 是可见的； 然而 B 加载的类 对 A 却是不可见的。这是由 classloader 加载模型中的可见性(visibility)决定的。可见性原则允许子类加载器查看父ClassLoader加载的所有类，但父类加载器看不到子类加载器的类。

“调用方-接口方法-实现方”关系

双亲委派模型不适用场景(服务供应商接口 SPI (ServiceProviderInterface))

常见的 SPI 有 JDBC、JNDI、JAXP 等，这些 SPI 的接口由核心类库提供，却由第三方实现，这样就存在一个问题：

SPI 的接口是 Java 核心库的一部分，由 BootstrapClassLoader 加载；并且接口的调用逻辑也是在核心库

SPI 实现的 Java 类一般是由 AppClassLoader 来加载的。

根据ClassLoader加载模型中的可见性原则，BootstrapClassLoader 是无法找到 SPI 的实现类的，因为它只加载 Java 的核心库。它也不能将加载任务委派给 AppClassLoader，因为它是最顶层的类加载器。也就是说，双亲委派模型并不能解决这个问题。

破坏双亲委派模型1——典型例子JNDI服务

JNDI服务已经是java的标准服务，它的代码由启动类加载器去加载(代码在rt.jar中)，但JNDI的目的就是对资源进行集中管理和查找，它需要调用由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者(SPI service provider interface)的代码，但启动类加载器不可能认识这些代码，那该怎么办呢？

破坏双亲委派模型2——服务供应商接口 java.sql.Driver

如java.sql.Driver 是最为典型的 SPI 接口， java.sql.DriverManager 通过扫包的方式拿到指定的实现类，完成 DriverManager的初始化。问题来了，根据双亲委派的可见性原则，启动类加载器加载的 DriverManager 是不可能拿到系统应用类加载器加载的实现类 。

为了解决这个问题，java设计团队引入了一个不太优雅的设计：线程上下文类加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器AppClassLoader。

Java 在核心类库中定义了许多接口，并且还给出了针对这些接口的调用逻辑，然而并未给出实现。开发者要做的就是定制一个实现类，在 META-INF/services 中注册实现类信息，以供核心类库使用。

在核心类库使用 SPI 接口时，传递的类加载器使用线程上下文类加载器，就可以成功的加载到 SPI 实现的类(被线程上下文类加载器加载的类，能够被核心类库的调用方调用，且实现类不是通过双亲委派模型的方式加载，而是直接用传递的线程上下文类加载器加载)。

线程上下文类加载器在很多 SPI 的实现中都会用到。但在 JDBC 中，可能会看到一种更直接的实现方式，比如，JDBC 驱动管理 java.sql.Driver 中的 loadInitialDrivers() 方法中，看到 JDK 是如何加载驱动的：

java.sql.DriverManager#loadInitialDrivers

ServiceLoader loadedDrivers = ServiceLoader.load(Driver.class);

Iterator driversIterator = loadedDrivers.iterator();

/* Load these drivers, so that they can be instantiated.

* It may be the case that the driver class may not be there

* i.e. there may be a packaged driver with the service class

* as implementation of java.sql.Driver but the actual class

* may be missing. In that case a java.util.ServiceConfigurationError

* will be thrown at runtime by the VM trying to locate

* and load the service.

*

* Adding a try catch block to catch those runtime errors

* if driver not available in classpath but it's

* packaged as service and that service is there in classpath.

*/

try{

while(driversIterator.hasNext()) {

driversIterator.next();

}

} catch(Throwable t) {

// Do nothing

}

return null;

java.util.ServiceLoader#load(java.lang.Class)

public static ServiceLoader load(Class service) {

ClassLoader cl = Thread.currentThread().getContextClassLoader();

return ServiceLoader.load(service, cl);

}

通过从线程上下文(ThreadContext)获取 classloader ，借助这个classloader 可以拿到实现类的 Class。

线程上下文 classloader并非具体的某个loader，一般情况下是 application classloader， 但也可以通过 java.lang.Thread#setContextClassLoader 这个方法指定 classloader。讲解线程上下文类加载器，最主要是让大家在看到 Thread.currentThread().getClassLoader() 和 Thread.currentThread().getContextClassLoader() 时不会一脸懵逼，这两者除了在许多底层框架中取得的 ClassLoader 可能会有所不同外，其他大多数业务场景下都是一样的，大家只要知道它是为了解决什么问题而存在的即可。

综上，为什么说 Java SPI 的设计会违反双亲委派原则呢？

首先双亲委派原则本身并非 JVM 强制模型。

Java 在核心类库中，定义了许多接口，并给出了针对这些接口的调用逻辑，但未给出接口实现。核心类库由启动类加载器加载。

接口的实现类交由开发者实现，然而实现类不会被启动类加载器所加载，基于双亲委派的可见性原则，SPI 调用方无法拿到实现类。

SPI Serviceloader 通过线程上下文获取能够加载实现类的classloader，一般情况下是 application classloader，绕过了双亲委派模型的层级限制，逻辑上打破了双亲委派原则。