深入理解Java类加载器(一)：Java类加载原理解析，持久化数据安全RDB、AOF

if (c == null) {

// 如果父类加载器不能完成加载请求时，再调用自身的findClass方法进行类加载，

// 若加载成功，findClass方法返回的是defineClass方法的返回值

// 注意，若自身也加载不了，会产生ClassNotFoundException异常并向上抛出

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©;

}

return c;

}

}

通过上面的代码分析，我们可以对JVM采用的双亲委派类加载机制有了更感性的认识，下面我们就接着分析一下启动类加载器、标准扩展类加载器和系统类加载器三者之间的关系。可能大家已经从各种资料上面看到了如下类似的一幅图片：

上面图片给人的直观印象是：系统类加载器的父类加载器是标准扩展类加载器，标准扩展类加载器的父类加载器是启动类加载器，下面我们就用代码具体测试一下：

public class Loadertest

{

public static void main(String[] args)

{

System.out.println(ClassLoader.getSystemClassLoader());

System.out.println(ClassLoader.getSystemClassLoader().getParent());

System.out.println(ClassLoader.getSystemClassLoader().getParent().getParent());

}

}

输出的结果是：

通过以上的代码输出，我们知道：通过java.lang.ClassLoader.getSystemClassLoader()可以直接获取到系统类加载器 ，并且可以判定系统类加载器的父加载器是标准扩展类加载器，但是我们试图获取标准扩展类加载器的父类加载器时却得到了null。事实上，由于启动类加载器无法被Java程序直接引用，因此JVM默认直接使用 null 代表启动类加载器。我们还是借助于代码分析一下，首先看一下

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

java.lang.ClassLoader抽象类中默认实