下面言归正传。
jboss为了实现类的共享引入了class loader repository的概念，并且设计了org.jboss.mx.loading.unifiedclassloader3 (ucl)来完成sharing classes的主要功能。
ucl和unifiedloaderrepository3 一对多的关系，默认情况下一个jboss实例中只有一个unifiedloaderrepository3实例，这个unifiedloaderrepository实例会和所有的ucl关联。
noannotationclassloader是ucl的父classloader用来加载$jboss_home/lib下的jar,system class loader是noannotationclassloader的父classloader。
这几个对象的关系请见下图
从上图可以看出默认情况下所有的ucl共享一个repository，通过repository可以实现class的共享。unifiedloaderrepository3实例中维护着两个容器，一个是class cache：这个容器很明显缓存了一些class，这样可以提高loadclass方法的执行效率；另一个是packagesmap：这个map维护的是类的包名和ucl的mapping关系。具体ucl按什么逻辑load class的请看下面的活动图：
unifiedclassloader3的继承结构如下图所示，unifiedclassloader3的父类repositoryclassloader重写了urlclassloader的loadclass方法，实现了上图的逻辑
下面请看一下相关代码：
repositoryclassloader.java
public class loadclass(string name, boolean resolve) throws classnotfoundexception { boolean trace = log.istraceenabled(); if (trace) log.trace("loadclass " + this + " name=" + name+", loadclassdepth="+loadclassdepth); class clazz = null; try { if (repository != null) { clazz = repository.getcachedclass(name);//先从cache中load class if (clazz != null) { if( log.istraceenabled() ) { stringbuffer buffer = new stringbuffer("loaded class from cache, "); classtostringaction.tostring(clazz, buffer); log.trace(buffer.tostring()); } return clazz; } } //loadclassimpl中会调用的loadmgr3的一些方法实现上面流程图的逻辑，具体的代码实现比较冗长，这里就不贴出来了 clazz = loadclassimpl(name, resolve, integer.max_value); return clazz; } finally { if (trace) { if (clazz != null) log.trace("loadclass " + this + " name=" + name + " class=" + clazz + " cl=" + clazz.getclassloader()); else log.trace("loadclass " + this + " name=" + name + " not found"); } } }
有几点结论可以加深一些印象：
- jboss做为application server可以部署ear包也可以war包。但是jboss在默认情况下处理ear和war是两种class load机制。
- 当部署ear时，jboss默认使用我前面提到的class load机制。一个ear包里的所有的jar由一个ucl统一加载和管理
- 需要注意的是ear里的war的部署有点特别。它只是将自身添加到ucl的classpath域中，而war下的web-inf/lib/*.jar，则是由webappclassloader来加载
由于jboss对所有ucl的共享机制就会导致出现一些class的版本冲突问题，一些应用加载不到自己的应用需要的class。对于这个问题jboss提供了一些解决措施：http://community.jboss.org/wiki/classloadingconfiguration。后面我会再整理一下此前我遇到过的一个class冲突的case和解决办法。
tomcat6/7 class loader机制
tomcat class loader层次结构
tomcat的class load机制较jboss来说要简单
当web应用需要load class时先调用webappclassloader的loadclass方法，loadclass内部逻辑如下：
- 调用findloadedclass(string)检查此class是否已经加载，如果以加载则直接返回，如果没有则继续做下一步。
- 调用system class loader的loadclass的方法，这样可以加载到jdk核心的类，如果没有找到符合的类则继续做下一步。
- 如果webappclassloader的delegate属性是true或者正在处理的class在过滤列表里，会先从父class loader中加载类。如果没有则继续做下一步。一般这一步不会执行。
- webappclassloader在自己的类库（web-inf/classes和web-inf/lib）中查找class。如果没有则继续做下一步。
- 如果前面第3步已经跳过这一步会继续执行。如果前面第3步已经执行过，这一步就不会再执行。这一步的执行逻辑同第3步。
具体的代码可以看webappclassloader.loadclass(..)
参考文档：
http://community.jboss.org/wiki/jbossclassloadingusecases
http://community.jboss.org/wiki/classloadingconfiguration
http://community.jboss.org/wiki/enableclassloaderlogging
http://agapple.iteye.com/blog/791940