本文旨在介绍JVM的类加载机制;同时分析Tomcat不能采用默认的加载机制的原因,并对其加载机制做了介绍。

1、JVM中的类加载机制

在Java2之后的版本中,类的加载采用的是一种称为双亲委派的代理模型:也就是说当前ClassLoader在加载类前,先委派给双亲去加载类;

在有双亲委派模式的情况下,启动类装载器可以抢在标准扩展类装载器之前去装载类,而标准扩展类装载器可以抢在系统类装载器之前去装载那个类,类路径类装载器又可以抢在用户自定义类装载器之前去装载它,用这种方法,类装载器的体系结构就可以防止不可靠的代码用它们自己的版本来替代可信任的类。

  • Bootstrap class loader:最顶级的class loader,采用native code实现,是JVM的一部分;它负责加载核心的Java包,如java.lang.*、java.uti.*等; 这些类位于$JAVA_HOME/jre/lib/rt.jar;
  • Extension class loader:扩展的class loader,加载位于$JAVA_HOME/jre/lib/ext目录下的扩展jar;
  • System class loader:系统class loader,加载$CLASSPATH下的目录和jar;它负责加载应用程序主函数类;

 

2、Tomcat中的类加载

当一个Servlet直接代理类装载请求给System class loader,则一个Context会加载其它Context下的类;因此每个Context必须要有自己的类装载器,用于装载WEB-INF/classes和WEB-INF/lib下的类;

当Context需要装载类时,先试着装载位于WEB-INF/classes和WEB-INF/lib下的类;如果装载失败,则再代理给上级class loader;

  • Common class loader:负责装载$CATALINA_HOME/common目录下的所有类和jar包,详细的配置可参考$CATALINA_HOME/conf/catalina.properties文件中的common.loader配置;该class loader装载的类对于Server class loader和Webapp class loader是可见的;Common class loader在Tomcat启动时创建,其parent class loader是System class loader;
  • Server class loader:负责装载Tomcat的核心类,位于$CATALINE_HOME/server目录下的所有类和jar,可由catalina.propreties中的server.loader配置指定;它在Tomcat启动时被创建,其parent loader是Common class loader;
  • Shared class loader:负责装载web app公用的类,可以用户通过catalina.properties文件中的shared.loader属性来指定;它在Tomcat启动时被创建,其parent loader也是Common class loader;
  • Webapp class loader:这个比较特殊,它只负责加载各自app中WEB-INF/classes以及WEB-INF/lib下的类;其parent loader虽然是Shared class loader,但其加载策略和默认的类加载机制不太一样;

 

3、Webapp class loader

其类加载策略如下:

1) 先看之前有没有加载过此类,如果加载过,直接从缓存中取出Class;

2) 如果之前没有加载过,则直接委托System class loader加载(防止应用程序替换信任类),而System class loader会按默认的双亲委派模式加载;

3) 如果System class loader加载失败,则试图在当前应用程序的WEB-INF/classes和WEB-INF/lib目录下加载(对于一些特殊的类,可能会先委托给Shared class loader加载);

4) 如果自己加载失败,则最后委托给Shared class loader加载;

简单画了一下加载顺序,可以参考一下:

载器与 Web 容器

对于运行在 Java EE™容器中的 Web 应用来说,类加载器的实现方式与一般的 Java 应用有所不同。不同的 Web 容器的实现方式也会有所不同。以 Apache Tomcat 来说,每个 Web 应用都有一个对应的类加载器实例。该类加载器也使用代理模式,所不同的是它是首先尝试去加载某个类,如果找不到再代理给父类加载器。这与一般类加载器的顺序是相反的。这是 Java Servlet 规范中的推荐做法,其目的是使得 Web 应用自己的类的优先级高于 Web 容器提供的类。这种代理模式的一个例外是:Java 核心库的类是不在查找范围之内的。这也是为了保证 Java 核心库的类型安全。

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

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