1. Java ClassLoader

Java通过Classloader加载Class，Classloader之间相互隔离。隔离真正的意思是：不同的Classloader可以加载相同的class定义，并且被jvm认定为不同的class。很多人对隔离有误解，认为不同的Classloader之间不能相互访问，这其实并不准确。可以这么理解：Classloader只是一个普通的Java类，加载的class集合是它的一个成员变量。如果一个Classloader中维护了另一个Classloader的引用，自然可以通过接口调用查找并使用另一个Classloader加载的类，双亲委派使用的正式这种机制。

双亲委派这名字乍一听好像是说你有父亲、母亲两个Classloader，你可以委派他们两个先去加载class，他们处理不了的你再处理。如果真这么理解就全错了。首先，他们不是两个，可能是n个；其次，他们不是你的父母，他们是整个jvm共享的Classloader；第三，他们谁的父母都不是，因为你和他们没有血缘(别人也没有)，你不是双亲Classloader的子类。

双亲委派的英文为parent delegation，指的是每个Classloader都有一个getParent方法获取上一级的Classloader。查找类时，先调用parent Classloader查找，如果找不到在用自身的Classloader查找。层级关系如下：

parent delegation

双亲委派实际上只是引用关系，上述bootrasp、extension、application Classloader之间关系均属此类。再来看另外一张图：

自定义Classloader

bootrasp、extension、application Classloader在jvm中只有一个实例，多个用户自定义的Classloader共享此实例，完成公共部分加载。

2. OSGI Classloader

在OSGI中，每一个Bundle有一个单独的Classloader实例。更具体点，BundleWiringImpl中定义了一个BundleClassLoader，每当加载一个bundle时，框架创建一个BundleClassLoader实例负责该bundle相关class的加载工作。

BundleClassLoader的加载顺序如下：

如class在 java.* package中，委托Bootstrap Classloader处理；

如class定义在 OSGi 框架中启动委托列表(org.osgi.framework.bootdelegation)中，则将加载请求委托给Bootstrap Classloader处理；

如class在 Import-Package 定义的package中，则框架找到导出此package的 Bundle 的 Class Loader，交其处理 。

如class属于在 Require-Bundle 中定义的 Bundle，则框架找到导出此package的Bundle的ClassLoader，交其处理。

Bundle 搜索自己的类资源 ( 包括 Bundle-Classpath 里面定义的类路径和属于 Bundle 的 Fragment 的类资源)；

若类在 DynamicImport-Package 中定义，则开始尝试在运行环境中寻找符合条件的 Bundle 。

Bundle之间隔离，但如果存在import关系又可以委托给相应export的classloader处理。实现上无非是维护了多个import bundle的Classloader，查找时调用其find方法实现。

需要注意的是：查找时优先查找Import-Package、Require-Bundle中的类，随后才是查找Bundle自己的类。这里又引入另外一个疑问，Embed-Dependency使用问题。

简单来说，如果一个Bunlde 需要使用protobuf-java.jar，有如下两种使用方式：

普通的dependency方式使用，如下图的Component C的使用方式。

Embed-dependency方式使用，如下图的ComponentA、ComponentB，此时将protobuf-java做为Bundle自身的一部分使用。

embed-dependency

按类加载的顺序，如果先加载Import-Package随后加载自身的Class，在外部存在protobuf-java，又有内嵌的protobuf-java时，如何做到使用自己的而非外部的呢？答案是在Embed-dependency中的jar并不会出现在Import-Package中。

最后再来讲一下，为什么每个bundle需要分配单独的Classloader，解决什么问题。在我看来，最主要的原因有如下两个：

定制导出类。非osgi环境下，所有package中的java类都将被导出，无法限定哪些只能jar内使用，哪些是需要export出去的。存在各种误用，耦合使用情况。

多版本控制。非osgi环境下，一个jvm对于一个类只允许存在一个版本。osgi中每个bundle是独立开发演进的，可能出现同时存在多个版本。

3. 参考资料