双亲委派模式

JVM加载类的实现方式，我们称为 双亲委托模型： 如果一个类加载器收到了类加载的请求，他首先不会自己去尝试加载这个类，而是把这个请求委托给自己的父加载器，每一层的类加载器都是如此，因此所有的类加载请求最终都应该传送到顶层的Bootstrap ClassLoader中，只有当父加载器反馈自己无法完成加载请求时，子加载器才会尝试自己加载。

双亲委派模式问题

双亲委派模式存在的问题就是不太灵活，和类的继承类似，只能继承一个类。一个 classloader 只能有一个父亲 classloader。 比如有如下的场景，我们需要加载 N 个 插件，这些插件使用自己的classloader来保证类的隔离。应用可以使用插件classloader 加载的类。其结构如下：

这样的问题就是 Plug-in 之间是从上往下是继承的关系，但是每一个 plug-in 对于 App 而言应该是同级别的关系 ，plug-in 之间应该可以相互依赖。 以上的模式显然是无法做到的。

双亲委派增强模式

双亲委派增强模式满足以下内容：

• Plugin Class loader 加载的 jar 都是隔离的，每一个jar 使用 一个 Plugin classloader 进行加载。
• 每一个 Plugin Class Loader 实例与其它的 实例 互为 双亲委派模式。 plugin 1 可以使用 2、3 加载的class，同理 2 也可以 1、2 加载的class。
• AppClassLoader 可以引用 所有 plugin classloader 加载的 class。但是 plugin classloder 不能使用 AppClassloader加载的class，为单向双亲委派模式。

Plugin 如何隔离？

plugin 隔离比较简单，只要使用不同的 Plugin classloader 实例进行加载就可以隔离。

Plugin 如何互为双亲委派？

每一个 pluginclassloader实例 指定加载自己的jar，并且每一个 pluginclassloader实例 可以获取到其他的pluginclassloader实例，在加载class的时候遍历所有的其它的classloader，如果加载成功加载完成，如果没有加载成功，自己再进行加载。这样就形成了所有 plugin 互为双亲委派模式。

fat jar 如何避免plugin的依赖被其他pluginclassloader加载？

当前打包的方式很多都是 fat jar 方式，自己的依赖 jar 也会打进自己的jar中，如果两个 plugin 分别依赖了 a-0.1jar 和 a-0.2.jar 。 如果按照上面的加载方式，plug-in-1 classloader 可能会加载到 a-0.2.jar 中的class。这样就出现了问题。

比较简单处理方式，在打包的时候可以把class 文件名称记录在 MANIFEST.MF 中，依赖 jar 不进行记录 ，这样每一个plugin classloader 对应加载的那些类就可以解析出来。

plug-in-1 classloader 加载class 过程如下：

• 识别这个class 在 其它的 classloader 中是否支持加载，判断的依据就是 classloader 解析的 class记录是否存在此class ，如果存在就使用其他的 plug-in classloader 进行加载。否则自己进行加载。

因为依赖jar中 class 没有进行记录，所以一直会使用自己的classloader进行加载。

参考 SOFA-ark 的classloader 模块 PluginClassLoader.java