【JVM】类加载机制

原文：【深入Java虚拟机】之四：类加载机制

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载七个阶段。它们开始的顺序如下图所示：

类加载的过程包括了加载、链接、初始化三个阶段。链接包括验证、准备、解析三个部分。

在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持java语言的运行时绑定（也成为动态绑定或晚期绑定）。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。

这里简要说明下java中的绑定：绑定指的是把一个方法的调用与方法所在的类(方法主体)关联起来，对java来说，绑定分为静态绑定和动态绑定：

静态绑定：即前期绑定。在程序执行前方法已经被绑定，此时由编译器或其它连接程序实现。针对java，简单的可以理解为程序编译期的绑定。java当中的方法只有final，static，private和构造方法是前期绑定的。

动态绑定：即晚期绑定，也叫运行时绑定。在运行时根据具体对象的类型进行绑定。在java中，几乎所有的方法都是后期绑定的。

下面详细讲述类加载过程中每个阶段所做的工作。

加载

加载是类加载过程的第一个阶段，在加载阶段，虚拟机需要完成以下三件事情：

1、通过一个类的全限定名来获取其定义的二进制字节流。

2、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

3、在java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口。

注意：这里第1条中的二进制字节流并不只是单纯地从Class文件中获取，比如它还可以从jar包中获取、从网络中获取（最典型的应用便是Applet）、由其他文件生成（JSP应用）等。如果输入数据不是 ClassFile 的结构，则会抛出 ClassFormatError。

第2条是指JVM分析并将这些二进制数据流转换为方法区(JVM的内存结构：方法区、堆，栈，本地方法栈，pc 寄存器)特定的数据结构（这些数据结构是实现有关的，不同 JVM 有不同实现）。这里处理了部分检验，比如类文件的魔数的验证，检查文件是否过长或者过短，确定是否有父类（除了 Obecjt 类）。

第3条要注意，有了对应的 Class 实例，并不意味着这个类已经完成了加载链链接！

相对于类加载的其他阶段而言，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器来完成加载。

加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，而且在java堆中也创建一个java.lang.Class类的对象，这样便可以通过该对象访问方法区中的这些数据。

类加载器和双亲委派机制

说到加载，不得不提到类加载器，下面就具体讲述下类加载器。

类加载器虽然只用于实现类的加载动作，但它在java程序中起到的作用却远远不限于类的加载阶段。对于任意一个类，都需要由它的类加载器和这个类本身一同确定其在就Java虚拟机中的唯一性，也就是说，即使两个类来源于同一个Class文件，只要加载它们的类加载器不同，那这两个类就必定不相等。这里的“相等”包括了代表类的Class对象的equals()、isAssignableFrom()、isInstance()等方法的返回结果，也包括了使用instanceof关键字对对象所属关系的判定结果。因此，即便是同样的java字节代码，被两个不同的类加载器定义之后，所得到的java类也是不同的。如果试图在两个类的对象之间进行赋值操作，会抛出java.lang.ClassCastException。这个特性为同样名称的java类在JVM中共存创造了条件。在实际的应用中，可能会要求同一名称的java类的不同版本在JVM中可以同时存在。通过类加载器就可以满足这种需求。这种技术在OSGI中得到了广泛的应用。

站在java虚拟机的角度来讲，只存在两种不同的类加载器：

1、启动类加载器：它使用C++实现（这里仅限于Hotspot，也就是JDK1.5之后默认的虚拟机，有很多其他的虚拟机是用java语言实现的），是虚拟机自身的一部分。
2、所有其他的类加载器：这些类加载器都由java语言实现，独立于虚拟机之外，并且全部继承自抽象类java.lang.ClassLoader，这些类加载器需要由启动类加载器加载到内存中之后才能去加载其他的类。

站在java开发人员的角度来看，类加载器可以大致划分为以下三类：

1、启动类加载器：Bootstrap ClassLoader
跟上面相同。它负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载）。启动类加载器是无法被java程序直接引用的。

