一、提起tomcat 中的classloader 莫过于经典的委托机制，
不过这个流传于世间的大图为tomcat5的classloader模型，对于目前比较主流的，支持nio 的tomcat7而言，classloader结构也不一样
二、研究tomcat的类加载器结构之前，我们先来关注一下JVM中的classloader机制：
jvm中默认定了三种classloader，分别为：bootstrap classloader， extension classloader, system classloader.
bootstrap 使用c语言来实现，没有对应的ClassLoader对象。
该方法String.class.getClassLoader() 返回null。
extension 用于从jre/lib/ext 目录加载“标准的扩展”。
system 用于加载应用类。由classpath环境变量中的 jar/zip 文件。
除此之外，java的classloader采用委托机制，即classloader都有一个 parent classloader。当收到一个类加载请求时，会先请求parent classloader加载类，如果parent classloader家在不到，再由自身尝试加载（如果加载不到，throw ClassNotFountException). 这种机制主要是出于安全考虑，如果用户自定义一个java.lang.Object 不至于覆盖jdk中的Object。
当然万事万物无绝对。OSGI就违反了这个原则。
三、那么Tomcat为什么要自定义ClassLoader呢？
我认为主要出于两方面原因：
1、Servlet规范中对于类加载器的要求
2、实现不同web app 的类隔离。
各个classloader作用说明：
1、bootstrap / extension： 加载$JAVA_HOME/jre/lib/ext下的类
2、system： 加载由CLASSPATH初始化的所有类，对于tomcat自身类以及所有web应用的类可见。但是查看tomcat标准的启动脚本$CATALINA_HOME/bin/catalina.bat， 完全无视CLASSPATH，直接加载tomcat中的3个jar包。
3、Common： 对于tomcat，和所有web app 可见，用于加载$CATALINA_BASE/conf/catalina.properties里面的类，通常应用程序的类不建议放在里面。默认加载：
Properties代码 收藏代码
common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
4、WebappX： 加载所有WEB-INF/classes下面的类以及里面的jar。
该classloader有意违背了委托原则。它首先看WEB-INF/classes中是否有请求的类，而不是委托parent classloader去处理，但是jre 和servlet api 不会被覆盖。
以上就是对于tomcat 中的classloader的简单总结介绍。
参考tomcat官方资料：
http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html