前言

在之前的文章中，我经常提到java类加载，ClassLoader等名词，而ClassLoader是什么？有什么职责？ClassLoader和java类加载机制有什么关系？java类加载机制具体过程是怎么做的？能不能自定义实现类加载？相信你此时已经充满了疑惑，那么本篇我们就来深入浅出的分析ClassLoader类加载器和JAVA类加载机制吧

初识ClassLoader

ClassLoader类加载器在Java中的定义就是用来加载其他类到Jvm中的操作类，负责将字节码文件加载到内存中，在内存中创建对应的Class对象。同样的ClassLoader一般使用系统提供的，但是在开发过程中往往会遇到一些特殊的功能，我们需要自定义ClassLoader来实现一些强大灵活的功能，如下:

• 热部署机制

即在不重启Java程序的情况下，动态替换部分类的实现，重新将新的Class字节码文件加载到jvm内存中，将原来的内存中的Class进行替换操作，而java自身的ClassLoader并不能实现热部署。而在一些常用的框架中，早已实现了热部署机制，例如在早期的java web开发中，我们使用的jsp就是使用了自定义的ClassLoader实现的jsp代码修改后不需要重启直接刷新生效，实现代码的动态更新

• 应用的模块化与隔离

ClassLoader还有一个特性，即不同的ClassLoader加载的Class类之间是相互隔离的，彼此互不影响，在我们常用的web容器服务器--Tomcat、jetty等都是利用了此技术，从而实现可以同时加载多个项目工程，并且web工程彼此之间互不干扰，而OSGI和Java9中，都实现了一个动态模块化的结构，每个模块使用独立的ClassLoader做到模块间隔离互不干扰

• 不同地方灵活加载类

系统默认的ClassLoader一般固定从本地指定目录的.class文件或者jar包文件中加载字节码文件。而实现自定义的ClassLoader，甚至可以做到远程加载Class、从服务器、数据库等地方加载，甚至可以做到任意生命周期加载，随心所欲

类加载机制与加载过程

当我们运行java程序的时候，JDK实际上就是帮我们执行了java命令，指定了包含main方法的完整类名，以及一个classpath类路径，作为程序的入口，然后根据类的完全限定名查找并且加载类，而查找的规则是在系统类和指定的文件类路径中寻找。

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

而这个查找加载的过程中，负责完成操作的类就是ClassLoader类加载器，输入为完全限定类名，输出是对应的Class对象，而在Java9之前，系统默认的类加载器有三种（java9有模块化概念），如下:

• 启动类加载器--Bootstrap ClassLoader

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

• 扩展类加载器---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加载，具体的过程大致如下:

1. 判断当前Class是否已经加载过了，如果已经被加载，直接返回Class对象，因为在java中一个Class类只会被同一个Class-Loader加载一次
2. 如果当前Class没有被加载，首先需要调用父ClassLoader去加载，加载成功后，得到父ClassLoader返回的Class对象
3. 父ClassLoader加载成功后，自身就会去加载当前的Class

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

打破双亲委派

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

1. 自定义Class类加载顺序:尽管java希望我们按照默认的双亲委派加载的顺序执行，但是我们的确在自定义ClassLoader的时候，不遵循这个约定，不过即使如此，一些被java安全机制限制的类依然不能随便被自定义的ClassLoader加载，例如包名为java开头的类
2. 网格化加载顺序：在OSGI和java9中，类加载器之间的关系甚至更复杂，形成了一个网状，每个模块都有自己的类加载器，并且模块之间可以存在依赖关系，也就是说此时可以是当前模块加载Class,也可以传递给其他模块的加载器加载
3. 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即可：

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

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