Java和Tomcat类加载机制对比分析

Posted 2021-04-04 架构师技术干货

什么是类加载

在JVM中并不是一次性把所有的文件都加载到，而是一步一步，按照需要来加载。比如JVM启动时，会通过不同的类加载器加载不同的类。当用户在自己的代码中，需要某些额外的类时，再通过加载机制加载到JVM中。

JVM类加载

JVM中采用双亲委派机制进行类加载，如下图

JVM中包括集中类加载器：

1. BootStrapClassLoader 引导类加载器

2. ExtClassLoader 扩展类加载器

3. AppClassLoader 应用类加载器

4. CustomClassLoader 用户自定义类加载器

当JVM运行过程中，用户需要加载某些类时，会按照下面的步骤（双亲委派机制）：

1. 用户自己的类加载器，把加载请求传给父加载器，父加载器再传给其父加载器，一直到加载器树的顶层。

2. 最顶层的类加载器首先针对其特定的位置加载，如果加载不到就转交给子类。

3. 如果一直到底层的类加载都没有加载到，那么就会抛出异常ClassNotFoundException。

因此，按照这个过程可以想到，如果同样在CLASSPATH指定的目录中和自己工作目录中存放相同的class，会优先加载CLASSPATH目录中的文件。

Tomcat类加载

Tomcat中的类加载机制与JVM不同，如下图：

当tomcat启动时，会创建几种类加载器：

1. Bootstrap 引导类加载器：加载JVM启动所需的类，以及标准扩展类（位于jre/lib/ext下）

2. System 系统类加载器：加载tomcat启动的类，比如bootstrap.jar，通常在catalina.bat或者catalina.sh中指定。位于CATALINA_HOME/bin下。

3. Common 通用类加载器：加载tomcat使用以及应用通用的一些类，位于CATALINA_HOME/lib下，比如servlet-api.jar

4. Webapp 应用类加载器：每个应用在部署后，都会创建一个唯一的类加载器。该类加载器会加载位于WEB-INF/lib下的jar文件中的class 和 WEB-INF/classes下的class文件。
   

当应用需要到某个类时，则会按照下面的顺序进行类加载：

1. 使用bootstrap引导类加载器加载

2. 使用system系统类加载器加载

3. 使用应用类加载器在WEB-INF/classes中加载

4. 使用应用类加载器在WEB-INF/lib中加载

5. 使用common类加载器在CATALINA_HOME/lib中加载

Tomcat独特的类加载机制

首先看下Tomcat类加载设计图

可以看到前3个类加载和默认的一致，CommonClassLoader、CatalinaClassLoader、SharedClassLoader和WebappClassLoader则是Tomcat自己定义的类加载器，它们分别加载/common/*、/server/*、/shared/*（在tomcat 6之后已经合并到根目录下的lib目录下）和/WebApp/WEB-INF/*中的Java类库。其中WebApp类加载器和Jsp类加载器通常会存在多个实例，每一个Web应用程序对应一个WebApp类加载器，每一个JSP文件对应一个Jsp类加载器

• commonLoader：Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容器本身以及各个Webapp访问；

• catalinaLoader：Tomcat容器私有的类加载器，加载路径中的class对于Webapp不可见；

• sharedLoader：各个Webapp共享的类加载器，加载路径中的class对于所有Webapp可见，但是对于Tomcat容器不可见；

• WebappClassLoader：各个Webapp私有的类加载器，加载路径中的class只对当前Webapp可见；
  

从图中委派关系中可以得出结论。

CommonClassLoader加载的类都可以被CatalinaClassLoader和SharedClassLoader使用，从而实现公有类库的共用，而CatalinaClassLoader和Shared ClassLoader自己能加载的类与对方相互隔离。WebAppClassLoader可以使用SharedClassLoader加载到的类，但各WebAppClassLoader实例之间相互隔离。而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的Class文件，当Web容器检测到文件被修改时，会替换掉目前的JasperLoader的实例，再建立一个新的Jsp类加载器。

Tomcat违背了Java推荐的双亲委派机制

双亲委派模型要求除了顶层的启动类加载器之外，其余的类加载器都应当由自己的父类加载器加载。Tomcat 为了实现隔离性，没有遵守这个约定，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器。

Q&A

Tomcat的类加载机制是违反了双亲委托原则的，对于一些未加载的非基础类(例如String)，各个web应用自己的类加载器(WebAppClassLoader)会优先加载，加载不到时再交给commonClassLoader走双亲委托。 对于JVM来说，如果同样在CLASSPATH指定的目录中和自己工作目录中存放相同的class，会优先加载CLASSPATH目录中的文件。

• 既然 Tomcat 不遵循双亲委派机制，那么如果我自己定义一个恶意的HashMap，会不会有风险呢？(阿里的面试官问的)

  答：不会有风险，Tomcat不遵循双亲委派机制，只是自定义的classLoader顺序不同，但顶层还是相同的。

• 一个Web容器可能需要部署两个或多个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的类库都是独立的，保证相互隔离

• 部署在同一个Web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程序，那么要有10份相同的类库加载进虚拟机。这是不允许的。

• Web容器也有自己依赖的类库，不能于应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。
  

• Tomcat 如果使用默认的类加载机制行不行？

答：不行。如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认的类加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。默认的类加载器是能够实现的，因为他的职责就是保证唯一性。要怎么实现jsp文件的热部署，jsp 文件其实也就是class文件，如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp是不会重新加载的。可以直接卸载掉这jsp文件的类加载器，所以每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载jsp文件。

---

微信号：topcoder666
长按、关注