实战分析Tomcat的类加载器结构（使用Eclipse MAT验证）

一、前言

在各种Tomcat相关书籍，书上都提到了其类加载器结构：

 



在Tomcat 7或者8中，共享类和Catalina类加载器在catalina.properties中都是没配置的，请看：



 

所以，catalina和shared是直接把common的类加载器赋值给了它们，这三者其实都是同一个类加载器。

 

这次我们来验证下，方法是通过jmap导出内存堆栈，然后用eclipse 的MAT工具进行分析。

 

二、步骤

 1、获取内存dump

我的tomcat是7.0.68，webapps只有默认的几个应用。

在命令行执行下面语句，获取pid：
ps -ef|grep java
 

然后执行：
jmap -dump:live,format=b,file=heap.bin 此处为pid占位符
 

2、eclipse MAT查找org.apache.catalina.loader.WebappClassLoader

用MAT打开heap.bin后，会让你选择分析的类型，我们选择Component Report即可。

接下来，正式开始分析：

我们知道，tomcat中的应用加载器，类名即为org.apache.catalina.loader.WebappClassLoader。

我们这里，直接用oql语言（eclipse mat中语法）来查询该类的对象：



 



 

可以看到，共有5个对象。



 

5个对象，分别对应了默认的5个应用，manager、host manaer、docs、root、example。

我们选择第一个，查看下图，可知，该classload是为manager应用服务的，其他几个就不一一截图了：



 

 

从上图也可以简单看出来，类加载路径就是简单地去自己context目录下的 WEB-INF/lib 、WEB-INF/classes下查找。

（当然，具体的实现没这么简单，会根据类名称以及delegate
参数，选择是给j2seClassLoader加载（加载jre/lib/ext下的），还是给parent

来加载，还是自己加载。） 

 

3、查看WebappClassLoader 的parent 加载器


按照理论上说，WebappClassLoader的parent，即为common类加载器，主要加载tomcat自己的类，即catalina.base中lib下面的类。

 

我们上图看看：



 

 从图上可以看出来，确实没骗我，加载的类路径确实就是tomcat的lib目录。

 

我们顺便，验证下，common、server、share都执行同一个引用。下图可以看出来，确实没错。



 

 

 4、查看common类加载器的parent


我们继续往上追溯，common的parent，应该是jdk的默认类加载器，类型为sun.misc.Launcher$AppClassLoader，主要负责加载classpath下的东西。

这里，看看我们的classpath是哪个：

 



 

 上图可以看出来，classpath下，只有2个类（忽略greys-agent.jar，那个是调试工具），即bootstrap.jar
和tomcat-juli.jar（Tomcat内部日志）。

 

到这里，我们的验证基本就结束了。

 

三、总结

这里，从第四点，我有一些感想，似乎明白了：

为什么tomcat的启动源码里，即bootstrap类中，一上来就要设置线程上下文类加载器。

 

 

原因就是，BootStrap是应用类加载器加载的，只加载了Bootstrap和tomcat-juli.jar。而tomcat/lib下没法加载。

所以就马上新建了commonLoader，（和catalinLoader、sharedLoader同一个引用），而且设置为线程类加载器，方便进行后续的类加载。

 


说实话，但我觉得，tomcat的bootstrp.jar和tomcat-juli.jar为啥不直接放到lib目录下，大家都直接使用common类加载器算了，搞不懂搞不懂。

今天分享就到这。

 

ps：题外话，为啥上一篇写的openjdk 源码编译、调试的文章，根本没几个人看呢。。。毕生绝学都拿出来了，哭。。

• « 上一篇：程序员如何获取招聘信息
• » 下一篇：用Python爬虫抓取免费代理IP