OSGi类加载问题

项目中遇到的JVM难点

——启动OSGi容器时，出现永久代内存不够。 内存泄露

——OSGi找不到类路径问题。

—— 线程死锁问题。

 

问题一：OSGi类内存问题

        其次，从内存用量来看，OSGi允许不同版本的Package同时存在，这是个优点，但是客观上会占用更多内存。例如，一个库可能需要 ASM 3.0，而同一应用程序使用的另一个库可能需要ASM 2.0，要解决这种问题，通常需要更改代码，而在OSGi中只需要付出一点Java 方法区的内存即可解决。

 

        不过，如果对OSGi动态性使用不当，可能会因为 不正确持有某个过期模块（被更新或卸载的模块）中一个类的实例，导致该类的类加载器无法被回收，进而导致该类加载器下所有类都无法被GC回收掉。

 

        为了防止保留类加载器带来的内存泄露，我们必须使用弱键和弱值。目标是不在内存中保持一个已卸载的bundle的类空间。我们必须使用弱值，因为每 个映射项目的值（BridgeClassLoader）都强引用着键（ClassLoader），于是以此方式否定它的“弱点”。这是WeakHashMap javadoc规定的标准建议。通过使用一个弱缓存我们避免了跟踪所有的bundle，而且不必对他们的生命周期做出反应。

问题二：运行时的ClassNotFoundException

情形1: 间接引用带来的问题

原因:Plugin_1 没有直接使用Plugin_2的Java文件，但运行时使用了Plugin_2中的Jar包中的文件。

解决措施:将Plugin_2中的Jar包导出来, 同时在Plugin_1中导入这些包。

 

情形2: 利用String反射到类或对象的时候出现的问题

Plugin_1涉及到由String转化为类对象Plugin_2_ClassA(Plugin_2_ClassA表示Plugin_2中的Class  A)的操作, 这个时候调用非常隐晦， 也需要按照情形1进行处理。

 

情形3:  加载顺序不对带来的问题

IDE环境下, 这个问题出现在控制台中

IDE环境下, 这个问题出现在configuration目录下面的Log目录中。

 

1. 如果是IDE环境下出现的问题,   Run Configuration中配置一下启动顺序

2. 发布环境下, config.ini 需要做新的调整,先加载底层插件，再加载依赖插件，最后加载不被任何插件依赖的项目 (参见文章开始的参考资料4)

3. 发布环境下, 如果问题一再出现, 请删除\configuration目录下的org.eclipse.osgi 目录, 再进行启动

 

 

OSGi类加载流程

OSGi每个模块都有自己独立的classpath。

如何实现这一点呢？是因为OSGi采取了不同的类加载机制：

——OSGi为每个bundle提供一个类加载器，该加载器能够看到bundle Jar文件内部的类和资源；

——为了让bundle能互相协作，可以基于依赖关系，从一个bundle类加载器委托到另一个bundle类加载器。

 

Java和J2EE的类加载模型都是层次化的，只能委托给上一层类加载器；

 

而OSGi类加载模型则是网络图状的，可以在bundle间互相委托。——这样更合理，因为bundle间的依赖关系并不是层次化的。

 

 

优点

找不到类时的错误提示更友好。假如bundleE不存在，则bundleC就不会被解析成功，会有错误消息提示为何未能解析；而不是报错ClassNotFoundException或NoClassDefFoundError。

效率更高。

 

在标准Java类加载模型中，总是会在classpath那一长串列表中进行查找；而OSGi类加载器能立即知道去哪里找类。

 

流程

Step 1: 检查是否java.*，或者在bootdelegation中定义

当bundle类加载器需要加载一个类时，首先检查包名是否以java.*开头，或者是否在一个特定的配置文件（org.osgi.framework.bootdelegation）中定义。如果是，则bundle类加载器立即委托给父类加载器（通常是Application类加载器）。

 

这么做有两个原因：

唯一能够定义java.*包的类加载器是bootstrap类加载器，这个规则是JVM要求的。如果OSGI bundle类加载器试图加载这种类，则会抛Security Exception。

一些JVM错误地假设父加载器委托永远会发生，内部VM类就能够通过任何类加载器找到特定的其他内部类。所以OSGi提供了org.osgi.framework.bootdelegation属性，允许对特定的包（即那些内部VM类）使用父加载器委托。

 

Step 2: 检查是否在Import-Package中声明

检查是否在Import-Package中声明。如果是，则找到导出包的bundle，将类加载请求委托给该bundle的类加载器。如此往复。

 

Step 3: 检查是否在Require-Bundle中声明

检查是否在Require-Bundle中声明。如果是，则将类加载请求委托给required bundle的类加载器。

 

Step 4: 检查是否bundle内部类

检查是否是该bundle内部的类，即当前JAR文件中的类。

 

Step5:  检查fragment

搜索可能附加在当前bundle上的fragment中的内部类。

 

什么是fragment？

Fragment bundle是OSGi 4引入的概念，它是一种不完整的bundle，必须要附加到一个host bundle上才能工作；fragment能够为host bundle添加类或资源，在运行时，fragment中的类会合并到host bundle的内部classpath中。

 

fragment有什么作用？

 

【场景1】bundle中有针对特定平台的代码

假设bundle对不同平台的实现方式稍有不同，Windows和Linux下代码有不同之处，即bundle中有针对特定平台的代码。

我们应该为每个平台提供不同的bundle吗？——显然不能，因为那会造成代码重复。

 

或者将共同代码放到bundle A中，Windows特定的那部分代码放到bundle Pwin中，Linux特定的那部分代码放到bundle Plinux中。——有问题：Pwin肯定要依赖A中某些包，我们就必须在A中导出这些包，如果只有Pwin用到这些包 岂不破坏封装性。

 

最好的解决方法是把Pwin作为fragment，附加到A中。这样Pwin就能看到A中的所有包，A也能看到Pwin的所有包。

 

【场景2】针对不同国家用户提供不同的i18n

 

GUI程序通常会通过properties文件定义i18n信息，可以将不同的i18n存到不同的fragment中。运行时用户只需要下载host bundle以及特定的i18n fragment即可，不需要把其他国家的i18n也下载下来。

 

 

Step6: 动态类加载

 

OSGi：灵活的类加载器架构

P279

高并发环境下死锁问题

都会锁定自己的类加载器实例。

 

转载于:https://www.cnblogs.com/lsx1993/p/4614904.html