Tomcat ClassLoader机制介绍

本文旨在介绍JVM的类加载机制；同时分析Tomcat不能采用默认的加载机制的缘由，并对其加载机制作了介绍。

一、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；它负责加载应用程序主函数类；

二、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，但其加载策略和默认的类加载机制不太同样；

三、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加载；

简单画了一下加载顺序，能够参考一下：