深入JBoss ClassLoader体系结构

原文：http://blog.csdn.net/youfly/archive/2009/02/12/3884028.aspx

 

 

下图是JBoss class loading体系结构：

上图是JBoss核心ClassLoader组件，它的核心部分是org.jboss.mx.loading.UnifiedClassLoader3(UCL)。 它继承标准的java.net.URLClassLoader，覆盖了标准parent delegation模型以使用共享class和资源仓库。这个共享的仓库是 org.jboss.mx.loading.UnifiedLoaderRepository3。 每一个UCL关联到单一的一个 UnifiedLoaderRepository3 , 并且一个 UnifiedLoaderRepository3 通 常拥有多个UCL。一个UCL可能具有多个URL用来载入class和资源。部署器使用最顶层的部署单元UCL作为它的共享classloader，并且 所有的部署都关联的这个ClassLoader。

当一个UCL请求载入一个类时，它首先去它关联的仓库cache查找，看是否这个类已被 载入。仅当这个类在仓库里不存在时，它才由UCL载入到仓库中。通常的，所有UCL实例共享一个UnifiedLoaderRepository3。 这意味着UCL是一个扁平的ClassLoader。

下面是UnfiedClassLoader3.loadClass(String, boolean)完整的执行序列：


1. 检查UnifiedClassLoader3关联的 UnifiedLoaderRepository3 类 cache。如果类在cache找到，则返回这个类。

2. 否则，检查UnfiedClassLoader3 是否能够载入这个类。它本质上调用了父类URLClassLoader.loadClass(String, boolean) 方法来查看这个类是否存在于当前ClassLoader关联的URL里，或者在当前ClassLoader的父 ClassLoader里。如果类被找到，则将它放到的仓库的Class cache里，并返回找到的类。

3. 否 则，仓库根据包名到UCl的印射查询其他的UCL是否有能力载入这个类。当一一个UCL添加到仓库中时，将建立UCL载入类的包名到当前这个UCL的印射 关系。这就能够快速的确定哪一个UCL能够载入当前类。 然后UCLs根据每个UCL添加到仓库里时指的顺序请求载入指定的类。如果其中一个UCL能够找到这个类，则返回这个类，如果都不能找到，则抛出java.lang.ClassNotFoundException 异 常。