三层classloader
Bootstrap classLoader:采用native code实现,是JVM的一部分,主要加载JVM自身工作需要的类,如java.lang.*、java.uti.*等; 这些类位于$JAVA_HOME/jre/lib/rt.jar。Bootstrap ClassLoader不继承自ClassLoader,因为它不是一个普通的Java类,底层由C++编写,已嵌入到了JVM内核当中,当JVM启动后,Bootstrap ClassLoader也随着启动,负责加载完核心类库后,并构造Extension ClassLoader和App ClassLoader类加载器。
ExtClassLoader:扩展的class loader,加载位于$JAVA_HOME/jre/lib/ext目录下的扩展jar。
AppClassLoader:系统class loader,父类是ExtClassLoader,加载$CLASSPATH下的目录和jar;它负责加载应用程序主函数类。
应用场景
有时候我们需要在一个 Project 中运行多个不同版本的 jar 包,以应对不同集群的版本或其它的问题。如果这个时候选择在同一个项目中实现这样的功能,那么通常只能选择更低版本的 jar 包,因为它们通常是向下兼容的,但是这样也往往会失去新版本的一些特性或功能,所以我们需要以扩展的方式引入这些 jar 包,并通过隔离执行,来实现版本的强制对应。
注意事项
总的来说,实现隔离允许指定 jar 包,主要需要做到以下几点:
自定义 ClassLoader,使其 Parent = null,避免其使用系统自带的 ClassLoader 加载 Class。
在调用相应版本的方法前,更改当前线程的 ContextClassLoader,避免扩展包的依赖包通过Thread.currentThread().getContextClassLoader()获取到非自定义的 ClassLoader 进行类加载
通过反射获取 Method 时,如果参数为自定义的类型,一定要使用自定义的 ClassLoader 加载参数获取 Class,然后在获取 Method,同时参数也必须转化为使用自定义的 ClassLoade 加载的类型(不同 ClassLoader 加载的同一个类不相等)
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自身的一部分使用。
最后再来讲一下,为什么每个bundle需要分配单独的Classloader,解决什么问题。在我看来,最主要的原因有如下两个:
定制导出类。非osgi环境下,所有package中的java类都将被导出,无法限定哪些只能jar内使用,哪些是需要export出去的。存在各种误用,耦合使用情况。
多版本控制。非osgi环境下,一个jvm对于一个类只允许存在一个版本。osgi中每个bundle是独立开发演进的,可能出现同时存在多个版本。
# OSGi动态加载删除bundle
使用监听器 listeners
ServiceListener 和ServiceTracker 提供bundle和service的动态监听,ServiceTracker可以动态监听未来的bundle和service(OSGi Release 2提供的ServiceTracker ,一般推荐)
通过重点推荐!)