深入浅出“类加载器” 之「案例分析:Tomcat 类加载器架构」

Posted by tomas家的小拨浪鼓 on November 8, 2019

深入浅出“类加载器” 之「案例分析:Tomcat 类加载器架构」

本文主要是《深入探索 JVM》系列中『类加载器』系列文章,通过 Tomcat 类加载器架构的分析来对类加载器有一个更‘生动’的了解。系列文章目录见:《 深入探索 JVM 》文集


『类加载器』篇文章推荐:
深入浅出“类加载器” 之「类加载机制(上)」
深入浅出“类加载器” 之「类加载机制(下)」
深入浅出“类加载器” 之「线程上下文类加载器」
深入浅出“类加载器” 之「从 sun.misc.Launcher 类源码深入探索 ClassLoader」
深入浅出“类加载器” 之「案例分析:Tomcat 类加载器架构」


一,Tomcat 类加载器架构

主流的Java Web服务器,都实现了自己定义的类加载器(一般都不止一个)。因为一个功能健全的Web服务器,要解决如下几个问题:

① 部署在同一个服务器上的两个Web应用程序所使用的Java类库可以实现相互隔离。
这是最基本的需求,两个不同的应用程序可能会依赖同一个第三方类库的不同版本,不能要求一个类库在一个服务器中只有一份,服务器应当保证两个应用程序的类库可以互相独立使用。

② 部署在同一个服务器上的两个Web应用程序所使用的Java类库可以互相共享。
这个需求也很常见,例如,用户可能有10个使用Spring组织的应用程序部署在同一台服务器上,如果把10份Spring分别存放在各个应用程序的隔离目录中,将会是很大的资源浪费——这主要倒不是浪费磁盘空间的问题,而是指类库在使用时都要被加载到服务器内存,如果类库不能共享,虚拟机的方法区就会很容易出现过度膨胀的风险。

③ 服务器需要尽可能地保证自身的安全不受部署的Web应用程序影响。
目前,有许多主流的Java Web服务器自身也是使用Java语言来实现的。因此,服务器本身也有类库依赖的问题,一般来说,基于安全考虑,服务器所使用的类库应该与应用程序的类库互相独立。

④ 支持JSP应用的Web服务器,大多数都需要支持HotSwap功能。


由于存在上述问题,在部署Web应用时,单独的一个ClassPath就无法满足需求了,所以各种Web服务器都“不约而同”地提供了好几个ClassPath路径供用户存放第三方类库,这些路径一般都以”lib”或”classes”命名。
通常,每一个目录都会有一个相应的自定义类加载器去加载放置在里面的Java类库。


  • 在Tomcat目录结构中,有4组目录:
    ①「/common」目录中:类库可被Tomcat和所有的Web应用程序共同使用。
    ②「/server」目录中:类库可被Tomcat使用,对所有的Web应用程序都不可见。
    ③「/shared』目录中:类库可被所有的Web应用程序共同使用,但对Tomcat自己不可见。
    ④「/WebApp/WEB-INF」目录中:类库仅仅可以被此Web应用程序使用,对Tomcat和其他Web应用程序都不可见。

为了支持这套目录结构,并对目录里面的类库进行加载和隔离,Tomcat自定义了多个类加载器,这些类加载器按照经典的双亲委派模型来实现。


「CommonClassLoader」:加载「/common/*」中的Java类库
「CatalinaClassLoader」:加载「/server/*」中的Java类库
「SharedClassLoader」:加载「/shared/*」中的Java类库
「WebappClassLoader」:加载「/WebApp/WEB-INF/*」中的Java类库
「JasperLoader」:加载JSP文件

其中WebApp类加载器(WebappClassLoader)和Jsp类加载器(JasperLoader)通常会存在多个实例,每一个Web应用程序对应一个WebApp类加载器,每一个JSP文件对应一个Jsp类加载器。

JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个Class,它出现的目的就是为了被丢弃:当服务器检测到JSP文件被修改时,会替换掉目前的JasperLoader的实例,并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。

对于Tomcat的6.x版本,只有指定了tomcat/conf/catalina.properties配置文件的server.loader和share.loader项后才会真正建立CatalinaClassLoader和SharedClassLoader的实例,否则会用到这两个类加载器的地方都会用CommonClassLoader的实例代替,而默认的配置文件中没有设置这两个loader项,所以Tomcat 6.x顺理成章地把/common、/server和/shared三个目录默认合并到一起变成一个/lib目录,这个目录里的类库相当于以前/common目录中类库的作用。这是Tomcat设计团队为了简化大多数的部署场景所做的一项改进,如果默认设置不能满足需要,用户可以通过修改配置文件指定server.loader和share.loader的方式重新启用Tomcat 5.x的加载器架构。