由于tomcat相对比较庞大我们无法去细细研究tomcat的所有实现细节。所以我打算只关注tomcat四到五个核心技术实现细节。不再关注其他的旁支末节。因为之前的文章写过java类加载器，秉承知识的连续性，我们今天就来研究一下tomcat中的类加载实现机制。
首先我们打开idea，找到tomcatBootstrap类的main方法。这里是整个tomcat的入口main方法。
我们看到tomcat的main方法里只做了两件事。第一件是执行init方法。第二件事是监听各种启动、关闭命令。我们只需要关注init方法里类加载器的初始化就可以了。我们进入init方法里看看。
继续进入intitClassLoaders方法。
我们看见在这个方法里有三个类加载器，分别为commonLoader、catalinaLoader、sharedLoader。并且明白了他们的父子关系现在我们得到他们的关系如下
那么到这里tomcat所有类加载器就完了吗？同学们，还是太年轻啊。如果到这里就完了的话，那tocmat作为一个servlet容器就至少有两个问题没有解决。1 各个web应用jar包冲突。如tomcat想部署两个web程序。两个程序都用了spring框架，但是用的spring版本不一样。在这样情况下，如此的的类加载器显然不能满足这种需求，因为类加载器只能加载一次spring相关jar包。所有至少需要一个类加载器能隔离web应用之间的jClass，这是其一，我们就姑且交叫这个类加载器为webappClassLoader吧（实际上，它就叫webappClassLoader，哈哈）。2 我们知道，tocmat是支持jsp的热部署的，但是我们知道ClassLoader在加载过jsp对应的Servlet后就不会再次加载了，那么怎么实现jsp的热部署呢？把加载Servlet的ClassLoader也同时卸载掉就行了！再用新的classLoader再次加载jsp就可以实现。如果真的有这么一个类加载器的话，我们姑且就把这个类加载器称为jaspLoader吧（实际上，它也就叫jaspLoader），所以一个jsp对应一个JaspLoader！！！。jsp简直是皇帝般的待遇，有自己的独栋别墅。
通过我们上面的分析我们知道tomcat肯定还有隐藏的。下次我们就把它们找出来！！！
-----------------------------------------------------------完美的分界线接上更新----------------------------------------------------------
WebappClassLoader由于是web 应用的私有类加载器。所以它的构建过程在Context容器中（虽然还没有开始研究Context相关源码，但通过Context绑定一个WebappClassLoader是不是可以反向推导出一个Context对应一个web应用！tomcat中server.xml中关于Context的配置也从侧面说明这一点）。
我们来看看StandardContext（Context的标准实现类）中关于WebappClassLoader的部分。
这部分代码在StandardContext的startInternal方法中。如果我们将这段代码得二行getParentClassLoader()方法获取到classLoader对象打印出来会发现它和我们上面构建的sharedLoader是一个对象。WebappClassLoader的父类加载器是sharedLoader。我们还要关注一下WebappClassLoader.start()方法。它集成子它的父类WebappClassLoaderBase的start方法
我们看到了熟悉的WEB-INF/classes 和/WEB-INF/lib，我明白了tomcat下的工程目录为什么要这样了。
JaspLoader呢？
我们再来看看它的父类加载器是什么？进入getClassLoader方法
可以看到JaspLoader的父加载器是从线程中获取的。那么是谁？
是webApplicationClassLoader至此我们已经对tomcat的类加载完全了解。