类加载器与Web容器

在关于类加载器中已经介绍了Jvm的类加载机制，然而对于运行在Java EE容器中的Web应用来说，类加载器的实现方式与一般的Java应用有所不同。不同的Web容器的实现方式也会有所不同。

Tomcat中的类加载机制

在Apache Tomcat 中，为了提高系统的灵活性，引入了commonLoader、sharedLoader、catalinaLoader；为了支持和分隔多个web应用，使用了WebappClassLoader。下面以Tomcat7.0的类加载器结构图总体来看大致如下：

   Bootstrap
      |
   System
      |
   Common
   /     \
Webapp1   Webapp2 ...

• Tomcat中的系统类加载器。Tomcat也是一个Java应用，他也是在最初系统提供的几层类加载器环境下运行起来的。那么Tomcat的一些最基本的类，也和其它简单Java应用一样，是通过系统的类加载器来加载的，比如默认配置下的tomcat/bin目录下的bootstrap.jar、tomcat-juli.jar、commons-daemon.jar这几个jar包中的类。
• Tomcat的Common Loader。Common Loader是Tomcat在系统类加载器之上建立起来的，其父loader是系统类加载器。Common Loader负责上面几个jar包外的Tomcat的大部分java类，通常情况下是tomcat/lib下的所有jar包。
• Webapp Class Loader。这个类加载器可以说是Tomcat种最重要的Class Loader，它创造了各个Web app空间。在实现上，它打破了系统默认规则，或者说是打破了java.lang.ClassLoader逻辑中的“双亲委派”模式，提供了一套自定义的类加载流程。默认情况下，对于一个未加载过的类，WebappClassLoader会先让系统加载java.lang.Object等Java本身的基础类，如果不是基础类则优先在当前Web app范围内查找并加载，如果没加载到，再交给common loader走标准的双亲委派模式加载。

那么commonLoader、sharedLoader、catalinaLoader这三个loader各有什么作用呢？在tomcat/conf目录的catalina.properties中有common.loader、server.loader、shared.loader的配置，这分别对应着commonLoader、catalinaLoader和sharedLoader。我们可以看到，默认情况下，serverl.loader和shared.loader的配置是空的，这意味着此两者在运行时和commonLoader相同。实际上，在Tomcat5.5之后的版本中，做了简化，只有commonLoader具备实际意义。而在5.5及之前的版本中，三者各不相同，各有分工。这里我们就不做考虑了。

绝大多数情况下，Web 应用的开发人员不需要考虑与类加载器相关的细节。下面给出几条简单的原则：

• 每个 Web 应用自己的 Java 类文件和使用的库的 jar 包，分别放在 WEB-INF/classes和 WEB-INF/lib目录下面。
• 多个应用共享的 Java 类文件和 jar 包，分别放在 Web 容器指定的由所有 Web 应用共享的目录下面。
• 当出现找不到类的错误时，检查当前类的类加载器和当前线程的上下文类加载器是否正确。

总结

每个 Web 应用都有一个对应的类加载器实例。其加载过程如下图：

   Bootstrap
      |
   System
      |
   Common
   /     \
Webapp1   Webapp2 ...
    |
java.lang.Object等Java基础类
    |
待加载类

在一个web应用中，当需要获取class实例的时候，可以直接获取当前类的类加载器或者获取当前线程中的类加载器。

使用当前类的类加载器是缺省规则：

Class.forName(String)

通过获取当前线程中的类加载器，代码如下：

Class.forName(className, isInitialized, Thread.currentThread().getContextClassLoader());

附录：

关于何时使用线程的上下文加载器？

这是一个很常见的问题，但答案却很难回答。这个问题通常在需要动态加载类和资源的系统编程时会遇到。总的说来动态加载资源时，往往需要从三种类加载器里选择：系统或程序的类加载器、当前类加载器、以及当前线程的上下文类加载器。在程序中应该使用何种类加载器呢？

　　系统类加载器通常不会使用。此类加载器处理启动应用程序时classpath指定的类，可以通过ClassLoader.getSystemClassLoader()来获得。所有的ClassLoader.getSystemXXX()接口也是通过这个类加载器加载的。一般不要显式调用这些方法，应该让其他类加载器代理到系统类加载器上。由于系统类加载器是JVM最后创建的类加载器，这样代码只会适应于简单命令行启动的程序。一旦代码移植到EJB、Web应用或者Java Web Start应用程序中，程序肯定不能正确执行。

　　因此一般只有两种选择，当前类加载器和线程上下文类加载器。当前类加载器是指当前方法所在类的加载器。这个类加载器是运行时类解析使用的加载器，Class.forName(String)和Class.getResource(String)也使用该类加载器。代码中X.class的写法使用的类加载器也是这个类加载器。

