类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)7个阶段。其中准备、验证、解析3个部分统称为连接（Linking）。如图所示

【领取资料】

加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）

加载

在加载阶段（可以参考java.lang.ClassLoader的loadClass()方法），虚拟机需要完成以下3件事情：

通过一个类的全限定名来获取定义此类的二进制字节流（并没有指明要从一个Class文件中获取，可以从其他渠道，譬如：网络、动态生成、数据库等）；
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构；
在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口；

加载阶段和连接阶段（Linking）的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。

验证

验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。验证阶段大致会完成4个阶段的检验动作：

文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以魔术0xCAFEBABE开头（当class文件以二进制形式打开，会看到这个文件头，cafebabe）、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了java.lang.Object之外。
字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
符号引用验证：确保解析动作能正确执行。

验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在堆中。其次，这里所说的初始值通常情况下是数据类型的零值，假设一个类变量的定义为：

有通常情况就有特殊情况，这里的特殊是指：

【领取资料】

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。

初始化

在介绍初始化时，要先介绍两个方法：<clinit> 和 <init> :

在编译生成class文件时，会自动产生两个方法，一个是类的初始化方法, 另一个是实例的初始化方法
clinit>：在jvm第一次加载class文件时调用，包括静态变量初始化语句和静态块的执行
<init>: 在实例创建出来的时候调用，包括调用new操作符；调用 Class 或 Java.lang.reflect.Constructor 对象的newInstance()方法；调用任何现有对象的clone()方法；通过 java.io.ObjectInputStream 类的getObject() 方法反序列化。

类初始化阶段是类加载过程的最后一步，到了初始化阶段，才真正开始执行类中定义的java程序代码。在准备极端，变量已经付过一次系统要求的初始值，而在初始化阶段，则根据程序猿通过程序制定的主管计划去初始化类变量和其他资源，或者说：初始化阶段是执行类构造器<clinit>()方法的过程.

<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块 static 中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。如下：

那么去掉报错的那句，改成下面：

输出结果：1

为什么输出结果是 1，在准备阶段我们知道 i=0，然后类初始化阶段按照顺序执行，首先执行 static 块中的 i=0,接着执行 static赋值操作i=1, 最后在 main 方法中获取 i 的值为1

<clinit>()方法与实例构造器<init>()方法不同，它不需要显示地调用父类构造器，虚拟机会保证在子类<init>()方法执行之前，父类的<clinit>()方法方法已经执行完毕
由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
<clinit>()方法对于类或者接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生产<clinit>()方法。
接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法。但接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。
虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确的加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个线程阻塞，在实际应用中这种阻塞往往是隐藏的。

让我们来验证上面的加载规则

【领取资料】

验证 1: 虚拟机会保证在子类<init>()方法执行之前，父类的<clinit>()方法方法已经执行完毕

输出结果

SSClass
SuperClass init!
123

**验证 2: **通过数组定义来引用类，不会触发此类的初始化(我的理解是数组的父类是Object)

输出结果：无

验证3 常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化

输出结果：

hello world

验证小结

虚拟机规范严格规定了有且只有5中情况（jdk1.7）必须对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

遇到 new, getstatic, putstatic, invokestatic 这些字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译器把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。
使用 java.lang.reflect 包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。
当使用jdk1.7动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果REF_getstatic, REF_putstatic, REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类没有进行初始化，则需要先出触发其初始化。

有了这个加载规则的印象，双亲委派模型就很好理解了，别着急，继续向下看, 你会发现你的理解层面提高了

双亲委派模型

刚看到这个词汇的时候我是完全懵懂的状态，其实就是定义了 JVM 启动的时候类的加载规则, 大家要按规矩办事，好办事，来看下图：

所谓双亲委派是指每次收到类加载请求时，先将请求委派给父类加载器完成（所有加载请求最终会委派到顶层的Bootstrap ClassLoader加载器中），如果父类加载器无法完成这个加载（该加载器的搜索范围中没有找到对应的类），子类尝试自己加载，如果都没加载到，则会抛出 ClassNotFoundException 异常，看到这里其实就解释了文章开头提出的第一个问题，父加载器已经加载了JDK 中的 String.class 文件，所以我们不能定义同名的 String java 文件。

