1 类加载器

1.1 类的加载过程

当程序要使用某个类时，如果该类还未被加载到内存中，则系统会通过加载，连接，初始化三步来实现对这个类进行初始化。

（1）加载

就是指将class文件读入内存，并为之创建一个Class对象。

任何类被使用时系统都会建立一个Class对象。

（2）连接

验证 是否有正确的内部结构，并和其他类协调一致

准备 负责为类的静态成员分配内存，并设置默认初始化值

解析 将常量池内的符号引用(逻辑地址)替换成直接引用（物理地址）

（3）初始化 就是我们以前讲过的初始化步骤

类初始化时机

l 创建类的实例

l 访问类的静态变量，或者为静态变量赋值

l 调用类的静态方法

l 使用反射方式来强制创建某个类或接口对应的java.lang.Class对象

l 初始化某个类的子类

l 直接使用java.exe命令来运行某个主类

在类加载时，静态变量和静态代码块的加载顺序（执行顺序），由编写先后决定。

在实例化时，成员变量和成员代码块的执行顺序，由编写先后决定。

1.2 什么是类加载器

类加载器就是用来加载类的东西，类加载器也是一个类：ClassLoader（把.class文件加载到JVM的方法区中，变成一个Class对象）。一些在java代码中动态生成的类，而这些类的数据就是在运行期时由类加载器去加载的，比如动态代理。

类加载器也可以被加载到内存，是通过其他类加载器完成的！Java提供了三种类加载器（比喻，它们都是片警！），分别是：

l bootstrap classloader：引导类加载器，加载rt.jar中的类（类库）；

l sun.misc.Launcher$ExtClassLoader：扩展类加载器，加载lib/ext目录下的类；

l sun.misc.Launcher$AppClassLoader：应用类加载器，加载CLASSPATH下的类，即我们写的类和第三方的jar包，以及第三方提供的类。（会先加载CLASSPATH下的类，然后加载lib目录下的jar包；）

通常情况下，Java中所有类都是通过这三个类加载器加载的。

类加载器之间存在上下级关系，应用类加载器的上级是扩展类加载器，而扩展类加载器的上级是引导类加载器，引导类加载器（该加载器本身无需加载，存在JVM中）没上层，它是BOSS。

当执行 java ***.class 的时候， java.exe 会帮助我们找到 JRE ，接着找到位于 JRE 内部的 jvm.dll ，这才是真正的 Java 虚拟机器 , 最后加载动态库，激活 Java 虚拟机器。虚拟机器激活以后，会先做一些初始化的动作，比如说读取系统参数等。一旦初始化动作完成之后，就会产生第一个类加载器―― Bootstrap Loader ， Bootstrap Loader 是由 C++ 所撰写而成，这个 Bootstrap Loader 所做的初始工作中，除了一些基本的初始化动作之外，最重要的就是加载 Launcher.java 之中的 ExtClassLoader ，并设定其 Parent 为 null ，代表其父加载器为 BootstrapLoader 。然后 Bootstrap Loader 再要求加载 Launcher.java 之中的 AppClassLoader ，并设定其 Parent 为之前产生的 ExtClassLoader 实体。这两个加载器都是以静态类的形式存在的。这里要请大家注意的是， Launcher$ExtClassLoader.class 与 Launcher$AppClassLoader.class 都是由 BootstrapLoader 所加载，所以 Parent 和由哪个类加载器加载没有关系。

1.3 JVM眼中的相同的类

在JVM中，不可能存在一个类被加载两次的事情！一个类如果已经被加载了，当再次试图加载这个类时，类加载器会先去查找这个类是否已经被加载过了，如果已经被加载过了，就不会再去加载了。

但是，如果一个类使用不同的类加载器去加载是可以出现多次加载的情况的！也就是说，在JVM眼中，相同的类需要有相同的class文件，以及相同的类加载器。当一个class文件，被不同的类加载器加载了，JVM会认识这是两个不同的类，这会在JVM中出现两个相同的Class对象！甚至会出现类型转换异常！

1.4类加载器的委托机制

当系统类加载器去加载一个类时，它首先会让上级去加载，即让扩展类加载器去加载类，扩展类加载器也会让它的上级引导类加载器去加载类。如果上级没有加载成功，那么再由自己去加载！

例如我们自己写的Person类，一定是存放到CLASSPATH中，那么一定是由系统类加载器来加载。当系统类加载器来加载类时，它首先把加载的任务交给扩展类加载去，如果扩展类加载器加载成功了，那么系统类加载器就不会再去加载。这就是代理模式了！

相同的道理，扩展类加载器也会把加载类的任务交给它的“上级”，即引导类加载器，引导类加载器加载成功，那么扩展类加载器也就不会再去加载了。引导类加载器是用C语言写的，是JVM的一部分，它是最上层的类加载器了，所以它就没有“上级了”。它只负责去加载“内部人”，即JDK中的类，但我们知道Person类不是我们自己写的类，所以它加载失败。

当扩展类加载器发现“上级”不能加载类，它就开始加载工作了，它加载的是lib\ext目录下的jar文件，当然，它也会加载失败，所以最终还是由系统类加载器在CLASSPATH中去加载Person，最终由系统类加载器加载到了Person类。

代理模式保证了JDK中的类一定是由引导类加载加载的！这就不会出现多个版本的类，这也是代理模式的好处。例如自定义的String类永远不会被加载。

1.5 自定义类加载器

