深入JBoss ClassLoader体系结构

 下图是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异常。