JVM：Tomcat中的类加载

Posted 2021-04-18 漫步君

在Class文件格式与执行引擎这一部分中，用户的程序能直接影响的内容并不太多，Class文件以何种格式存储、类型何时加载、如何连接以及虚拟机如何执行字节码指令等，都是由虚拟机直接控制的行为，用户程序无法对其进行改变。而能通过程序进行操作的，主要是字节码生成与类加载器这两部分的功能。

接下来我们以主流的Java Web服务器中的Tomcat为例，详细解释类加载的过程。

 

一个功能健全的Web服务器要解决如下几个问题：

1.部署在同一个服务器上的两个Web应用程序所使用的Java类库可以实现相互隔离。

2.部署在同一个服务器上的两个Web应用程序所使用的Java类库可以相互共享。

3.服务器要尽可能的保证自身的安全不受部署的Web应用程序影响。

4.支持Jsp应用的Web服务器，大多数都需要支持HotSwap（热加载）功能。

由于存在上述问题，在部署Web应用是，单独的一个ClassPath就无法满足要求了，所以各种Web服务器都提供了好几个Class路径供用户存放第三方类库，一般以lib或者classes命名。被放置到不同路径中的类库，具备不同的访问范围和服务对象，通常每一个目录都会有一个相应的自定义类加载器去加载放置在里面的Java类库。

以Tomcat例：Tomcat的早期结构中（Tomcat5.x及之前），有三组目录common、server、shared，可以存放Java类库，另外还可以加上Web应用程序自身的目录WEB-INF一共4组，把Java类库放置在这些目录中的含义分别如下：

>放置在common目录中：类库可以被Tomcat和所有的Web应用程序共同使用。

>放置在server目录中：类库可以被Tomcat使用，对所有的Web应用程序都是不可见的。

>放置在shared目录中：类库可以被所有的Web应用程序共同使用，但对Tomcat自己不可见。

>放置在webapps/WEB-INF中：类库仅仅可以被此web应用程序使用，对Tomcat和其他Web应用程序都不可见。

为了支持这套目录结构，Tomcat自定义多个类加载器，并按照经典的双亲委派模型来实现：

>其中每个Web应用程序对应一个WebApp类加载器。

>每个JSP文件对应一个Jsp类加载器。

>CommomClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用，而这两个自己能加载的类则与对方相互隔离。

>WebAppClassLoader可使用SharedClassLoader加载的类，但各个WebAppClassLoader实例之间相互隔离。

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

 

对于Tomcat6.x以及以后版本，只有指定了/conf/catalina/properties配置文件的server.loader和shared.loader项后才会真正建立CatalinaClassLoader和SharedClassLoader实例，否则会由CommonClassLoader替代，默认配置文件中没有这两项。

Tomcat6.x以后把common、server、shared这三个目录默认合并到一起变成一个lib目录

这个目录相当common目录中类库的作用。如果默认设置不能满足要求，用户可以通过修改配置文件指定server.loader和share.loader的方式重新启用Tomcat5.x的加载架构。

随笔，是记忆的一种延伸