在上文中，已经介绍了 系统类加载器 以及类加载器的相关机制，还自定制类加载器的方式。接下来就以tomcat6为例看看tomat是如何使用自定制类加载器的。（本介绍是基于tomcat6.0.41，不同版本可能存在差异！）
网上所描述的tomcat类加载器
在网上搜一下“tomcat类加载器”会发现有大量的文章，在此我偷个懒，^_^把网上对tomcat类加载器的描述重说一下吧。
- CommonClassLoader：加载的类目录通过{tomcat}/conf/catalina.properties中的common.loader指定，以SystemClassLoader为parent(目前默认定义是common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar)
- CatalinaClassLoader ：加载的类目录通过{tomcat}/conf/catalina.properties中server.loader指定，以CommonClassLoader为parent，如果server.loader配置为空，则ServerClassLoader 与CommonClassLoader是同一个(默认server.loader配置为空)
- SharedClassLoader：加载的类目录通过{tomcat}/conf/catalina.properties中share.loader指定，以CommonClassLoader为parent，如果server.loader配置为空，则CatalinaClassLoader 与CommonClassLoader是同一个(默认share.loader配置为空)
- WebappClassLoader：每个Context一个WebappClassLoader实例，负责加载context的/WEB-INF/lib和/WEB-INF/classes目录，context间的隔离就是通过不同的WebappClassLoader来做到的。由于类定义一旦加载就不可改变，因此要实现tomcat的context的reload功能，实际上是通过新建一个新的WebappClassLoader来做的，因此reload的做法实际上代价是很高昂的，需要注意的是，JVM内存的Perm区是只吃不拉的，因此抛弃掉的WebappClassLoader加载的类并不会被JVM释放，因此tomcat的reload功能如果应用定义的类比较多的话，reload几次就OutOfPermSpace异常了。
- JasperLoader：每个JSP一个JasperLoader实例，与WebappClassLoader做法类似，JSP支持修改生效是通过丢弃旧的JasperLoader，建一个新的JasperLoader来做到的，同样的，存在轻微的PermSpace的内存泄露的情况
以上对个个classloader的作用做了介绍，但请读者不要搞混淆了，上边说的个个类加载器只是类加载器的名字，不是类加载类的名字。上边的图是看到网上资料的说明绘制的，但是与实际源码中的结构还是差异挺大的。（没有研究是不是因为tomcat的版本所致）。下面就详细介绍下tomcat源码中类加载器的组织结构。
tomcat源码中类加载器的结构分析
首先要说明是tomcat默认配置下的情况。那接下来看看tomcat启动时的类初始化情况，这是BootStrap类的类初始化方法：
可以看到，在创建commonLoader时传的父类加载器是null。跟踪下去会发现commonLoader的父类加载器确实是null。有朋友可能想，tomcat在启动时肯定也要依赖jdk核心库，parent是null那怎么委托给parent去加载核心库的类了啊。这里大家不要忘了ClassLoader类的loadClass方法：
通过以上initClassLoaders方法我们也能看到catalinaLoader和sharedLoader的父类加载器都是commonLoader，跟上边图的类加载器结构符合。但是commonLoader、catalinaLoader和sharedLoader的创建都是依赖tomcat安装目录下conf/catalina.properties的配置。默认情况配置是：
- common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
- server.loader=
- shared.loader=
由于server.loader和shared.loader的配置为空，所以其实commonLoader、catalinaLoader和sharedLoader都是指向同一个类加载器实例，看代码如下：（限于篇幅只贴部分代码）
而他们指向那个类加载器类的实例呢？跟踪到最后我们发现如下代码：
就是StandardClassLoader的实例，下文再对StandardClassLoader进行源码讲解。
接下来再看看webappclassloader的创建过程，webappclassLoader是在WebappLoader类中的createClassLoader方法中通过反射实例化的。下边是源代码：
可以看到他的parent是通过调用container.getParentlassLoader()获得的（如果对tomcat的结构不熟悉，请看这篇 文章 ）跟踪到最后我们发现它调用了ContainerBase的这个方法：
通过默认配置下debug可以知道最后是返回的systemclassloader，也就是说WebappClassLoader的父类加载器是systemclassloader也就是 上篇文章 说的App ClassLoader。
（由于JasperLoader本人还没有做分析，先不进行讲解了）
tomcat类加载器的实现方式分析
上文说到了commonLoader、catalinaLoader和sharedLoader都是指向StandardClassLoader的实例，来先看一看StandardClassLoader的源码实现：
有没有感到你的意外啊，对的就是这么简单，这跟我 上篇文章 说的最简单的实现方式一样。（上篇文章做了解读，这里不再做说明了）
我们再来看看webappclassLoader，他的实现类就是org.apache.catalina.loader.WebappClassLoader，此类加载器也是继承自URLClassLoader，但是它覆盖了loadClass方法和findClass方法。这个类有三千多行这里就不将代码全部贴出来了。
