码迷,mamicode.com
首页 > 其他好文 > 详细

OSGi类加载问题

时间:2015-07-02 00:52:26      阅读:226      评论:0      收藏:0      [点我收藏+]

标签:

项目中遇到的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
高并发环境下死锁问题
都会锁定自己的类加载器实例。
 

OSGi类加载问题

标签:

原文地址:http://www.cnblogs.com/lsx1993/p/4614904.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!