Java双亲委派机制
JVM双亲委派机制
Bootstrap类加载器
- 加载lib/rt.jar charset.jar等核心类
- 构造ExtClassLoader和APPClassLoader
- 是由c++实现的一个类加载器
- 如果一个类调用它的getclass方法后再调用getclassload方法时,返回值为null,则代表当前类是被该加载器加载的。
Ext类加载器
- 加载扩展jar包(JDK路径下,jre/lib/ext/*.jar)
- 还可以由-Djava.ext.dirs指定加载jar包
App类加载器
- 加载classpath下的内容
自定义类加载器
- 自己编写的类加载器
双亲委派的实现方式
源码如下:
protected Class<!--?--> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 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 {
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 = 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;
}
}
解释一下
假设我们存在自定义的类加载器
以下步骤以String类的加载步骤为例
- 当一个类第一次被加载时,会先进入我们自定义的类加载器,调用loadClass方法,查询该类是否被我们的自定义加载器加载过(由于是第一次加载所以肯定没有被加载过)。
- 没有被加载过就会去找自定义加载器的上一级加载器,也就是AppClassLoader并调用它的loadClass方法,查询该类有没有被AppClassLoader加载过(同样没有被加载)
- 再去上一级加载器ExtClassLoader执行同样的操作
- 最终到达BootstrapClassLoader中,发现都没有加载过该类,然后再自上向下由BootstrapClassLoader查看自己加载的类库中是否存在该类,有则加载。没有则让ExtClassLoader查询自己类库中存不存在,以此类推。
- 最终如果回到自定义加载器也没有发现该类,则抛出ClassNotFoundException。
再放张图片(图片来自CSDN:IT烂笔头)
为什么需要双亲委派?
如果有人想替换系统级别的类:String.java。篡改它的实现,在这种机制下这些系统的类已经被Bootstrap classLoader加载过了(为什么?因为当一个类需要加载的时候,最先去尝试加载的就是BootstrapClassLoader),所以其他类加载器并没有机会再去加载,从一定程度上防止了危险代码的植入。
类加载的脑图