【领取资料】

为什么会有这样的规矩设定？

因为这样可以避免重复加载，当父亲已经加载了该类的时候，就没有必要 ClassLoader 再加载一次。考虑到安全因素，我们试想一下，如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代java核心api中定义的类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String 已经在启动时就被引导类加载器（Bootstrcp ClassLoader）加载，所以用户自定义的ClassLoader永远也无法加载一个自己写的String，除非你改变 JDK 中 ClassLoader 搜索类的默认算法。

我们发现除了启动类加载器（BootStrap ClassLoader），每个类都有其"父类"加载器

⚠️ 其实这里的父子关系是组合模式，不是继承关系来实现

从图中可以看到类 AppClassLoader 和 ExtClassLoader 都继承 URLClassLoader，而 URLClassLoader 又继承 ClassLoader，在 ClassLoader 中有一个属性

在通过构造函数实例化 AppClassLoader 和 ExtClassLoader 的时候都要传入一个 classloader 作为当前 classloader 的 parent

顶层ClassLoader有几个函数很关键，先有个印象

【领取资料】

指定保护域（protectionDomain），把ByteBuffer的内容转换成 Java 类，这个方法被声明为final的

把字节数组 b中的内容转换成 Java 类，其开始偏移为off,这个方法被声明为final的

查找指定名称的类

链接指定的类

类加载器责任范围

上面我们提到每个加载器都有对应的加载搜索范围

Bootstrap ClassLoader:这个加载器不是一个Java类，而是由底层的c++实现，负责在虚拟机启动时加载Jdk核心类库（如：rt.jar、resources.jar、charsets.jar等）以及加载后两个类加载器。这个ClassLoader完全是JVM自己控制的，需要加载哪个类，怎么加载都是由JVM自己控制，别人也访问不到这个类
Extension ClassLoader:是一个普通的Java类，继承自ClassLoader类，负责加载JAVA_HOME/jre/lib/ext/目录下的所有jar包。
App ClassLoader：是Extension ClassLoader的子对象，负责加载应用程序classpath目录下的所有jar和class文件。

大家自行运行这个文件，就可以看到每个类加载器加载的文件了

【领取资料】

两种类的加载方式

通常用这两种方式来动态加载一个 java 类，Class.forName() 与 ClassLoader.loadClass() 但是两个方法之间也是有一些细微的差别

Class.forName() 方式

查看Class类的具体实现可知，实质上这个方法是调用原生的方法：

形式上类似于Class.forName(name,true,currentLoader)。综上所述，Class.forName 如果调用成功会：

保证一个Java类被有效得加载到内存中；
类默认会被初始化，即执行内部的静态块代码以及保证静态属性被初始化；
默认会使用当前的类加载器来加载对应的类。

ClassLoader.loadClass方式

如果采用这种方式的类加载策略，由于双亲托管模型的存在，最终都会将类的加载任务交付给Bootstrap ClassLoader进行加载。跟踪源代码，最终会调用原生方法：

与此同时，与上一种方式的最本质的不同是，类不会被初始化，只有显式调用才会进行初始化。综上所述，ClassLoader.loadClass 如果调用成功会：

类会被加载到内存中；
类不会被初始化，只有在之后被第一次调用时类才会被初始化；
之所以采用这种方式的类加载，是提供一种灵活度，可以根据自身的需求继承ClassLoader类实现一个自定义的类加载器实现类的加载。（很多开源Web项目中都有这种情况，比如tomcat，struct2，jboss。原因是根据Java Servlet规范的要求，既要Web应用自己的类的优先级要高于Web容器提供的类，但同时又要保证Java的核心类不被任意覆盖，此时重写一个类加载器就很必要了）

双亲委派模型是什么？

说完了类加载器，下面我们就说一下什么是双亲委派模型吧。

