1 类装载器
Java中的Class实例,不仅是全限定名(包名+类名)的函数,也是类装载器的函数,即:Class = f(name,Li,Ld)其中name表示为全限定名,Li为初始类装载器,Ld为定义类装载器初始装载器;初始类装载器为在其上发生loadClass调用返回Class实例的那个装载器;定义装载器则是实际为Class实例执行defineClass,从bytecode中读入类定义的那个装载器。因为loadClass方法可以被子类重载,其中对defineClass的调用有可能被委派给其它装载器做,(具体含义,参见java classloader 的双亲委派机制—《深入JAVA虚拟机》一书有比较深入的讲解)所以Li和Ld不一定相同。
于是, 两个不同类装载器装载的类,即使类全限定名相同,都不能相互cast,否则抛出ClassCastException。
如果装载器L1装载的类p.A有包可见的方法f,则装载器L2装载的类p.B不能访问f,否则抛出IllegalAccessException。
如果有Class1和Class2的name,Li相同,而Ld不同,它们实例之间的引用赋值时会触发装载限制检查,抛出LinkageError。
2 JBoss的Classloader机制
概念介绍
UCL:org.jboss.mx.loading.UnifiedClassLoader3,他继承了标准的java.net.URLClassLoader,覆盖了标准的parent delegation模型以使用共享class和资源仓库(respository)org.jboss.mx.loading.UnifiedLoaderRepository3
Jboss Classloader 实现机制
平面模型:
JBoss实现了自己的类装载器UnifiedClassLoader3,一般来说,一个顶层的deployment就有一个UnifiedClassLoader3实例为之工作。一个deployment所装载的类,其他deployment是可见的,全局唯一的UnifiedLoaderRepository3实例用于管理这些类,以及转载他们的UnifieClassLoader3实例。UnifiedLoaderRepository3实例和UnifieClassLoader3实例是一对多的关系。
在%JBOSS_HOME%/server/<profile>/conf/jboss-service.xml中有如下配置:
<mbean code="org.jboss.management.j2ee.LocalJBossServerDomain" name="jboss.management.local:j2eeType=J2EEDomain,name=Manager">
<attribute name="MainDeployer">jboss.system:service=MainDeployer</attribute>
<attribute name="SARDeployer">jboss.system:service=ServiceDeployer</attribute>
<attribute name="EARDeployer">jboss.j2ee:service=EARDeployer</attribute>
<attribute name="EJBDeployer">jboss.ejb:service=EJBDeployer</attribute>
<attribute name="RARDeployer">jboss.jca:service=RARDeployer</attribute>
<attribute name="CMDeployer">jboss.jca:service=ConnectionFactoryDeployer</attribute>
<attribute name="WARDeployer">jboss.web:service=WebServer</attribute>
<attribute name="CARDeployer">jboss.j2ee:service=ClientDeployer</attribute>
<attribute name="MailService">jboss:service=Mail</attribute>
<attribute name="JMSService">jboss.mq:service=DestinationManager</attribute>
<attribute name="JNDIService">jboss:service=Naming</attribute>
<attribute name="JTAService">jboss:service=TransactionManager</attribute>
<attribute name="UserTransactionService">jboss:service=ClientUserTransaction</attribute>
<attribute name="RMI_IIOPService">jboss:service=CorbaORB</attribute>
</mbean>
不同的deployer是根据文件的后缀进行区分。MainDeployer起到一个controller的作用,根据不用的后缀分发到不同的deployer进行处理。如果是*.ear,则会由EARDeployer进行载入。
应用的加载是一个 Top Level Deployer + Top Level Ucl。 举个例子,比如发布一个a.ear应用,ear应用中会包含一个*.war。这时候就会涉及deployer选择问题。jboss采取的原则就是按Top Level,根据最顶层的应用选择deployer,继而也有了top level ucl的概念。由顶级的ucl来加载整个应用。这里需要注意的是war的部署有点特别。它只是将自身添加到ucl的classpath域中,而war下的WEB-INF/lib/*.jar,则是由WebAppClassloader来加载。可调整ear下的 META-INF/jboss-service.xml中的UseJbossWebLoader属性。如果设置为true,就是用ucl来加载war下的jar包,它首先会调用仓库去loadclass(即从UnifiedLoaderRepository3实例中查找看是否已经加载过),仓库在查找无果的情况下会回调各自的UCL去加载本地库。否则就是采用独立SERVLET规范定义的classloader(即WebAppClassLoader)加载。
隔离的(scope)JBOSS 应用ClassLoader机制:
每一个隔离的JBOSS应用都有一个自己的私有仓库,org.jboss.mx.loading.HeirarchicalLoaderRepository3,此类继承自公用仓库类,org.jboss.mx.loading.UnifiedLoaderRepository3。scope配置只能是顶级下的配置,比如一个.sar中包括.war都配置了scope只有.sar下的META-INF/jboss-service.xml才有效,这与前面的Top Level Deployer + Top Level Ucl对应,
针对.sar可以在jboss-service.xml中,添加如下配置
<server>
<loader-repository> com.example:loader=unique-archive-name </loader-repository>
</server>
针对.ear,可以在jboss-app.xml中添加如下配置
<jboss-app>
<loader-repository>com.example:loader=unique-archive-name</loader-repository>
</jboss-app>
针对.war,可以在jboss-web.xml中添加如下配置
<jboss-web>
<loader-repository> com.example:loader=unique-archive-name </loader-repository>
</jboss-web>
针对典型的ear+war应用,*.ear/META-INF/jboss-service.xml,用于调整war的加载方式
<!-- Get the flag indicating if the normal Java2 parent first class
loading model should be used over the servlet 2.3 web container first
model.
-->
<attribute name="Java2ClassLoadingCompliance">false</attribute>
<!-- A flag indicating if the JBoss Loader should be used. This loader
uses a unified class loader as the class loader rather than the tomcat
specific class loader.
The default is false to ensure that wars have isolated class loading
for duplicate jars and jsp files.
-->
<attribute name="UseJBossWebLoader">false</attribute>
配置UseJBossWebLoader为true时,webapp将使用jboss隔离的UCL作为classloader,并且是否parent load模型是由其中的java2ParentDelegation参数决定,java2ClassLoadingCompliance属性会被忽略;
配置UseJBossWebLoader为false,则webapp的加载时通过独立于jboss的classloader即WebAppClassLoader来加载,配置java2ClassLoadingCompliance为true,则表明是选择parent first,典型的classloader双亲委派模型,否则采用child first,先从自身加载,找不到再请父亲加载。
分享到:
相关推荐
随着OSGi(Open Services Gateway Initiative)风格的类加载机制逐渐流行,以及新的Java模块和类加载规范的出现,JBoss对自身的类加载层进行了重构,以适应这些新的需求。在JBoss Microcontainer中,类加载层扮演着...
当需要加载类时,先由父类加载器尝试,如果找不到则递归到更高级别的父类加载器,直到到达根类加载器(Bootstrap ClassLoader)。这种机制确保了类型安全,防止了不同版本的类冲突。 2.2.2 类装载和Java中的类型 ...
压缩包中的"jboss+classloader分享.ppt"很可能包含了一个关于JBOSS类加载机制的详细讲解,这将有助于理解类加载如何影响RMI的使用,以及如何解决相关的类冲突问题。这个PPT可能涵盖了以下内容: - JBOSS类加载层次...
在深入探讨JBoss的管理与开发核心技术前,我们先来理解一下本书中提到的关键概念之一:JBoss的JMX实现架构以及类装载器机制。这不仅对于理解和操作JBoss有着重要意义,也是实现热部署等高级功能的基础。 ### JBoss ...
### JBoss管理与开发核心技术(第三版):深入解析JBoss类装载器架构与类型安全性 ...对于开发人员来说,了解这些底层机制是非常重要的,因为它有助于避免常见的运行时错误,并确保应用程序的稳定性和可靠性。
JVM通过一些工具和插件,如JRebel、JBoss ClassLoader、Spring Boot DevTools等,实现了类的热更新。 热更新的基本原理是利用JVM的类加载机制。在Java中,类是由ClassLoader加载的,当一个类被加载后,如果该类的....
除了手动编写自定义ClassLoader,还有一些开源工具可以帮助实现Java热部署,例如JRebel、JBoss Tools中的HotSwap等。这些工具能够监控源代码的变化,并自动触发类的重新加载,极大地提高了开发效率。 总的来说,...
2. JBoss ClassLoader Enhancer:研究如何利用这个工具在不重启JVM的情况下更新类文件。 3. ClassPath Hacking:理解如何修改运行时的类路径,实现类的动态替换,从而实现热部署。 四、实战经验 源码中的实战案例将...
在JBoss 3.x中,类加载机制被优化,使得部署单元之间的类共享成为可能。这解决了JBoss 2.x中MBean无法与动态部署的J2EE组件无缝协作的问题,并且赋予了MBeans热部署的能力。热部署意味着在不中断服务的情况下,可以...
#### ClassLoader结构与双亲代理机制 - **ClassLoader层次结构**:Bootstrap Loader、Extension Loader、App ClassLoader。 - **自定义Class**:理论上可以定义`java.lang.String`类,但实际开发中不允许这样做,...
5. **ClassLoader**:双亲委派模型是类加载机制的核心,防止不同ClassLoader加载相同的类造成混乱。 6. **设计模式**:通常需要了解单例、工厂、观察者、装饰器、适配器、代理等常见的23种设计模式,以及六大设计...
7. 类加载机制:classLoader、类加载过程、双亲委派(破坏双亲委派)、模块化(jboss modules、osgi、jigsaw) 8. 虚拟机性能监控与故障处理工具:jps, jstack, jmap、jstat, jconsole, jinfo, jhat, javap, btrace...
- **类加载器体系结构**:认识Bootstrap ClassLoader、Extension ClassLoader、Application ClassLoader的区别和作用。 - **类的生命周期管理**:掌握类的卸载条件和时机。 ### 4. GUI开发 - **Applet基础知识**:...
首先,Tomcat是Java EE(Enterprise Edition)的一部分,但仅实现了Servlet和JSP规范,因此它被归类为轻量级应用服务器,与全功能的应用服务器如JBoss或WebLogic相比,它的内存占用和系统资源需求更低,适合小型到...
- **类加载器**:了解类加载过程,掌握Bootstrap ClassLoader、Extension ClassLoader和App ClassLoader的工作机制。 - **类的反射**:进一步探索Java反射机制,学习如何通过反射动态地创建和操作对象。 - **垃圾...
- **层次化 ClassLoader**:这种新的 ClassLoader 结构提高了类加载的灵活性。 - **Legacy API Adapter**:为了兼容旧版本的 API,Drools 提供了一个适配器。 - **KIE 文档**:详细的文档帮助用户更好地理解和...
- **强大的连接池管理**:Mod_Proxy提供了高效的连接池管理机制,确保转发的请求能在统一的连接池中处理,提高了资源利用率。 **1.1.2 NIO** NIO(Non-blocking I/O)是非阻塞I/O的简称,是Java平台处理网络I/O的...
20. **EJB部署文件**:包含ejb-jar.xml和jboss.xml等,描述EJB的元数据,如bean的类型、接口、事务属性等。App Server根据部署文件管理EJB实例。 21. **设计模式**:如单例模式、工厂模式、观察者模式、策略模式、...
- **JVM** 通过 `ClassLoader` 来加载类,主要包括 `Bootstrap ClassLoader`、`Extension ClassLoader` 和 `Application ClassLoader`。 ### 24. 线程模型与线程安全 - **线程模型** 有两种:通过继承 `Thread` 类...
Java应用服务器是指支持Java应用运行的服务器软件,文档中提到了几种常见的Java应用服务器,包括Jboss、Websphere、Weblogic。这些应用服务器对于Java的Web应用开发和企业级应用部署至关重要。例如,Tomcat是一个...