事件来源
项目版本第一轮交付测试后测试同学反馈,用户编辑的功能出错,报异常。 该功能在当前版本中没有需求进行调整, 我抓紧去测试环境上看了下日志,发现日志中有如下内容:
异常日志挺明显的,实体Bean的代理类强转为Proxy失败。心中大体上锁定了下范围,必然是类加载的问题,在java中是否一个两个类是否是同一个类,必要的前提是classloader需要是同一个,在之前的tomcat了解中,掌握大tomcat针对每个一个webapps目录下的项目会使用一个专门的classloader进行类加载。为了证实是否是这个原因,以及究竟是什么导致了加载多个Proxy的类对象。
定位流程
很早之前就有使用arthas, 知道其中有查找类以及查找类详细的信息。 sc命令, 以及-d参数, 详细的可以阅读arthas官方介绍(https://arthas.aliyun.com/doc/sc.html)
- 查看tomcat中加载了多少的javassist.util.proxy.Proxy类
sc -d javassist.util.proxy.Proxy > /tmp/proxy.txt - 查看/tmp/proxy.txt中的Proxy的信息(grep Proxy相关信息到另外一个文件中)
- 分析上图的信息可以明确发现,javassist.util.proxy.Proxy类确实被两个classloader加载。
查看提交历史,发现确实是有位同学为了方便解决项目依赖jar包,将wlclient这个jar包直接打包在war包中。进而导致Proxy这个类的被加载了多次。
解决方式
- 方案一:将wlclient中的javassist相关内容移除。
- 方案二:放wlclient放在tomcat的lib目录下(选择了该方案)
深入思考
为什么放在tomcat的webapps下项目的lib目录中和放在tomcat的lib目录中的类会由不同的类加载器进行加载?了解tomcat的同学应该都知道,tomcat针对webapps下的项目,每个项目新建了一个类加载器(默认为ParallelWebappClassLoader),用于隔离不同的业务的, 但这些类加载器的父类加载器都是同一个的,根据双亲委派机制也应该统一由父类加载器的进行处理的才对。
双亲委派机制怎么实现
平时大家无论看介绍书籍,或者看博客文档,其中介绍的加载机制中都提到了双亲委派的加载机制,那么这种机制是怎么实现的哪?我们通过阅读下java的源码看下委派机制是怎么实现的
//Classloader#loadClass
Class<?> c = findLoadedClass(name);//判断是否已经加载过了
if (c == null) {
try {
if (parent != null) {
c = parent.loadClass(name, false); //使用父类加载器进行加载
} else {
c = findBootstrapClassOrNull(name); // 使用Bootstrap类加载器进行加载
}
} catch (ClassNotFoundException e) {
}
if (c == null) {
c = findClass(name); //父类加载器未加载到该类,则交由当前类加载器进行加载
}
}
从上述代码中我们可以看出,双亲委派的加载是怎么实现的:
1、双亲委派,不是由父子类集成关系引入的,而是有classLoader中的parent属性
2、双亲委派的实现是首先判断是否存在parent,存在则尝试使用parent加载,不存在则先尝试使用Bootstrap进行加载,最后才尝试使用自己进行加载
ParallelWebappClassLoader的加载逻辑什么
看完标准的双亲委派机制,大致可以猜测到ParallelWebappClassLoader的处理逻辑,应该是将判断逻辑进行了调整,应该是先交给当前类加载器进行尝试,加载不到在通过父加载进行加载。 我们在通过实际的代码确定下(核心的逻辑)
boolean delegateLoad = delegate || filter(name, true);
if (delegateLoad) {// 判断条件 delegate || filter(name, true)
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) {
}
}
// (2) Search local repositories
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
}
// (3) Delegate to parent unconditionally
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) {
}
}
注:delegate默认值为false
从上述代码中可以看出来,默认情况下除了filter通过的类会有限使用父类加载器进行加载,其它情况下均先有当前类加载器进行尝试加载,加载失败在委托父类加载器进行加载,filter的逻辑,较为简单就是针对tomcat自身的className,或者javax提供的标准servlet api的类优先交由父类加载器进行加载。
深入考虑下,同一个tomcat是支持多应用的,多个应用如果出现相同的类,在默认的双亲委派机制下就有可能出现逻辑冲突。在这种情况下优先使用自己的类加载器进行加载是合理的。
单应用情况下是否可以调整这种加载机制
上述代码中是否优先使用当前类加载器进行加载,还有另外一个参数控制,delegate。 该参数如何配置。
配置很简单通过Context.xml文件中增加增加详见https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html 。 配置如下:
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
<Loader delegate ="true"/> <!-- 增加的内容 -->
</Context>
非双亲委派机制的加载方式还有哪些
jdbc的类加载机制
标准的jdbc的实现方式已经发生变化之前的我们使用jdbc的是否需要如下的写法:
Class.forName(proConf.getDriver());
DriverManager.getConnection(proConf.getUrl(), proConf.getUser(), proConf.getPassword());
现阶段实现中已经不需要Class.forName步骤,而是通过spi的机制将项目依赖的jdbcDriver注册在DriverManager中。
可以想一下DriverManger类是由BootstrapClassloader进行加载的,在加载DriverManager时如何能够加载到项目目录中的Driver类那? 我们通过代码来确定下DriverManger如何实现加载项目依赖的Driver
ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
public static <S> ServiceLoader<S> load(Class<S> service) {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return ServiceLoader.load(service, cl);
}
使用ServiceLoader加载类的时候的通过Thread.currentThread获取到的contextClassLoader进行Driver的初始化的,从而使得加载的Bootstrap类的时候可以同步加载到项目目录中的类。
大家可以测试时重置下Thread的contentClassLoader, 例如进行尝试,测试下是否可以加载到项目路径的Driver。classLoader初始化时parent需要设置为null,否则默认是AppClassLoader。
Thread.currentThread().setContextClassLoader(new URLClassLoader(new URL[]{}, null))