其是在JDK1.2期间被引入的，而后陆续被推荐给开发者，到目前已经成为了最常用的类加载器实现方式了。

双亲委派整个过程分为以下几步：

假设用户刚刚摸鱼写的Test类想进行加载，这个时候首先会发送给应用程序类加载器AppCloassLoader；
然后AppClassLoader并不会直接去加载Test类，而是会委派于父类加载器完成此操作，也就是ExtClassLoader；
ExtClassLoader同样也不会直接去加载Test类，而是会继续委派于父类加载器完成，也就是BootstrapClassLoader；
BootstrapClassLoader这个时候已经到顶层了，没有父类加载器了，所以BootstrapClassLoader会在jdk/lib目录下去搜索是否存在，因为这里是用户自己写的Test类，是不会存在于jdk下的，所以这个时候会给子类加载器一个反馈。
ExtClassLoader收到父类加载器发送的反馈，知道了父类加载器并没有找到对应的类，爸爸靠不住，就只能自己来加载了，结果显而易见，自己也不行，没办法，只能给更下面的子类加载器了。
AppClassLoader收到父类加载器的反馈，顿时明白，原来爸爸虽然是爸爸，但是他终究不能管儿子的私事，所以这时候，AppClassLoader就自己尝试去加载。
结果，就这样成功了，走了一大圈，兜兜转转还是自己干。

这个并没有那么复杂，我就不画图了哈，大家如果想看图，可以去网上再搜一下，我记得有个大佬画的就很形象。

为什么要使用双亲委派模型？

使用双亲委派模型，有一个很大的好处，就是避免原始类被覆盖的问题。

比如，用户编写了一个Object类，放入程序中加载。

当没有双亲委派机制时，就会出现重复的Object类，会给开发人员造成很大的困扰，本来就只需要基于JDK开发就好了，现在还得把JDK中的类全记住，避免编写重复的类。

当存在双亲委派机制时呢，整个事情就不一样了，每次加载类时，都会遵循双亲委派机制，去问父类是否可以加载，如果可以呢，那就不需要再次加载了，这样事情就变得简单了。（老子走的路，小子不能走》.《）

如何打破双亲委派模型？

这个问题，其实就算是双亲委派模型中最深入的问题了，最起码中高级工程师面试，问到这也就下个话题了。

这里我也简单说一下吧，最常见的也是人们常说的有两种，分别是：

在自定义类加载器中，重写loadClass方法。
【领取资料】

为什么呢？因为如果你去看ClassLoader类的源码时，你会发现，双亲委派的核心代码就是在这个方法中的；试想，你如果重写了这个方法，自然而然的就打破了双亲委派机制了。

使用线程上下文类加载器

因为双亲委派机制不能支持SPI(Service Provider Interface), 所以才会引入线程上下文类加载器，有了它，就可以打通双亲委派模型的层次结构来反向使用类加载器来完成类加载。

这个目前也是没有办法的事，涉及到SPI的目前都在使用这种方式来完成类加载，其中就包括常用到的JNDI、JDBC、JAXB等。

这里其实还有一个可以打破双亲委派模型的情况，那就是OSGI，这个解释是在《深入理解 Java虚拟机》这本书中，可能是这本书的作者本身就对OSGI比较熟悉，而且看简介还出过一本OSGI的书。

在很多应用环境中，OSGI被当做模块化热部署实现的关键，所以，这样就说明了，OSGI一定会对类加载过程做相应的一些措施。

因为这个并不常碰到，还是大家自行去查看吧，我就不在这赘述了。

以上是关于“双亲委派机制”的主要内容，如果未能解决你的问题，请参考以下文章

电脑每次开机都会弹这个错误框

我的查询有啥问题？为啥每次单击列按钮时都会出错？ [关闭]

我的程序有啥问题？我希望保存坐标值，但每次循环后它都会重置为 0,0

PlayFramework 每次启动都会解决依赖关系

为啥很多文件都会过期？

为啥，每次打开EXcel都会这个窗口，所以导致每次都要开两次才行！

“双 亲 委 派 机 制”