OSGI——更灵活的类加载器架构

本篇文章是看了深入理解JVM关于OSGI后的一点个人理解和笔记

OSGI(Open Service Gateway Initiative)是一种与类加载器有关的规范，也可以将其视作一种架构或者模型框架。我们都知道，JVM中类加载器的结构是树状的，其原因是使用了双亲委派模型，这一个模型没啥不好，主流也是用这个，但树状结构相比更复杂的场景而言不够灵活；而OSGI规范之下的类加载器架构是网络状的，允许加载器之间产生更多的关系，所以缺点也很明显：引入了复杂度和出错率。下面具体介绍。

不同的类加载器架构
先来看下两种类加载器架构的区别：

​​

​​

可以看出，相同数目的类加载器数量，OSGI就是乱。但不可否认，OSGI提供了更多的器间关系，适合在存在有复杂类加载依赖的系统中使用。

OSGI的基本组件——Bundle
OSGI提供了一种类似于Java类库的组件，叫Bundle，用Jar包的形式进行了封装，看起来还没看到什么明显的区别对么？实际上，Bundle（可以视为类库）之间的关系对应着上图中的类加载器的关系，而且是一一对应。

为什么能做到关系的复杂呢？因为在Bundle中可以声明它所依赖的其它包和类（归属于其它Bundle），也可以声明它允许导出即被依赖的包和类，然后类加载器就按着Bundle之间的关系规定去加载目标类（被依赖类），即Bundle之间的关系决定了类加载器之间的关系，而这也是bundle和类加载器一一对应的原因。

而传统的库类加载取决于类加载器的双亲委派模型：先让父类加载器看能不能找到并加载本类（依赖类）依赖的类（被依赖类），找不到才用自己的类加载器去加载被依赖类。

​​

Bundle和类加载器的关系
其实Bundle可以类比Java中的类库，类加载器用于加载Bundle中的类或者接口（均以字节码形式存在）到内存中。

OSGI的优缺点
优点：
1）类库的可见性相比传统的Java类库能得到更精准的控制，也更灵活；
2）另外就是基于OSGI的程序很可能实现模块级别的热插拔功能，什么意思？就是程序在升级或者调试排错的时候，可以只停用、安装应用的一个模块而不需要停止整个应用。

缺点：
错综的关系引入了复杂度，容易出错，体现在容易导致死锁和内存泄漏。

欢迎关注我的公众号——日更的小易