如果是class文件的根目录中，则直接查看是否有对应的子目录以及class文件，如果当前路径是jar文件，首先实行解压，然后再去到目录中查找是否有对应的类。

而这个查找加载的过程中，卖力完成操作的类便是ClassLoader类加载器，输入为完备限定类名，输出是对应的Class工具，而在Java9之前，系统默认的类加载器有三种（java9有模块化观点），如下:

启动类加载器--Bootstrap ClassLoader

Bootstrap ClassLoader加载器是Java虚拟机内部实现的，不在java代码中实现，此类卖力加载java的根本类，如String、Array等class，还有jdk文件夹中lib文件夹目录中的rt.jar

jsp修改后不重启的原理深刻浅出Java类加载机制 Angular

扩展类加载器---Extension ClassLoader

Extension ClassLoader类加载器默认的实现类是sun.misc.Launcher包中的ExtClassLoader类，此类默认卖力加载JDK中一些扩展的jar，如lib文件夹中ext目录中的jar文件

运用程序类加载器--Application ClassLoader

Application

ClassLoader类加载器的默认实现类为sun.misc.Launcher包中的AppClassLoader类，此加载器默认卖力加载运用程序的类，包括自己实现的类与引入的第三方类库，即会加载全体java程序目录中的所有指定的类

双亲委派模型

这三个别系的类加载器都能实现类加载功能，并且卖力的职责和加载的范围都不一样，那么这三个类加载器之间的关系是什么呢？顺序是什么？首先我们可以把这三个类加载器理解为父子关系，当然不是java中的继续关系，而是一种叫"父子委派"的模式，即每一个ClassLoader都有一个变量parent指向父ClassLoader，代码如下:

而三个别系ClassLoader之间的父子关系大致如下:

Application ClassLoader的父亲是Extension ClassLoader，而Extension ClassLoader的父亲是Bootstrap ClassLoader，而在加载类的时候，一样平常会先通过父ClassLoader加载，详细的过程大致如下:

判断当前Class是否已经加载过了，如果已经被加载，直接返回Class工具，由于在java中一个Class类只会被同一个Class-Loader加载一次如果当前Class没有被加载，首先须要调用父ClassLoader去加载，加载成功后，得到父ClassLoader返回的Class工具父ClassLoader加载成功后，自身就会去加载当前的Class

而以上的过程称之为“双亲委派模型”，即优先让父ClassLoader加载Class，而如此设计的好处，则是可以避免Java中的类库被覆盖的问题，例如，开拓者自己实现了一个java.lang.String 类，通过双亲委派模型，只会被Bootstrap ClassLoader加载，避免了系统的String类被覆盖。

冲破双亲委派

须要把稳的一点是，虽然ClassLoader默认的是双亲委派模型，但是我们依然存在一些例外，或者人为改变的情形，例如:

自定义Class类加载顺序:只管java希望我们按照默认的双亲委派加载的顺序实行，但是我们的确在自定义ClassLoader的时候，不遵照这个约定，不过纵然如此，一些被java安全机制限定的类依然不能随便被自定义的ClassLoader加载，例如包名为java开头的类网格化加载顺序：在OSGI和java9中，类加载器之间的关系乃至更繁芜，形成了一个网状，每个模块都有自己的类加载器，并且模块之间可以存在依赖关系，也便是说此时可以是当前模块加载Class,也可以通报给其他模块的加载器加载JNDI：JNDI(Java Naming and Directory Interface)技能是企业级运用的一种常见做事，利用的办法便是父加载器委托给子加载器进行加载，和默认的双亲委派机制是反过来的Class.forName与类加载

之前的文章中，我们有学习到反射技能，也知道Class工具中都有一个反射方法，可以获取到当前Class的ClassLoader，如下:

而每一个ClassLoader都有一个方法获取父ClassLoader，如下:

除此之外，我们还可以通过Class工具获取默认的系统类加载器，如下:

与之对应的是，ClassLoader中也有一个紧张的方法用来加载class，如下:

理解了这些后，我们开始考试测验利用反射和ClassLoader来加载一个常用的类--ArrayList，代码如下：

把稳：由于双亲委派机制，父ClassLoader可能会加载失落败或者返回的不是当前ClassLoader加载的结果，ArrayList由于是系统包下的类，实际上已经被BootStrap ClassLoader加载了，以是这里返回的反而是null

在前面反射篇我们还理解到了一个加载Class的方法--forName,但是ClassLoader的loadClass看起来和forName功能一样，这两个有什么差异呢？实在熟习事理的都知道，基本实现事理是相同的，都是利用的ClassLoader代码进行加载，不过，ClassLoader的loadClass方法不会初始化类的初始化代码，并且有一点须要把稳的是forName方法有多个重载，个中一个为:

这里须要指定三个参数，第一个是class全量限定类名，第二个则是表示是否在Class类加载后急速初始化代码块(static代码块),第三个参数则是通报一个类加载器实现Class的加载，如果我们这个时候分别用ClassLoader和forName的办法加载一个有static代码块的类，就会创造，forName办法加载的Class输出了static代码块的内容，为了弄懂个中缘由，我们直接从ClassLoader类的loadClass方法的源码来一探究竟:

可以看到内部调用了重载方法loadClass，我们跟进去看看，代码如下:

从上述的源码以及我添加的注释中，我们大概明白了，在loadClass方法实行过程中，还会通报一个resolve标示符，此标示符和forName的initialize参数是一样的，用来判断是否在Class加载后进行初始化代码块的操作，但是我们从上面的方法明显看到，默认通报的值为false，即仅仅加载Class类，并不去调用类的初始化代码块部分，两者的差异至此已经原形大白。

自定义ClassLoader

前面我们也多次提到过自定义ClassLoader，此技能也是tomcat、OSGI等实现运用隔离、动态模块加载的根本，那么如何自定义呢？

一样平常来说，我们须要继续类ClassLoader，重写其方法findClass即可，现在我们来看一个开拓中常碰着的问题：我们在开拓过程中常常碰着本地运行程序的情形，每每有些时候会碰着做事真个jar与我们自定义的代码中有部分类名同等的时候，由于系统加载的时候默认优先显示做事真个jar中的calss，而不是本地的class，那么究其缘故原由，便是jvm默认利用AppClassLoader加载classpath中的类 ，那么我们能否重写AppClassLoader来实现优先显示本地实现的类，再去加载做事真个jar中呢？说做就做，我们参考系统默认实现的URLClassLoader 类的代码来写一个大略的功能实现，代码如下:

而实现了往后，在运行的时候只须要加上对应的变量指定利用的classLoader即可：

如果喜好本文，可以关注我们的官方账号，第一韶光获取资讯。

你的关注是对我们更新最大的动力哦~