2、扩展类加载器：Extension ClassLoader
该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载JDK\jre\lib\ext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库（如javax.*开头的类），开发者可以直接使用扩展类加载器。

3、应用程序类加载器：Application ClassLoader
该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

应用程序都是由这三种类加载器互相配合进行加载的，如果有必要，我们还可以加入自定义的类加载器。因为JVM自带的ClassLoader只是懂得从本地文件系统加载标准的java class文件，因此如果编写了自己的ClassLoader，便可以做到如下几点：

1）在执行非置信代码之前，自动验证数字签名。

2）动态地创建符合用户特定需要的定制化构建类。

3）从特定的场所取得java class，例如数据库中和网络中。

事实上当使用Applet的时候，就用到了特定的ClassLoader，因为这时需要从网络上加载java class，并且要检查相关的安全信息，应用服务器也大都使用了自定义的ClassLoader技术。

这几种类加载器的层次关系如下图所示：

这种层次关系称为类加载器的双亲委派模型。我们把每一层上面的类加载器叫做当前层类加载器的父加载器，当然，它们之间的父子关系并不是通过继承关系来实现的，而是使用组合关系来复用父加载器中的代码。该模型在JDK1.2期间被引入并广泛应用于之后几乎所有的java程序中，但它并不是一个强制性的约束模型，而是java设计者们推荐给开发者的一种类的加载器实现方式。

双亲委派模型的工作流程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类。

使用双亲委派模型来组织类加载器之间的关系，有一个很明显的好处，就是java类随着它的类加载器（说白了，就是它所在的目录）一起具备了一种带有优先级的层次关系，这对于保证Java程序的稳定运作很重要。例如，类java.lang.Object类存放在JDK\jre\lib下的rt.jar之中，因此无论是哪个类加载器要加载此类，最终都会委派给启动类加载器进行加载，这边保证了Object类在程序中的各种类加载器中都是同一个类。

链接

java类的链接指的是将java类的二进制代码合并到JVM的运行状态之中的过程。在链接之前，这个类必须被成功加载。

第二阶段是链接（Linking），这是核心的步骤，链接的过程比加载过程要复杂很多，这是实现java的动态性的重要一步！简单说是把原始的类定义信息平滑地转化入 JVM 运行的过程中。这里可进一步细分为三个步骤：

验证（Verification）
这是虚拟机安全的重要保障，JVM 需要核验字节信息是符合 java 虚拟机规范的，换言之，验证是用来确保Java类的二进制表示在结构上是完全正确的，否则就被认为是 java.lang.VerifyError，这样就防止了恶意信息或者不合规的信息危害 JVM 的运行，验证阶段有可能触发更多 class 的加载。

准备（Preparation）
创建类或接口中的静态变量，并初始化静态变量的初始值。但这里的“初始化”和下面的显式初始化阶段是有区别的，侧重点在于分配所需要的内存空间，不会去执行更进一步的 JVM 指令。

对类的成员变量分配空间。虽然有初始值，但这个时候不会对他们进行初始化（因为这里不会执行任何 java 代码）。具体如下：
所有原始类型的值都为 0。如 float: 0f, int: 0, boolean: 0(注意 boolean 底层实现大多使用 int)，引用类型则为 null。值得注意的是，JVM 可能会在这个时期给一些有助于程序运行效率提高的数据结构分配空间。

【JVM】关于类加载器准备阶段的一道面试题目

解析（Resolution）
在这一步会将常量池中的符号引用（symbolic reference）替换为直接引用。在java 虚拟机规范中，详细介绍了类、接口、方法和字段等各个方面的解析。

在一个java类中会包含对其它类或接口的形式引用，包括它的父类、所实现的接口、方法的形式参数和返回值的java类等。解析的过程就是确保这些被引用的类能被正确的找到。解析的过程可能会导致其它的java类被加载。

为类、接口、方法、成员变量的符号引用定位直接引用（如果符号引用先到常量池中寻找符号，再找先应的类型，无疑会耗费更多时间），完成内存结构的布局。

