记一次类加载问题

事件来源

项目版本第一轮交付测试后测试同学反馈，用户编辑的功能出错，报异常。 该功能在当前版本中没有需求进行调整， 我抓紧去测试环境上看了下日志，发现日志中有如下内容：

异常日志挺明显的，实体Bean的代理类强转为Proxy失败。心中大体上锁定了下范围，必然是类加载的问题，在java中是否一个两个类是否是同一个类，必要的前提是classloader需要是同一个，在之前的tomcat了解中，掌握大tomcat针对每个一个webapps目录下的项目会使用一个专门的classloader进行类加载。为了证实是否是这个原因，以及究竟是什么导致了加载多个Proxy的类对象。

定位流程

很早之前就有使用arthas， 知道其中有查找类以及查找类详细的信息。 sc命令， 以及-d参数， 详细的可以阅读arthas官方介绍（https://arthas.aliyun.com/doc/sc.html）

1. 查看tomcat中加载了多少的javassist.util.proxy.Proxy类

   sc -d javassist.util.proxy.Proxy > /tmp/proxy.txt

2. 查看/tmp/proxy.txt中的Proxy的信息(grep Proxy相关信息到另外一个文件中)

   

3. 分析上图的信息可以明确发现，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))