双亲委派机制
Java类的加载是存在一定的顺序的,当我们加载一个类的时候,会从从下向上查找是否已经加载过当前类,每个类加载器都有一个父类加载器,在类加载的过程中,每个类加载器都会先检查是否已经加载了该类,如果已经加载则直接返回,否则会将加载请求委派给父类加载器。例如:
- 有一个类A,首先先检查应用加载器(AppClassLoader)是否已经加载过这个类,
- 如果没有加载过啊这个类,则继续向上检索,判断扩展类加载器(ExtClassLoader)是否加载过该类,
- 如果还是没有,则继续向上检索,此时如果发现启动类加载器(BootstrapClassLoader)加载过该类,则直接返回,
- 如果发现还是没有加载过这个类,就尝试从上到下加载这个类,首先会尝试BootstrapClassLoader来加载这个类,检查当前类是否在%JAVA_HOME%中lib/ext目录下,或者Xbootclasspath指定的目录下
- 如果存在则加载否则,继续向下委派,同样检查%JAVA_HOME%中lib/ext来判断ExtClassLoader是否能加载当前类,不能则继续向下委派
- 然后找到AppClassLoader检索当前项目的classpath 路径,如果找不到则会抛出找不到类的异常
向上查找
这种向上委派的方式加载的优点是可以有效的避免类的重复加载,当我们一直向上委派发现所有的父类加载器都无法加载该类,则由当前类加载器自己尝试加载,所以看上去是自顶向下尝试加载。
向下委派
双亲委派可能出现的问题
- 如果一个类在启动类加载器的路径下能找到,扩展加载器包路径下也能找到,classpath 也能找到则会有限加载启动类加载器,因为该加载器优先级是最高的
- String 能否被覆盖,我们自定一个全限定名和String类型都是java.lang.String的类,我们自定义的这个String是不会被加载的,被加载的还是仍然是启动类加载器中String类,是不会被覆盖的,这样就避免了在Java类加载当中Java的核心类被覆盖的问题
打破双亲委派
在tomcat 当中可能存在多个应用,每个应用当中都存在Servlet,此时假如有两个应用,应用A已经加载Servlet就会导致应用B加载的时候认为Servlte类已经被加载过了,打破双亲委派机制有三种方式:
- 自定义类加载机制
- 线程上下文类加载器
- osgi框架的类加载器
自定义加载器打破双亲委派
双亲委派源码分析
ClassLoader中的loadClass方法分析
// name字段:class名称
// resolve: 是否执行链接阶段的代码,如果为true则执行链接阶段的相关代码
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
// 加锁防止多线程情况下重复加载
synchronized (getClassLoadingLock(name)) {
// 首先检查当前类是否已经被加载
Class<?> c = findLoadedClass(name);
// 等于null 则表示没有被加载,继续执行加载逻辑
if (c == null) {
long t0 = System.nanoTime();
try {
// 向上委托的代码
// 检查上一级的加载器是否为空,用来判断是否是Bootstrap类加载器
if (parent != null) {
// 这里的parent是一个ClassLoader对象,
// 代码中是这样写的: private final ClassLoader parent;
c = parent.loadClass(name, false);
} else {
// 如果为空则表示是启动类加载器
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
// 最终还是没有加载成功
if (c == null) {
long t1 = System.nanoTime();
// 这个方法抛出了异常,因为ClassLoader是一个抽象类,
// 所以这里findClass方法是通过ClassLoader的子类实现的具体的逻辑
c = findClass(name);
// this is the defining class loader; record the stats
PerfCounter.getParentDelegationTime().addTime(t1 - t0);
PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
PerfCounter.getFindClasses().increment();
}
}
// 执行链接阶段相关的代码
if (resolve) {
resolveClass(c);
}
return c;
}
}
上方代码的注释中说到ClassLoader中的findClass是通过其子类实现的具体逻辑的,为了更好的说明这里以URLClassLoader为例(下方代码是URLClassLoader实现的findClass的具体实现):
protected Class<?> findClass(final String name)
throws ClassNotFoundException
{
final Class<?> result;
try {
result = AccessController.doPrivileged(
new PrivilegedExceptionAction<>() {
public Class<?> run() throws ClassNotFoundException {
String path = name.replace('.', '/').concat(".class");
Resource res = ucp.getResource(path, false);
if (res != null) {
try {
return defineClass(name, res);
} catch (IOException e) {
throw new ClassNotFoundException(name, e);
} catch (ClassFormatError e2) {
if (res.getDataError() != null) {
e2.addSuppressed(res.getDataError());
}
throw e2;
}
} else {
return null;
}
}
}, acc);
} catch (java.security.PrivilegedActionException pae) {
throw (ClassNotFoundException) pae.getException();
}
if (result == null) {
throw new ClassNotFoundException(name);
}
return result;
}
自定义类加载器后面有时间去补充