这一步是可选的。可以在符号引用第一次被使用时完成，即所谓的延迟解析(late resolution)。但对用户而言，这一步永远是延迟解析的，即使运行时会执行 early resolution，但程序不会显示的在第一次判断出错误时抛出错误，而会在对应的类第一次主动使用的时候抛出错误！

另外，这一步与之后的类初始化是不冲突的，并非一定要所有的解析结束以后才执行类的初始化。不同的 JVM 实现不同。

看下面一段代码：

public class LinkTest {   
   public static void main(String[] args) {       
      ToBeLinked toBeLinked = null;       
      System.out.println("Test link.");   
   }
}

类 LinkTest引用了类ToBeLinked，但是并没有真正使用它，只是声明了一个变量，并没有创建该类的实例或是访问其中的静态域。如果把编译好的ToBeLinked的java字节代码删除之后，再运行LinkTest，程序不会抛出错误。这是因为ToBeLinked类没有被真正用到。链接策略使得ToBeLinked类不会被加载，因此也不会发现ToBeLinked的java字节代码实际上是不存在的。如果把代码改成ToBeLinked toBeLinked = new ToBeLinked();之后，再按照相同的方法运行，就会抛出异常了。因为这个时候ToBeLinked这个类被真正使用到了，会需要加载这个类。

下面对验证、准备、解析阶段进行详细分析。

验证

验证的目的是为了确保Class文件中的字节流包含的信息符合当前虚拟机的要求，而且不会危害虚拟机自身的安全。不同的虚拟机对类验证的实现可能会有所不同，但大致都会完成以下四个阶段的验证：文件格式的验证、元数据的验证、字节码验证和符号引用验证。

文件格式的验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理，该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。经过该阶段的验证后，字节流才会进入内存的方法区中进行存储，后面的三个验证都是基于方法区的存储结构进行的。

元数据验证：对类的元数据信息进行语义校验（其实就是对类中的各数据类型进行语法校验），保证不存在不符合java语法规范的元数据信息。

字节码验证：该阶段验证的主要工作是进行数据流和控制流分析，对类的方法体进行校验分析，以保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。

符号引用验证：这是最后一个阶段的验证，它发生在虚拟机将符号引用转化为直接引用的时候（解析阶段中发生该转化，后面会有讲解），主要是对类自身以外的信息（常量池中的各种符号引用）进行匹配性的校验。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：

1、这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在java堆中。

2、这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在java代码中被显式地赋予的值。

假设一个类变量的定义为：

public static int value = 3；

那么变量value在准备阶段过后的初始值为0，而不是3，因为这时候尚未开始执行任何java方法，而把value赋值为3的putstatic指令是在程序编译后，存放于类构造器<clinit>()方法之中的，所以把value赋值为3的动作将在初始化阶段才会执行。

下表列出了java中所有基本数据类型以及reference类型的默认零值：

这里还需要注意如下几点：

Ⅰ 对基本数据类型来说，对于类变量（static）和全局变量，如果不显式地对其赋值而直接使用，则系统会为其赋予默认的零值，而对于局部变量来说，在使用前必须显式地为其赋值，否则编译时不通过。

Ⅱ 对于同时被static和final修饰的常量，必须在声明的时候就为其显式地赋值，否则编译时不通过；而只被final修饰的常量则既可以在声明时显式地为其赋值，也可以在类初始化时显式地为其赋值，总之，在使用前必须为其显式地赋值，系统不会为其赋予默认零值。

Ⅲ 对于引用数据类型reference来说，如数组引用、对象引用等，如果没有对其进行显式地赋值而直接使用，系统都会为其赋予默认的零值，即null。

Ⅳ 如果在数组初始化时没有对数组中的各元素赋值，那么其中的元素将根据对应的数据类型而被赋予默认的零值。

3、如果类字段的字段属性表中存在ConstantValue属性，即同时被final和static修饰，那么在准备阶段变量value就会被初始化为ConstValue属性所指定的值。

假设上面的类变量value被定义为：

public static final int value = 3；

