为什么tomcat要自定义classloader

sdtf08

　　一、 提起tomcat 中的classloader 莫过于经典的委托机制，上图：
　　
                                                
 
　　不过这个流传于世间的大图为tomcat5的classloader模型，对于目前比较主流的，支持nio 的tomcat7而言，classloader结构也不一样，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里面的类，通常应用程序的类不建议放在里面。默认加载：

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