类加载器、双亲委派、SPI
类加载器
JVM中有两种类型的类加载器，由C++编写的及由Java编写的。除了启动类加载器(BootstrapClassLoader)是由C++编写的，其他都是由Java编写的，由Java编写的类加载器都继承自类java.lang.ClassLoader.JVM还支持自定义类加载器。各类加载器之间存在着逻辑上的父子关系，因为他们没有直接的从属关系
启动类加载器
因为启动类加载器是由C++编写的，通过Java程序去查看显示的是NULL,因此，启动类加载器无法被Java程序调用，启动类加载器不像其他类加载器有实体，它是没有实体的，JVM将C++处理类加载的一套逻辑定义为启动类加载器，加载的jar包如图所示。也可以通过-Xbootclasspath指定
HotSpot源码
首先我们找到启动main方法的入口
第二步，找到LoadMianClass
第三步，找到GetLauncherHelperClass中，findBootStrapClass方法。
这套逻辑做的事情就是通过启动类加载器加载类sun.launcher.LauncherHelper，执行该类的方法checkAndLoadMian,加载main函数所在的类，启动扩展类加载器、应用类加载器也是在这个时候完成的
BootstrapClassLoader在JVM中对应的是ClassLoader.cpp。我们可以看到它包含的都是一些静态属性和静态方法
扩展类加载器
ExtClassLoader的继承关系图
通过代码方式可以查看扩展类加载器加载的路径，也可以通过java.ext.dirs指定
应用类加载器
AppClassLoader的继承关系图
查看应用类加载器，它是默认加载用户程序的类加载器，也可以通过java.class.path指定
自定义类加载器
实现方式，需要继承java.lang.ClassLoader类,通过源码查看我们也得知了ClassLoader在loadClass的时候不会立马触发解析阶段，因为源码里面就写死了是false.懒汉模式，你可能听过loadClass()和findClass()方法，两者的职责是不一样的
loadClass方法与findClass方法分析:
1.loadClass方法是ClassLoader类中最常用的方法之一，它负责加载指定的类。它的主要特点是:
1.1 它是一个public方法，可以被外部类调用。
1.2 首先会检查类是否已经被加载，如果已经被加载，则直接返回对应的Class对象。
1.3 如果类没有被加载，它会调用findLoadedClass方法来检查类是否已经被其他类加载器加载
1.4 如果类仍然没有被加载，它会调用findClass方法(或者委托给父类加载器)来加载类。
1.5 如果上面的操作还是没有成功加载类，就抛出ClassNotFoundException一场
2.findClass方法是ClassLoader类中的一个protected方法，通常用于自定义类加载器时重写该方法
2.1 findClass方法负责从文件系统、网络或其他来源找到并读取类的字节码
2.2 在自定义类加载器时，通常重写findClass方法来实现特定的类加载逻辑。
2.3 当loadClass方法确定类尚未被加载，并且父类加载器没有加载该类时，它将调用findClass方法
在实现自定义类加载器时，通常会这样重写findClass:
1.根据类的全限定名(name参数)转换为文件路径
2.读取类的字节码文件
3.调用defineClass方法，将字节码转换成Class对象。
loadClass是用于外部调用的公共方法，负责整个类的加载过程，包括委托模型和类加载逻辑
findClass是用于被loadClass调用的受保护方法，通常在自定义类加载器时被重写以实现具体的类查找和字节码读取逻辑
如何查看加载过的类？
findLoadedClass方法如果深入进去看的话，会发现其调用到了一个native的findLoadedClass0方法，这里的话，我们可以在openjdk的源码当中搜索
当我们再进一步查看的话，会发现看不到它的实现，这可能和C++的写法有关系，
它这里的方法实现其实是要到jvm.cpp文件中才能看到，具体的写法我也不是很清楚，但是可以看到，最后生成关键的一步是find_instance_or_array_klass这个方法
find_instance_or_array_klass方法中又调用了find(),我们再跟进去
我们可以发现，当查找加载过的类时，它是把类信息放到了一个hashtable里面，先通过class_name和类加载器loader计算出一个d_index，然后再通过这个索引去查找
如果在Dictionary字典里面找到了这个classname对应的类，则返回，没有则返回null，可以看到，查找加载过的类时，并不是直接拿着classname去找的，而是classname + classloader组合起来查找的.也就是key=>类的全限定名+类加载器 ->index value: Metadata:klass
类加载器创建链
启动类加载没有实体，只是将一段加载逻辑命名成启动类加载器。启动类加载器做的事情是:加载类sun.lanuncher.LanuncherHelper,执行该类的方法checkAndLoadMain…启动类、扩展类、应用类加载器逻辑上的父子关系就是在这个方法的调用链中生成的
我们知道JVM启动时会执行JavaMain,之后会执行JVM的相关初始化工作，这里先不谈，先看类加载器创建链。然后执行loadMainClass
获取LauncherHelper，它这个动作其实是让Bootstrap类加载器进行加载的
调用了FindBootstrapClass方法，
这里其实是要返回一个InstanceMirrorClass对象出来，如果加载过，则返回缓存即可，没有加载过，则进行加载
checkAndLoadMain方法中可以看到通过classloader加载该类，这也是类加载器加载一个类的流程，这个地方是要判断这个类应该交给哪个类加载器去加载，加载的细节其实就走到我们Java文件里面了ClassLoader的细节，那么这个scloader是怎么来的呢？
scloader是通过ClassLoader.getSytemClassLoader()方法创建的
在initSystemClassLoader方法里面核心逻辑是sum.misc.Lanuncher.getLauncher()
sun.misc.Launcher是C++里面的Java类，并不是我们rt.jar里面的，所以我们还得在HotSpot中去看，我们发现Launcher的构造方法中创建了扩展类加载器ExtClassLoader以及AppClassLoader
ExtClassLoader在创建的时候调用了super(getExtURLs(dirs), null, factory);由于它继承了URLClassLoader所以我们需要到它的父类里面去查看构造参数的细节
可以看到parent为null
在创建AppClassLoader的时候，把ExtClasLoader当作parent传给了构造参数，也就是说AppClassLoader和ExtClassLoader才具有真正意义上父子结构
再结合到java层面来看，当委托到ExtClassLoader的时候，由于它的parent为null，这个时候会调用findBootstrapClassOrNull
而findBootstrapClassOrNull方法底层又是一个native方法，这个时候就需要到C++里面去看了
这个方法会调用到ClassLoader.c(也就是对应的Bootstrap)。
看到SystemDictionary::resolve_or_null，返回由Bootstrap类加载器加载的InstanceMirrorClass