编译时javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为3。可以理解为static final常量在编译期就将其结果放入了调用它的类的常量池中。注意此处与第2点的区别，第2点的例子public static int value = 3；只被static修饰，在准备阶段该value只会被初始化为基本数据类型的默认零值0。

解析

解析阶段是虚拟机将常量池中的符号引用转化为直接引用的过程。在Class类文件结构一文中已经比较过了符号引用和直接引用的区别和关联，这里不再赘述。前面说解析阶段可能开始于初始化之前，也可能在初始化之后开始，虚拟机会根据需要来判断，到底是在类被加载器加载时就对常量池中的符号引用进行解析（初始化之前），还是等到一个符号引用将要被使用前才去解析它（初始化之后）?

对同一个符号引用进行多次解析请求时很常见的事情，虚拟机实现可能会对第一次解析的结果进行缓存（在运行时常量池中记录直接引用，并把常量标示为已解析状态），从而避免解析动作重复进行。

解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行，分别对应于常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info四种常量类型。

1、类或接口的解析：判断所要转化成的直接引用是对数组类型，还是普通的对象类型的引用，从而进行不同的解析。
2、字段解析：对字段进行解析时，会先在本类中查找是否包含有简单名称和字段描述符都与目标相匹配的字段，如果有，则查找结束；如果没有，则会按照继承关系从上往下递归搜索该类所实现的各个接口和它们的父接口，还没有，则按照继承关系从上往下递归搜索其父类，直至查找结束，查找流程如下图所示：

从下面一段代码的执行结果中很容易看出来字段解析的搜索顺序：

class Super{  
    public static int m = 11;  
    static{  
        System.out.println("执行了super类静态语句块");  
    }  
}  
  
  
class Father extends Super{  
    public static int m = 33;  
    static{  
        System.out.println("执行了父类静态语句块");  
    }  
}  
  
class Child extends Father{  
    static{  
        System.out.println("执行了子类静态语句块");  
    }  
}  
  
public class StaticTest{  
    public static void main(String[] args){  
        System.out.println(Child.m);  
    }  
}  

执行结果如下：

执行了super类静态语句块
执行了父类静态语句块
33

如果注释掉Father类中对m定义的那一行，则输出结果如下：

执行了super类静态语句块
11

这里我们便可以分析如下：static变量发生在静态解析阶段，也即是初始化之前，此时已经将字段的符号引用转化为了内存引用，也便将它与对应的类关联在了一起，由于在子类中没有查找到与m相匹配的字段，那么m便不会与子类关联在一起，因此并不会触发子类的初始化。

最后需要注意：理论上是按照上述顺序进行搜索解析，但在实际应用中，虚拟机的编译器实现可能要比上述规范要求的更严格一些。如果有一个同名字段同时出现在该类的接口和父类中，或同时在自己或父类的接口中出现，编译器可能会拒绝编译。如果对上面的代码做些修改，将Super改为接口，并将Child类继承Father类且实现Super接口，那么在编译时会报出如下错误：

StaticTest.java:24: 对 m 的引用不明确，Father 中的 变量 m 和 Super 中的 变量 m

都匹配
                System.out.println(Child.m);
                                        ^
1 错误

3、类方法解析：对类方法的解析与对字段解析的搜索步骤差不多，只是多了判断该方法所处的是类还是接口的步骤，而且对类方法的匹配搜索，是先搜索父类，再搜索接口。

4、接口方法解析：与类方法解析步骤类似，只是接口不会有父类，因此，只递归向上搜索父接口就行了。

初始化

初始化是类加载过程的最后一步，到了此阶段，才真正开始执行类中定义的java程序代码。

在准备阶段，类变量（static）已经被赋过一次系统要求的初始值，而在初始化阶段，则是根据程序员通过程序指定的主观计划去初始化类变量和其他资源，或者可以从另一个角度来表达：初始化阶段是执行类构造器<clinit>()方法的过程。

在编译生成的Class文件时,会自动产生两个方法,一个是类的初始化方法<clinit>,另一个是实例的初始化方法<init>。可以简单理解为<clinit>是用户初始化静态变量和静态块的，且只执行一次，而<init>是用于对象实例化的构造器方法，每次对象实例化时都会调用。

