首先思考一个问题,整个Tomcat容器是一个Java进程,假若Tomcat中同时部署了两个应用,应用A依赖Spring3.0,应用B依赖Spring5.0,那么Tomcat如何决定使用哪个版本的依赖呢。
所以,按照JDK自带的双亲委派模型是无法解决的,因为ClassLoader#loaderClass默认会检查这个类有没有加载过,保证了类在进程中是唯一的。如果我们想加载两个版本的类,需要打破原有的模型。
1.Tomcat 类加载要求
1)隔离:对于 Tomcat 类隔离要满足以下两点:
- Tomcat 上部署的各个 web 应用应该隔离。比如不同的应用可能会依赖相同三方库的不同版本
- Tomcat 自己的类库于所有的 web 应用应该隔离。
2)共享:要求部署在同一个 Tomcat 不同的应用程序,相同类库的相同版本是共享的,否则就会出现大量相同的类加载到虚拟机中。
2.Tomcat 类加载器结构分析
1)在双亲委派的结构下,同级间 ClassLoader 相隔离
- 对于每个 web 应用都创建一个 ClassLoader – WebappClassLoader(加载 /WEB-INF/classes、/WEB-INF/lib)
- 对于 Tomcat 的类库单独创建一个 ClassLoader – CatalinaClassLoader (加载 server.loader…)
2)局部打破双亲委派
对于 WebappClassLoader,如果直接使用双亲委派,可能会出现问题,举个例子,父 AppClassLoader 已经加载了 commons-lang:1.0,而当前应用依赖的是 2.0,那么就会出现 2.0 无法加载的情况。
所以,这里需要重写 WebappClassLoader 的 loadClass 方法,在收到类加载的请求后,**先自己加载(打破双亲委派),**如果 findClass 找不到,再交给父加载器去加载。
注:打破双亲委派并不是说没有 parent,而是对于调用 ClassLoader 加载类的顺序。
3)抽象公共层 ClassLoader
首先,到这里又未完全打破双亲委派;然后,双亲委派下 parent 可以实现类加载的共享;所以,Tomcat 还提供了两个类加载器,我们可以把应用共享的依赖放到它们加载的路径下
- CommonClassLoader:Tomcat 应用和全部 web 应用共享(加载 $CATALINA_HOME/lib)
- SharedClassLoader:对于所有的 web 应用共享(加载 shared.loader…)
注:默认情况下,common、cataina、shared 这三个公共的 classloader 其实是同一个,都是 common classloader。而针对每个 webapp,都有自己的 WebappClassLoader 实例来加载每个应用自己的类,该类加载实例的 parent 即是 Shared ClassLoader。
最后再把这些 ClassLoader 的类关系再来看一下:
3.WebappClassLoader 实现分析
public Class<?> loadClass(String name) throws ClassNotFoundException {
return loadClass(name, false);
}
@Override
public Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
synchronized (getClassLoadingLock(name)) {
Class<?> clazz = null;
// 1. 首先从当前ClassLoader的本地缓存中加载类,如果找到则返回
// 类中维护了一个resourceEntries的ConcurrentHashMap
clazz = findLoadedClass0(name);
if (clazz != null) {
if (log.isDebugEnabled())
log.debug(" Returning class from cache");
if (resolve)
resolveClass(clazz);
return clazz;
}
// 2. 在本地缓存没有的情况下,调用ClassLoader的findLoadedClass方法查看jvm是否已经加载过此类,如果已经加载则直接返回。
clazz = findLoadedClass(name);
if (clazz != null) {
if (log.isDebugEnabled())
log.debug(" Returning class from cache");
if (resolve)
resolveClass(clazz);
return clazz;
}
String resourceName = binaryNameToPath(name, false);
// 3. 尝试使用javaSE classLoader来加载,避免web应用覆盖核心jre类
// 这里的javaSE classLoader是ExtClassLoader还是BootstrapClassLoader,要看具体的jvm实现
ClassLoader javaseLoader = getJavaseClassLoader();
boolean tryLoadingFromJavaseLoader;
try {
URL url;
if (securityManager != null) {
PrivilegedAction<URL> dp = new PrivilegedJavaseGetResource(resourceName);
url = AccessController.doPrivileged(dp);
} else {
url = javaseLoader.getResource(resourceName);
}
tryLoadingFromJavaseLoader = (url != null);
} catch (Throwable t) {
tryLoadingFromJavaseLoader = true;
}
boolean delegateLoad = delegate || filter(name, true);
// 4. 判断是否设置了delegate属性,如果设置为true则先使用parent(sharedLoader\commonLoader)加载
if (delegateLoad) {
if (log.isDebugEnabled())
log.debug(" Delegating to parent classloader1 " + parent);
try {
clazz = Class.forName(name, false, parent);
if (clazz != null) {
if (log.isDebugEnabled())
log.debug(" Loading class from parent");
if (resolve)
resolveClass(clazz);
return clazz;
}
} catch (ClassNotFoundException e) {
// Ignore
}
}
// 5. 默认是设置delegate是false的,那么就会先用WebAppClassLoader进行加载
if (log.isDebugEnabled())
log.debug(" Searching local repositories");
try {
clazz = findClass(name);
if (clazz != null) {
if (log.isDebugEnabled())
log.debug(" Loading class from local repository");
if (resolve)
resolveClass(clazz);
return clazz;
}
} catch (ClassNotFoundException e) {
// Ignore
}
// 6. 若是WebappClassLoader在/WEB-INF/classes、/WEB-INF/lib下还是查找不到class
// 那么委托给parent(sharedLoader\commonLoader)去查找该类
// 这里满足双亲委派原则
if (!delegateLoad) {
if (log.isDebugEnabled())
log.debug(" Delegating to parent classloader at end: " + parent);
try {
clazz = Class.forName(name, false, parent);
if (clazz != null) {
if (log.isDebugEnabled())
log.debug(" Loading class from parent");
if (resolve)
resolveClass(clazz);
return clazz;
}
} catch (ClassNotFoundException e) {
// Ignore
}
}
}
// 如果上述步骤都未加载到Class,抛ClassNotFoundException
throw new ClassNotFoundException(name);
}
Web 应用类加载器默认的加载顺序是(打破了双亲委派规则):
- 先从缓存中加载
- 如果没有,则从 JVM 的 Bootstrap 类加载器加载
- 如果没有,则从当前类加载器加载(按照 WEB-INF/classes、WEB-INF/lib 的顺序)
- 如果没有,则从父类加载器加载,由于父类加载器采用默认的委派模式,所以加载顺序是 AppClassLoader、Common、Shared
如果在配置文件中配置了<Loader delegate="true"/>
,那么就是遵循双亲委派规则,加载顺序如下:
- 先从缓存中加载;
- 如果没有,则从 JVM 的 Bootstrap 类加载器加载;
- 如果没有,则从父类加载器加载,加载顺序是 AppClassLoader、Common、Shared
- 如果没有,则从当前类加载器加载(按照 WEB-INF/classes、WEB-INF/lib 的顺序)
4.打破双亲委派的其他例子
Tomcat 其实是整体满足双亲委派,而局部打破了这个规则,最终到依赖隔离的目的。当然了,根据具体的场景,还有将双亲委派打破的更彻底的情况(如阿里的Pandora)。
这里还要说的是,通过线程上下文加载器打破双亲委派。
比如 JDBC 的 Driver 接口定义在 JDK 中,其实现由各个数据库的服务商来提供(MySQL 驱动包)。DriverManager 类中要加载各个实现了 Driver 接口的类,然后进行管理,但是 DriverManager 位于 JAVA_HOME中jre/lib/rt.jar 包,由 BootStrapClassLoader 加载;而其 Driver 接口的实现类是位于服务商提供的 Jar 包,根据之前说的传递机制,所以也需要 BootStrapClassLoader 去加载这些实现类。我们知道,BootStraClassLoader 默认只负责加载 JAVA_HOME中jre/lib/rt.jar 里所有的 class,所以需要由子类加载器去加载 Driver 实现,这就破坏了双亲委派模型。
其中,这个子类加载器是通过 Thread.currentThread().getContextClassLoader() 得到的线程上下文加载器。