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

Java框架

浏览数:163

2019-6-26

AD:资源代下载服务

一、前言

在各种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 源码编译、调试的文章,根本没几个人看呢。。。毕生绝学都拿出来了,哭。。

作者:三国梦回