1、 <clinit>方法在JVM第一次加载Class文件时调用(所以静态块只会执行一次),包括静态块的执行和静态变量初始化。
2、<init>方法在实例(对象)创建时候调用, 就是生成对象的时候, 例如new ,反射等等。

这里简单说明下<clinit>()方法的执行规则:

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

2、<clinit>()方法与实例构造器<init>()方法（类的构造函数）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕，所以父类的静态块等要优先于子类的操作。因此，在虚拟机中第一个被执行的<clinit>()方法的类肯定是java.lang.Object。

3、<clinit>()方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对类变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。

4、接口中不能使用静态语句块，但仍然有类变量（final static）初始化的赋值操作，因此接口与类一样会生成<clinit>()方法。但是接口鱼类不同的是：执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法，只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。

5、虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时很长的操作，那就可能造成多个线程阻塞，在实际应用中这种阻塞往往是很隐蔽的。

下面给出一个简单的例子，以便更清晰地说明如上规则：

class Father{  
    public static int a = 1;  
    static{  
        a = 2;  
    }  
}  
  
class Child extends Father{  
    public static int b = a;  
}  
  
public class ClinitTest{  
    public static void main(String[] args){  
        System.out.println(Child.b);  
    }  
}  

执行上面的代码，会打印出2，也就是说b的值被赋为了2。

我们来看得到该结果的步骤。
1、首先在准备阶段为类变量分配内存并设置类变量初始值，这样A和B均被赋值为默认值0；
2、而后再在调用<clinit>()方法时（初始化阶段），给他们赋予程序中指定的值。当我们调用Child.b时，触发Child的<clinit>()方法，根据规则2，在此之前，要先执行完其父类Father的<clinit>()方法，又根据规则1，在执行<clinit>()方法时，需要按static语句或static变量赋值操作等在代码中出现的顺序来执行相关的static语句，因此当触发执行Father的<clinit>()方法时，会先将a赋值为1，再执行static语句块中语句，将a赋值为2，而后再执行Child类的<clinit>()方法，这样便会将b的赋值为2。

如果我们颠倒一下Father类中public static int a = 1;语句和static语句块的顺序，程序执行后，则会打印出1。

class Father{  

    static{  
        a = 2;  
    }
    
    public static int a = 1;//与上面的静态代码块调换了位置
}  

很明显是根据规则1，执行Father的<clinit>()方法时，根据顺序先执行了static语句块中的内容，后执行了public static int a = 1;语句。

另外，在颠倒二者的顺序之后，如果在static语句块中对a进行访问（比如将a赋给某个变量），在编译时将会报错，因为根据规则1，它只能对a进行赋值，而不能访问。

JVM初始化补充说明

类的初始化也是延迟的，直到类第一次被主动使用(active use)，JVM 才会初始化类。

Java类主动使用情况，会导致类的初始化：
1）创建类的实例
2）访问某个类或接口的静态变量，或者对该静态变量赋值
3）调用类的静态方法
4）反射（如Class.forName("com.bunny.Test")）
5）初始化一个类的子类
6）Java虚拟机启动时被表明为启动类的类（JavaTest）

其他使用java类方式，都可以被看作是被动使用，都不会导致类的初始化。

package com.evada.de;

class ChildClass extends  ClassUsed{
    public static int c = 0;
}


public class ClassUsed {

    public static int a = 0;

    public static void main(String[] args) throws Exception{

        /** 创建类的实例  **/
        ClassUsed classUsed = new ClassUsed();

        /** 访问某个类或接口的静态变量，或者对该静态变量赋值 **/
        int b = ClassUsed.a;

        /** 调用类的静态方法  **/
        ClassUsed.test();

        /** 反射 **/
        Class.forName("com.bunny.Test");

        /** 初始化一个类的子类 **/
        ChildClass.c = 10;

        /** Java虚拟机启动时被表明为启动类的类 **/
        //java com.hwy.MyTest
    }

    public static void test(){

    }
}

