本文旨在介绍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加载；
简单画了一下加载顺序，可以参考一下：
若转载请注明出处！若有疑问，请回复交流！