　　线程上下文类加载器在Java 2(J2SE)时引入。每个线程都有一个关联的上下文类加载器。如果你使用new Thread()方式生成新的线程，新线程将继承其父线程的上下文类加载器。如果程序对线程上下文类加载器没有任何改动的话，程序中所有的线程将都使用系统类加载器作为上下文类加载器。Web应用和Java企业级应用中，应用服务器经常要使用复杂的类加载器结构来实现JNDI（Java命名和目录接口)、线程池、组件热部署等功能，因此理解这一点尤其重要。

　　为什么要引入线程的上下文类加载器？将它引入J2SE并不是纯粹的噱头，由于Sun没有提供充分的文档解释说明这一点，这使许多开发者很糊涂。实际上，上下文类加载器为同样在J2SE中引入的类加载代理机制提供了后门。通常JVM中的类加载器是按照层次结构组织的，目的是每个类加载器（除了启动整个JVM的原初类加载器）都有一个父类加载器。当类加载请求到来时，类加载器通常首先将请求代理给父类加载器。只有当父类加载器失败后，它才试图按照自己的算法查找并定义当前类。

　　有时这种模式并不能总是奏效。这通常发生在JVM核心代码必须动态加载由应用程序动态提供的资源时。拿JNDI为例，它的核心是由JRE核心类(rt.jar)实现的。但这些核心JNDI类必须能加载由第三方厂商提供的JNDI实现。这种情况下调用父类加载器（原初类加载器）来加载只有其子类加载器可见的类，这种代理机制就会失效。解决办法就是让核心JNDI类使用线程上下文类加载器，从而有效的打通类加载器层次结构，逆着代理机制的方向使用类加载器。

　　顺便提一下，XML解析API(JAXP)也是使用此种机制。当JAXP还是J2SE扩展时，XML解析器使用当前类加载器方法来加载解析器实现。但当JAXP成为J2SE核心代码后，类加载机制就换成了使用线程上下文加载器，这和JNDI的原因相似。

　　好了，现在我们明白了问题的关键：这两种选择不可能适应所有情况。一些人认为线程上下文类加载器应成为新的标准。但这在不同JVM线程共享数据来沟通时，就会使类加载器的结构乱七八糟。除非所有线程都使用同一个上下文类加载器。而且，使用当前类加载器已成为缺省规则，它们广泛应用在类声明、Class.forName等情景中。即使你想尽可能只使用上下文类加载器，总是有这样那样的代码不是你所能控制的。这些代码都使用代理到当前类加载器的模式。混杂使用代理模式是很危险的。

　　更为糟糕的是，某些应用服务器将当前类加载器和上下文类加器分别设置成不同的ClassLoader实例。虽然它们拥有相同的类路径，但是它们之间并不存在父子代理关系。想想这为什么可怕：记住加载并定义某个类的类加载器是虚拟机内部标识该类的组成部分，如果当前类加载器加载类X并接着执行它，如JNDI查找类型为Y的数据，上下文类加载器能够加载并定义Y，这个Y的定义和当前类加载器加载的相同名称的类就不是同一个，使用隐式类型转换就会造成异常。

　　这种混乱的状况还将在Java中存在很长时间。在J2SE中还包括以下的功能使用不同的类加载器：

　　（1）JNDI使用线程上下文类加载器。

　　（2）Class.getResource()和Class.forName()使用当前类加载器。

　　（3）JAXP使用上下文类加载器。

　　（4）java.util.ResourceBundle使用调用者的当前类加载器。

　　（5）URL协议处理器使用java.protocol.handler.pkgs系统属性并只使用系统类加载器。

　　（6）Java序列化API缺省使用调用者当前的类加载器。

　　这些类加载器非常混乱，没有在J2SE文档中给以清晰明确的说明。

　　该如何选择类加载器？

　　如若代码是限于某些特定框架，这些框架有着特定加载规则，则不要做任何改动，让框架开发者来保证其工作（比如应用服务器提供商，尽管他们并不能总是做对）。如在Web应用和EJB中，要使用Class.gerResource来加载资源。

　　在其他情况下，我们可以自己来选择最合适的类加载器。可以使用策略模式来设计选择机制。其思想是将“总是使用上下文类加载器”或者“总是使用当前类加载器”的决策同具体实现逻辑分离开。往往设计之初是很难预测何种类加载策略是合适的，该设计能够让你可以后来修改类加载策略。

以上回答来自深入理解Java类加载器，感兴趣的可以去看看，里面还给了一个类加载策略的实现。

参考

深入探讨 Java 类加载器

Tomcat7源码分析（上）——启动过程和类加载器

深入理解Java类加载器