为什么tomcat要自定义classloader

一、 提起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