当一个java类第一次被真正使用到的时候，JVM会进行该类的初始化操作。初始化过程的主要操作是执行静态代码块和初始化静态域。在一个类被初始化之前，它的直接父类也需要被初始化。但是，一个接口的初始化，不会引起其父接口的初始化。在初始化的时候，会按照源代码中从上到下的顺序依次执行静态代码块和初始化静态域。(具体规则参见上面<clinit>()方法的执行规则)

public class StaticTest {   
   public static int X = 10;   
   public static void main(String[] args) {       
      System.out.println(Y); //输出60   
   }   
   static {       
      X = 30;   
   }  
   public static int Y = X * 2;
}

在上面的代码中，在初始化的时候，静态域的初始化和静态代码块的执行会从上到下依次执行。因此变量X的值首先初始化成10，后来又被赋值成30；而变量Y的值则被初始化成60。

类的初始化分两步：

1.如果基类没有被初始化，初始化基类。
2.有类构造函数，则执行类构造函数。

类构造函数是由 java 编译器完成的。它把类成员变量的初始化和 static 区间的代码提取出，放到一个<clinit>方法中。这个方法不能被一般的方法访问（注意，static final 成员变量不会在此执行初始化，它一般被编译器生成 constant 值，在准备阶段第3点有说明，准备阶段就会对static final 常量初始化）。同时，<clinit>中是不会显示的调用基类的<clinit>的，因为 1 中已经执行了基类的初始化（详细规则在上面<clinit>()方法的执行规则第2点）。该初始化过程是由 JVM 保证线程安全的。

java类和接口的初始化只有在特定的时机才会发生，这些时机包括：

1、创建一个java类的实例。如

MyClass obj = new MyClass()

2、调用一个java类中的静态方法。如

MyClass.sayHello()

3、给java类或接口中声明的静态域赋值。如

MyClass.value = 10

4、访问java类或接口中声明的静态域，并且该域不是常值变量。如

int value = MyClass.value

5、在顶层java类中执行assert语句。

通过 java 反射 API 也可能造成类和接口的初始化。需要注意的是，当访问一个java类或接口中的静态域的时候，只有真正声明这个域的类或接口才会被初始化。考虑下面的代码：

class B {   
   static int value = 100;   
   static {       
      System.out.println("Class B is initialized."); //输出   
   }
}
class A extends B {   
   static {       
      System.out.println("Class A is initialized."); //不会输出   
   }
}
public class InitTest {   
   public static void main(String[] args) {       
      System.out.println(A.value); //输出100   
   }
}

在上述代码中，类InitTest通过A.value引用了类B中声明的静态域value。由于value是在类B中声明的，只有类B会被初始化，而类A则不会被初始化。

总结

整个类加载过程中，除了在加载阶段用户应用程序可以自定义类加载器参与之外，其余所有的动作完全由虚拟机JVM主导和控制。

到了初始化才开始执行类中定义的java程序代码（即字节码），但这里的执行代码只是个开端，它仅限于<clinit>()方法。

类加载过程中主要是将Class文件（准确地讲，应该是类的二进制字节流）加载到虚拟机内存中，真正执行字节码的操作，在加载完成后才真正开始。

对于某个特定的类加载器来说，一个 java 类只能被载入一次，也就是说在JVM中，类的完整标识是（classLoader，package，className）。

另外一个类可以被不同的类加载器加载，但是，同一个类，由不同的类加载器实例加载的话，会在方法区产生两个不同的类，彼此不可见，并且在堆中生成不同 Class 实例。

如果使用的类加载器没有重写ClassLoader中的getSystemClassLoader方法，那么使用的都是AppClassLoader的同一个实例进行类的加载的，所以加载同一个类在内存中只有一个类，即所有通过正常双亲委派模式的类加载器加载的classpath和ext下的所有类在方法区都是同一个类，堆中的Class实例也是同一个。

参考资料：
Java类的加载、链接和初始化
自定义类加载器加载类遇到的问题
关于static的加载顺序
极客时间：第23讲 | 请介绍类加载过程，什么是双亲委派模型？