前言
上篇文章《Tomcat优化-深入Tomcat底层原理》我们从宏观上分析了一下Tomcat的顶层架构以及核心组件的执行流程。本篇文章我们从源码角度来分析Tomcat的类加载机制，且看它是如何打破JVM的ClassLoader双亲委派的
Tomcat ClassLoader 初始化
Tomcat的启动类是在 org.apache.catalina.startup.Bootstrap#main中，通过执行main方法来启动，该方法中会创建一个Bootstrap对象，然后执行Bootstrap.init()方法来进行初始化。同时该方法中维护了 Bootstrap 的 start ，stop等生命周期方法的入口，源码如下
public static void main(String args[]) {
synchronized (daemonLock) {
if (daemon == null) {
// Don't set daemon until init() has completed
Bootstrap bootstrap = new Bootstrap();
try {
//1.初始化Tomcat
bootstrap.init();
} catch (Throwable t) {
handleThrowable(t);
log.error("Init exception", t);
return;
}
daemon = bootstrap;
} else {
// When running as a service the call to stop will be on a new
// thread so make sure the correct class loader is used to
// prevent a range of class not found exceptions.
Thread.currentThread().setContextClassLoader(daemon.catalinaLoader);
}
}
try {
String command = "start";
if (args.length > 0) {
command = args[args.length - 1];
}
//触发startd指令
if (command.equals("startd")) {
args[args.length - 1] = "start";
daemon.load(args);
daemon.start();
//触发 stop执行
} else if (command.equals("stopd")) {
args[args.length - 1] = "stop";
daemon.stop();
} else if (command.equals("start")) {
daemon.setAwait(true);
daemon.load(args);
daemon.start();
if (null == daemon.getServer()) {
System.exit(1);
}
} else if (command.equals("stop")) {
daemon.stopServer(args);
} else if (command.equals("configtest")) {
daemon.load(args);
if (null == daemon.getServer()) {
System.exit(1);
}
System.exit(0);
} else {
log.warn("Bootstrap: command \"" + command + "\" does not exist.");
}
} catch (Throwable t) {
// Unwrap the Exception for clearer error reporting
if (t instanceof InvocationTargetException && t.getCause() != null) {
t = t.getCause();
}
handleThrowable(t);
log.error("Error running command", t);
System.exit(1);
}
}
下面我们切入到bootstrap#init初始化方法中，该方法中会调用 initClassLoaders初始化Tomcat自定义的类加载器，下面我们可以看到三个类加载器分别是：commonLoader，catalinaLoader，sharedLoader。三个类加载器创建好之后，会通过catalinaLoader加载 Catalina.class并实例化它。并把sharedLoader作为Catalina的setParentClassLoader父类加载器。如下：
//Tomcat中自定义的classLoader
ClassLoader commonLoader = null;
ClassLoader catalinaLoader = null;
ClassLoader sharedLoader = null;
//初始化ClassLoader
private void initClassLoaders() {
try {
commonLoader = createClassLoader("common", null);
if (commonLoader == null) {
// no config file, default to this loader - we might be in a 'single' env.
commonLoader = this.getClass().getClassLoader();
}
catalinaLoader = createClassLoader("server", commonLoader);
sharedLoader = createClassLoader("shared", commonLoader);
} catch (Throwable t) {
handleThrowable(t);
log.error("Class loader creation threw exception", t);
System.exit(1);
}
}
//初始化bootstrap
public void init() throws Exception {
//初始化类加载器
initClassLoaders();
Thread.currentThread().setContextClassLoader(catalinaLoader);
SecurityClassLoad.securityClassLoad(catalinaLoader);
// Load our startup class and call its process() method
if (log.isTraceEnabled()) {
log.trace("Loading startup class");
}
//加载 Catalina 类
Class<?> startupClass = catalinaLoader.loadClass("org.apache.catalina.startup.Catalina");
//实例化 Catalina 对象
Object startupInstance = startupClass.getConstructor().newInstance();
// Set the shared extensions class loader
if (log.isTraceEnabled()) {
log.trace("Setting startup class properties");
}
String methodName = "setParentClassLoader";
Class<?> paramTypes[] = new Class[1];
paramTypes[0] = Class.forName("java.lang.ClassLoader");
Object paramValues[] = new Object[1];
paramValues[0] = sharedLoader;
//调用 Catalina的setParentClassLoader，为Catalina设置 parent 类加载器
Method method = startupInstance.getClass().getMethod(methodName, paramTypes);
method.invoke(startupInstance, paramValues);
catalinaDaemon = startupInstance;
}
JVM ClassLoader 双亲委派
这里看起来会有些懵逼，如果要理解Tomcat的类加载机制就要先理解JVM的类加载机制。下面是JVM的类加载器
在JVM中分为启动类加载器，扩展类加载器，应用程序类加载器，和自定义加载器4类，他们分别加载
- 启动类加载器：加载 jre/lib 目录下的jar包，其中包括了java的基本环境，比如：java.lang，java.io 等包下的基础类
- 扩展类加载器：加载 jre/lib/ext 目录下的jar包，也是java自带的一些基础包
- 应用程序类加载器：加载classpath下的代码，也就是我们自己的代码，以及pom中导入的jar
- 自定义加载器：程序员自己定义的类加载器，按照程序员指定的需求进行加载
JVM的这些类加载器遵循双亲委派设计模式进行类的加载，大概的含义是子加载器优先委派父加载器进行加载父加载器没有加载子加载器才加载比如：AppClassLoader加载之前会先调用父加载器ExtClassLoader的加载方法，而ExtClassLoader加载之前会调用BootstrapClassLoader方法优先进行加载，也就形成了加载顺序其实是从上往下进行加载，如果父加载器加载了某个类，子加载器将不再会加载。在Jvm中提供了一个类加载器的顶层类java.lang.ClassLoader ,所有的类加载器都是他的之类，他里面维护了一个 private final ClassLoader parent; 字段和loadClass方法
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
//1.首先，检查类是否已加载
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
//如果父类加载器不为空，则优先委派父类进行加载
if (parent != null) {
c = parent.loadClass(name, false);
} else {
//如果父类加载器为空，则查找 Bootstrap 类加载器，如果找不到则返回null
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
//如果c == null 说明父类加载失败，则自己加载
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
这里需要注意的一点是：这些类加载器是没有继承关系的，而是通过维护一个parent成员变量来体现父子关系(组合模式)。上面代码的大意是
- 首先ClassLoader会检查某个class是否已经被加载，已经加载的类会存储到JVM中，则无需加载直接返回Class，这里是使用c++去实现的
- 如果父类加载器加载结果为null,则会调用自己的类加载器方法findClass去加载
这里是典型的双亲委派设计模式，这样设计有什么目的呢？一个是为了防止类重复加载，二个是安全性问题
- 防止类重复加载：父类加载器如果已经加载了某个class,那么子类加载器将不再会加载
- 安全性问题 ： 试想如果我们自己写了一个类
java.lang.String那么jvm会不会采用我们的String而不采用JDK自己带的String呢，答案是不会的。因为BootStrapClassLoader 优先把String加载进JVM中，我们自己的String根本就不会生效。
Tomcat Class Loader 打破双亲委派
对于Tomcat而言它是打破了JVM的双亲委派的。他自定义了自己的类加载器如下：
Tomcat定义了自己的类加载器去打破双亲委派，它主要解决3个问题
- 一个Tomcat需要加载不同的项目代码，那么不同的项目中肯定有相同名字的类，但是功能又不同，这些类如何做代码隔离
- 一个Tomcat需要加载不同的项目代码，对于一些公共的类，在不同的项目中否需要重复加载？答案是否定的，否则JVM会日益膨胀，那么如何做到公共的class只加载一份呢，并且不同的项目需要共享这些公共的class.
- Tomcat本省的代码也是需要类加载器去加载
要解决这些问题就需要说道Tomcat自定义的ClassLoader了他们的职责如下
- commonLoader : 加载基础的类，这些类是tomcat和app项目共用的，在catalina.properties中定义了common.loader属性该属性指定一些lib路径，CommonLoader会从这些目录中加载一些基础的class。
- catalinaLoader ：加载Tomcat私有的类，app项目不可见，在catalina.properties中定义了server.loader属性该属性指定一些lib路径，catalinaLoader会从这些目录中加载class。
- sharedLoader ： 加载共享的类，多个app项目都可见，在catalina.properties中定义了shared.loader属性该属性指定一些lib路径，catalinaLoader会从这些目录中加载class。
- WebappClassLoader ：：每个 Web 应用程序都有一个与之关联的 Web 应用程序类加载器。它负责加载 Web 应用程序自身的类库，专门负责加载servelt应用，每个应用都有自己的WebappClassLoader，相互隔离，但它并不遵循双亲委派模型
WebappClassLoader ： 实现项目隔离
WebappClassLoader是针对每个Servlet项目都有一个，这样可以实现项目之间的相互隔离，比如不同的项目中都用到Spring,但是他们使用的Spring版本不一杨，有了WebappClassLoader之后也能相安无事，因为class是相互隔离的。所以：不同的加载器加载的类是认为不同的，那怕类名是相同的。而如果同一个ClassLoader中出现了2个相同的类，ClassLoader也只会加载一次
SharedClassLoader ： 实现class共享
多个项目之间势必有一些共享的类，Tomcat是如何实现不同app之间类的共享的类，SharedClassLoader 作为 WebappClassLoader的父类加载器，如果WebappClassLoader没有加载到某个类(这个类可能是共享的)就会委托父类加载器 SharedClassLoader去加载，SharedClassLoader会在指定目录下加载一些共享的类返回给WebappClassLoader，这样就实现了不同的项目之间共享类。
CatalinaClassloader ：实现Tomcat私有加载
Tomcat自身的类并没有使用WebappClassLoader来加载，而是专门设计了一个CatalinaClassloader来加载，这样就可以实现Tomcat本身的类和APP的类进行隔离，那么如果Tomcat和APP之间需要共享一些类怎么办呢？Tomcat设计了commonLoader类加载器来实现 Tomcat和各个APP之间的类共享。commonLoader作为CatalinaClassloader 和 SharedClassLoader的父加载器，CommonClassLoader 能加载的类都可以被 CatalinaClassLoader 和SharedClassLoader 使用，而 CatalinaClassLoader 和 SharedClassLoader 能加载的类则与对方相互隔离。WebAppClassLoader 可以使用 SharedClassLoader 加载到的类，但各个WebAppClassLoader 实例之间相互隔离。
下面我们来看一下 WebAppClassLoader 是如何加载Class的，核心代码在其父类：org.apache.catalina.loader.WebappClassLoaderBase#loadClass(java.lang.String, boolean)，源码如下
public Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
Class<?> clazz = null;
...
// (0) Check our previously loaded local class cache
//（0） 检查我们之前加载的本地类缓存
clazz = findLoadedClass0(name);
//拿到JAVA的类加载器 ExtClassLoader
ClassLoader javaseLoader = getJavaseClassLoader();
...
//委派JavaSe的ExtClassLoader去尝试加载
clazz = javaseLoader.loadClass(name);
...
//调用自己的findClass来加载
clazz = findClass(name);
}
上面代码我精简了一下，大概流程是
- 先从缓存中去检查该类是否已经被加载，如果已经加载了就会直接返回不会再加载
- 会找到Java的ExtClassLoader去加载，为什么呢？因为所有类都需要一个Object.class才可以使用，所以必须先加载JDK一些基础的东西。但是这里没有使用Java的AppClassLoader去加载，如果使用AppClassLoader去加载那就没有打破双亲委派，很显然这里打破了。
- 如果ExtClassLoader加载不到那么这个类可能是我们自己的类的，就会调用findClass方法去加载
下面是org.apache.catalina.loader.WebappClassLoaderBase#findClass 源码
public Class<?> findClass(String name) throws ClassNotFoundException {
//在内部找class
clazz = findClassInternal(name);
...
if (clazz == null && hasExternalRepositories) {
try {
//委托父类加载
clazz = super.findClass(name);
...
}
//父类也没找到就抛出异常
if (clazz == null) {
if (log.isTraceEnabled()) {
log.trace(" --> Returning ClassNotFoundException");
}
throw new ClassNotFoundException(name);
}
}
这里的大概含义就是：现在项目内部加载class,如果自己没加载到再委托父加载器去加载。稍微归纳一下加载流程如下
- 先检查缓存，确定该类是否已经被加载
- 委托ExtClassLoader去加载(需要JDK环境)
- 调用findClass 自己去加载
- 找不到再委托super父类加载器去加载
总结：为什么Tomcat需要打破双亲委派
Tomcat 并没有完全打破 Java 的双亲委派模型，而是对其进行了扩展和补充，以适应 Web 应用程序的特殊需求。Tomcat 打破双亲委派模型的主要原因有以下几点：
- 隔离性：
Web 应用程序通常希望自己的类库（位于 WEB-INF/lib 和 WEB-INF/classes 目录下）与容器提供的类库和其他应用程序的类库完全隔离。如果完全遵循双亲委派模型，那么应用程序可能会意外地加载到容器或其他应用程序的类，导致版本冲突或不可预期的行为。 - 热替换和重新加载：
Tomcat 支持在不重启整个容器的情况下重新加载或替换 Web 应用程序。为了实现这一功能，Tomcat 需要为每个 Web 应用程序提供一个独立的类加载器，以便能够单独卸载和重新加载应用程序的类。 - 自定义类加载：
Tomcat 允许管理员通过配置来指定额外的共享库（位于 CATALINA_HOME/lib 目录下），这些库可以被所有的 Web 应用程序共享。为了实现这一功能，Tomcat 需要一个额外的类加载器（如 Catalina 类加载器）来加载这些共享库，并在需要时将它们提供给 Web 应用程序类加载器。 - 处理复杂的类库依赖：
在某些情况下，Web 应用程序可能依赖于特定版本的类库，而这些版本可能与 Tomcat 容器或其他应用程序的类库版本不同。为了处理这种复杂的类库依赖关系，Tomcat 需要提供一种机制来确保每个应用程序加载到正确的类库版本。
Tomcat 并没有完全打破双亲委派模型，而是在其基础上增加了额外的类加载器层次结构，并通过特定的加载策略来实现上述功能。这种设计使得 Tomcat 能够在保持类加载灵活性和隔离性的同时，也支持了 Web 应用程序的复杂性和动态性。
需要注意的是，虽然 Tomcat 的类加载器设计在一定程度上打破了双亲委派模型，但它仍然遵循了 Java 的类加载机制的基本原则，包括安全性、可靠性和可维护性等。因此，在使用 Tomcat 时，开发人员仍然需要注意类加载相关的最佳实践和潜在问题。
有点懒，不想写太长了，就写到这里把，觉得可以给个好评
535
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
