双亲委派模型
JVM提供了3种类加载器:
•启动类加载器(Bootstrap ClassLoader):负责加载 JAVA_HOME\lib 目录中的,或通过-Xbootclasspath参数指定路径中的,且被虚拟机认可(按文件名识别,如rt.jar)的类。
•扩展类加载器(Extension ClassLoader):负责加载 JAVA_HOME\lib\ext 目录中的,或通过java.ext.dirs系统变量指定路径中的类库。
•应用程序类加载器(Application ClassLoader):负责加载用户路径(classpath)上的类库。
JVM通过双亲委派模型进行类的加载,当然我们也可以通过继承java.lang.ClassLoader实现自定义的类加载器。
双亲委派机制:某个特定的类加载器在接到加载类的请求时,首先将加载任务委托给父类加载器,依次递归。如果父类加载器可以完成类加载任务,就成功返回;只有父类加载器无法完成此加载任务时,才自己去加载。作用:1)避免重复加载;2)更安全。
总结一句话:越底层的类交给上层的类加载器加载。
双亲委派模型实现源码
双亲委派模型对于保证Java程序的稳定运作很重要,但它的实现却非常简单,实现双亲委派的代码都集中在java.lang.ClassLoader 的 loadClass()方法之中。
public Class<?> loadClass(String name) throws ClassNotFoundException {
return loadClass(name, false);
}
调用下面loadClass方法
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
//检查class是否已经被加载
//已加载直接返回class
//未加载则加载class
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
//判断父类加载器存在,则用父类加载器加载
//否则用bootstrap启动类加载器加载
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
}
//上面加载失败,则用自身的类加载器加载
if (c == null) {
long t1 = System.nanoTime();
//调用findClass加载类
//自定义类加载器需要实现findClass方法
c = findClass(name);
//类加载器统计信息
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
总结下过程:
1、判断是否已加载过,若已加载直接返回class
2、若未加载,判断是否存在父加载器,存在用父加载器加载
3、若不存在父加载器,则用启动类加载器加载
4、2 3步骤若加载失败,则用自身类的加载器加载
三次打破双亲委派模型
第一次兼容之前JDK版本
由于类加载器和抽象类java.lang.ClassLoader 在JDK1.0时代就已经存在, 面对已经存在的用户自定义类加载器的实现代码, Java 设计者引入双清委派模型时不得不做出一些妥协。
为了向前兼容, jdk1.2之后的java.lang.ClassLoader 添加了一个新的 protected 方法 findClass()。
第二次基础类回调用户的代码
双亲委派很好地解决了各个类加载器的基础类统一问题 (越基础的类由越上层的加载器进行加载)
基础类通常作为被用户代码调用的API, 但是当基础类要调用回用户的代码时该怎么解决?
典型例子SPI:jndi,jdbc,JAXB和 JBI等
第三次动态性追求
代码热替换(Hotswap), 模块热部署(Hot Deployment)