什么是类的加载机制？
java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验，转换解析和初始化，最终形成可以被虚拟机直接使用的java类型，这就是虚拟机的加载机制。* Class文件由类装载器装载后，在JVM中将形成一份描述Class结构的元信息对象，通过该元信息对象可以获知Class的结构信息：如构造函数，属性和方法等，Java允许用户借由这个Class相关的元信息对象间接调用Class对象的功能,这里就是我们经常能见到的Class类。
类加载的过程
- 装载：查找和导入Class文件；
- 通过类的全限定名（包名 + 类名），获取到该类的.class文件的二进制字节流,将二进制字节流所代表的静态存储结构，转化为方法区运行时的数据结构,在内存中生成一个代表该类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口
- 链接：把类的二进制数据合并到JRE中；
-
链接是指将上面创建好的class类合并至Java虚拟机中，使之能够执行的过程，可分为
验证、准备、解析三个阶段- 验证：检查载入Class文件数据的正确性；
- 确保class文件中的字节流包含的信息，符合当前虚拟机的要求，保证这个被加载的class类的正确性，不会危害到虚拟机的安全。
- 准备：给类的静态变量分配存储空间；
- 为类中的
静态字段分配内存，并设置默认的初始值，比如int类型初始值是0。被final修饰的static字段不会设置，因为final在编译的时候就分配了
- 为类中的
- 解析：将符号引用转成直接引用；
- 解析阶段的目的，是将常量池内的符号引用转换为直接引用的过程（将常量池内的符号引用解析成为实际引用）。如果符号引用指向一个未被加载的类，或者未被加载类的字段或方法，那么解析将触发这个类的加载（但未必触发这个类的链接以及初始化。）
- 验证：检查载入Class文件数据的正确性；
- 初始化：对类的静态变量，静态代码块执行初始化操作；
-
初始化就是执行类的构造器方法
init()的过程。这个方法不需要定义，是javac编译器自动收集类中所有类变量的赋值动作和静态代码块中的语句合并来的。
若该类具有父类，
jvm会保证父类的init先执行，然后在执行子类的init。
类加载器的分类
- 启动类/引导类：Bootstrap ClassLoader
-
这个类加载器使用C/C++语言实现的，嵌套在JVM内部，java程序无法直接操作这个类。
它用来加载Java核心类库，如：
JAVA_HOME/jre/lib/rt.jar、resources.jar、sun.boot.class.path路径下的包，用于提供jvm运行所需的包。
- 扩展类加载器：Extension ClassLoader
- Java语言编写，由
sun.misc.Launcher$ExtClassLoader实现，我们可以用Java程序操作这个加载器，派生继承自java.lang.ClassLoader，父类加载器为启动类加载器。从系统属性：java.ext.dirs目录中加载类库，或者从JDK安装目录：jre/lib/ext目录下加载类库。我们就可以将我们自己的包放在以上目录下，就会自动加载进来了。
- 应用程序类加载器：Application Classloader
- Java语言编写，由
sun.misc.Launcher$AppClassLoader实现。派生继承自java.lang.ClassLoader，父类加载器为启动类加载器，它负责加载环境变量classpath或者系统属性java.class.path指定路径下的类库，它是程序中默认的类加载器，我们Java程序中的类，都是由它加载完成的。我们可以通过ClassLoader#getSystemClassLoader()获取并操作这个加载器
- 自定义加载器
-
一般情况下，以上3种加载器能满足我们日常的开发工作，不满足时，我们还可以自定义加载器。
比如用网络加载Java类，为了保证传输中的安全性，采用了加密操作，那么以上3种加载器就无法加载这个类，这时候就需要
自定义加载器 -
自定义加载器实现步骤
继承
java.lang.ClassLoader类，重写findClass()方法。如果没有太复杂的需求，可以直接继承URLClassLoader类，重写loadClass方法，具体可参考AppClassLoader和ExtClassLoader。
双亲委派机制
概述
-
jvm对class文件采用的是按需加载的方式，当需要使用该类时，jvm才会将它的class文件加载到内存中产生class对象。在加载类的时候，是采用的双亲委派机制，即把请求交给父类处理的一种任务委派模式。
-
如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的加载器都是如此，因此所有的类加载请求都会传给顶层的启动类加载器，只有当父加载器反馈自己无法完成该加载请求（该加载器的搜索范围中没有找到对应的类）时，子加载器才会尝试自己去加载。
为什么要用双亲委派机制？
- 委托双亲的模式保证了Java核心不会被恶心篡改。例如java.lang.Object类，无论哪个类加载器去加载该类，最终都是由启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。否则的话，如果不使用该模型的话，如果用户自定义一个java.lang.Object类且存放在classpath中，那么系统中将会出现多个Object类，应用程序也会变得很混乱。如果我们自定义一个rt.jar中已有类的同名Java类，会发现JVM可以正常编译，但该类永远无法被加载运行。
反向委派机制
-
tomcat
可以看图中的 WebAppClassLoader，它加载自己目录下的 .class 文件，并不会传递给父类的加载器。但是，它却可以使用 SharedClassLoader 所加载的类，实现了共享和分离的功能。
但是你自己写一个 ArrayList，放在应用目录里，tomcat 依然不会加载。它只是自定义的加载器顺序不同，但对于顶层来说，还是一样的。（也就是仍会自上而下检查是否有相同类已经加载）
- SPI
Java 中有一个 SPI 机制，全称是 Service Provider Interface，是 Java 提供的一套用来被第三方实现或者扩展的 API，它可以用来启用框架扩展和替换组件。
- 在Java应用中存在着很多服务提供者接口（Service Provider Interface，SPI），这些接口允许第三方为它们提供实现，如常见的 SPI 有 JDBC、JNDI等，这些 SPI 的接口属于 Java 核心库，一般存在rt.jar包中，由Bootstrap类加载器加载。而Bootstrap类加载器无法直接加载SPI的实现类，同时由于双亲委派模式的存在，Bootstrap类加载器也无法反向委托AppClassLoader加载器SPI的实现类。在这种情况下，我们就需要一种特殊的类加载器来加载第三方的类库，而 线程上下文类加载器（双亲委派模型的破坏者）就是很好的选择。
从图可知rt.jar核心包是有Bootstrap类加载器加载的，其内包含SPI核心接口类，由于SPI中的类经常需要调用外部实现类的方法，而jdbc.jar包含外部实现类(jdbc.jar存在于classpath路径)无法通过Bootstrap类加载器加载，因此只能委派线程上下文类加载器把jdbc.jar中的实现类加载到内存以便SPI相关类使用。显然这种线程上下文类加载器的加载方式破坏了“双亲委派模型”，它在执行过程中抛弃双亲委派加载链模式，使程序可以逆向使用类加载器，当然这也使得Java类加载器变得更加灵活。
沙箱安全机制
自定义 String 类，但是在加载自定义 String 类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载 JDK 自带的文件（rt.jar 包中的 javalangString.class），报错信息说没有 main 方法就是因为加载的 rt.jar 包中的 String 类。这样可以保证对 Java 核心源代码的保护，这就是沙箱安全机制。