我们也可以通过继承ClassLoader类来完成自定义类加载器，自类加载器的目的一般是为了加载网络上的类，因为这会让class在网络中传输，为了安全，那么class一定是需要加密的，所以需要自定义的类加载器来加载（自定义的类加载器需要做解密工作）。

ClassLoader加载类都是通过loadClass()方法来完成的，loadClass()方法的工作流程如下：

l 调用findLoadedClass()方法查看该类是否已经被加载过了（在JVM的方法区中查看已加载过的类！），如果该没有加载过，那么这个方法返回null；

l 判断findLoadedClass()方法返回的是否为null，如果不是null那么直接返回，这可以避免同一个类被加载两次；

l 如果findLoadedClass()返回的是null，那么就启动代理模式（委托机制），即调用上级的loadClass()方法，获取上级的方法是getParent()，当然上级可能还有上级，这个动作就一直向上走；

l 如果getParent().loadClass()返回的不是null，这说明上级加载成功了，那么就加载结果；

l 如果上级返回的是null，这说明需要自己出手了，这时loadClass()方法会调用本类的findClass()方法来加载类；

l 这说明我们只需要重写ClassLoader的findClass()方法，这就可以了！如果重写了loadClass()方法覆盖了代理模式！

OK，通过上面的分析，我们知道要自定义一个类加载器，只需要继承ClassLoader类，然后重写它的findClass()方法即可。那么在findClass()方法中我们要完成哪些工作呢？

l 找到class文件，把它加载到一个byte[]中；

l 调用defineClass()方法，把byte[]传递给这个方法即可。

1.6Tomcat的类加载器

Tomcat提供了两种类加载器！

* 服务器类加载器：它负责加载这个下面的类！(${CATALINA_HOME}\lib)

* 应用类加载器：它负责加载这两个路径下的类！(${CONTEXT_HOME}\WEB-INF\lib、${CONTEXT_HOME}\WEB-INF\classes)。

注意：Tomcat会为每个应用（假设该Tomcat下部署了多个应用）提供一个应用类加载器，负责加载每个该应用下WEB-INF\lib和WEB-INF\classes目录下的类。

对于运行在 Java EE容器中的 Web 应用来说，类加载器的实现方式与一般的 Java 应用有所不同。不同的 Web 容器的实现方式也会有所不同。以 Apache Tomcat 来说，每个 Web 应用都有一个对应的类加载器实例。该类加载器也使用代理模式，所不同的是它是首先尝试去加载某个类，如果找不到再代理给父类加载器去加载。这与一般类加载器的顺序是相反的。这是 Java Servlet 规范中的推荐做法，其目的是使得 Web 应用自己的类的优先级高于 Web 容器提供的类。

这种代理模式的一个例外是：Java 核心库的类是不在查找范围之内的。这也是为了保证 Java 核心库的类型安全。（tomcat的webApp类加载器，在加载用户自定义类时，先尝试让App类加载器判断下是不是jdk的核心类，如果是，就由App类加载器加载；否则就自己来加载；如果自己还加载不了，就交给服务器类加载器去加载。）

Tomcat提供的类加载器有这样一个好处，就是对每个应用来说，可以使该应用下的类优先被加载！（优先于(${CATALINA_HOME}\lib目录下的类）。

相同名称的类可以并存在 Java 虚拟机中，只需要用不同的类加载器来加载它们即可。不同类加载器加载的类之间是不兼容的，这就相当于在 Java 虚拟机内部创建了一个个相互隔离的 Java 类空间。这种技术在许多框架中都被用到，例如OSGI、Web 容器(Tomcat)。

1.7加载资源文件

我们在开发中，要读取配置文件时，为什么不使用File的形式读取？因为应用有可能被打包成jar文件，单纯地用File去读取jar包的文件是不能的，因为File的方式并不会深入到jar包内部的路径（即不会解压jar文件），那么就无法读取到jar内部的配置文件了。所以，如果jar包中的类源代码用File f=new File(相对路径)的形式，是不可能定位到文件资源的，会报FileNotFoundException的异常信息。

而如果用ClassLoader来加载资源文件，就能解决这个问题。ClassLoader会使用文件资源定位符的格式 (jar中资源有其专门的URL形式： jar:<url>!/{entry} )。

1.8怎样获取ClassLoader呢

Thread.currentThread().getContextClassLoader()和ClassLoader.getSystemClassLoader()如何选择？

分别在IDEA中运行、以jar的方式运行上面Controller的代码查看结果。

在IDEA开发工具中运行时直接调用ClassLoader.getSystemClassLoader()调用的是AppClassLoader，在IDEA环境时可以加载到target目录下的所有文件。而如果在springBoot项目的 jar方式运行时仍然还是用AppClassLoader去加载项目内的静态资源的话就会找不到的，因为springBoot加载静态资源文件是用的内置tomcat的classloader去加载的。

总结：

为了避免在项目中加载不到本项目中静态资源文件的BUG发生，调用静态资源的classLoader最好用Thread.currentThread().getContextClassLoader()方法来获取，因为一般同一个项目中java代码和其静态资源文件都是同一个classLoader来加载的，以此确保通过此classLoader也能加载到本项目中的资源文件。

遗留知识

1.SPI机制

2.字节码技术

3.SpringBoot的spring.factories原理

4.Dubbo的SPI扩展原理

预知后事如何，且听下回分解。

JMM的内容很多很深，已经尽量浓缩了。打字不容易，记得关注——收藏——转发哦。