类加载的过程

淡淡的烟草味﹌ 2022-03-10 14:17 225阅读 0赞

### 类加载的过程 ###

*   *  加载
     *  验证
     *  准备
     *  解析
     *  初始化

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括了：**加载**（Loading）、**验证**（Verification）、**准备**（Preparation）、**解析**（Resolution）、**初始化**（Initialization）、**使用**（Using）和**卸载**（Unloading）七个阶段。其中验证、准备和解析三个部分统称为连接（Linking），这七个阶段的发生顺序如图所示。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNjU4NjEyMA_size_16_color_FFFFFF_t_70]  
加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）。请注意这里写的是按部就班地“开始”，而不是按部就班地“进行”或“完成”，因为这些阶段通常都是互相交叉地混合式进行的，通常会在一个阶段执行的过程中调用或激活另外一个阶段。

什么情况下需要开始类加载过程的第一个阶段：加载。虚拟机规范中并没有进行强制约束，这点可以交给虚拟机的具体实现来自由把握。

但是对于初始化阶段，虚拟机规范则是严格规定了有且只有四种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：  
（1）遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。  
（2）使用java.lang.reflect包的方法对类进行发射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。  
（3）当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。  
（3）当虚拟机启动时，用户需要指定一个要执行的主类（包含main（）方法的那个类），虚拟机会先初始化这个主类。

这四种场景中的行为称为对一个类进行主动引用。除此之外所有引用类的方式，都不会触发初始化，称为被动引用。

**被动使用类字段演示一：** 通过子类引用父类的静态字段，不会导致子类初始化

public class SuperClass{
     static{ System.out.println（"SuperClass init！"）； } 
    public static int value=123； 
    } 
    public class SubClass extends SuperClass{
     static{ System.out.println（"SubClass init！"）； } 
    } 
    
    public class NotInitialization{ 
    public static void main（String[]args）{
    System.out.println（SubClass.value）； 
    } 
    }

上述代码运行之后，只会输出“`SuperClass init！`”，而不会输出“SubClass init！”。**对于静态字段，只有直接定义这个字段的类才会被初始化**，**因此通过其子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化**。至于是否要触发子类的加载和验证，在虚拟机规范中并未明确规定，这点取决于虚拟机的具体实现。

**被动使用类字段演示二：** 通过数组定义来引用类，不会触发此类的初始化

public class NotInitialization{ 
    public static void main（String[]args）{
     SuperClass[]sca=new SuperClass[10]； 
    } 
    }

运行之后发现没有输出"SuperClass init！"

**被动使用类字段演示三：** 常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此不会触发定义常量的类 的初始化。

public class ConstClass{
    static{ System.out.println（"ConstClass init！"）； } 
    public static final String HELLOWORLD="hello world"； 
    } 
    
    public class NotInitialization{ 
    public static void main（String[]args）{
     System.out.println（ConstClass.HELLOWORLD）； 
    } 
    }

上述代码运行之后，也没有输出“ConstClass init！”，这是因为虽然在Java源码中引用了ConstClass类中的常量HELLOWORLD，但是**在编译阶段将此常量的值“hello world”存储到了`NotInitialization`类的常量池中**，对常量`ConstClass.HELLOWORLD`的引用实际都被转化为`NotInitialization`类对自身常量池的引用了。  
也就是说实际上`NotInitialization`的Class文件之中并没有`ConstClass`类的符号引用入口，这两个类在编译成Class之后就不存在任何联系了。

接口的加载过程与类加载过程稍有一些不同，针对接口需要做一些特殊说明：

1.  接口也有初始化过程，这点与类是一致的，而接口中不能使用“static\{\}”语句块
2.  但编译器仍然会为接口生成“＜clinit＞（）”类构造器 ，用于初始化接口中所定义的成员变量。

接口与类真正有所区别的是前面讲述的四种“有且仅有”需要开始初始化场景中的第三种：  
当一个类在初始化时，要求其父类全部都已经初始化过了，但是**一个接口在初始化时，并不要求其父接口全部都完成了初始化，只有在真正使用到父接口的时候（如引用接口中定义的常量）才会初始化。**

## 加载 ##

“加载”（Loading）阶段是“类加载”（Class Loading）过程的一个阶段。在加载阶段，虚拟机需要完成以下三件事情：

1.  通过一个类的全限定名来获取定义此类的二进制字节流。
2.  将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3.  在Java堆中生成一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入口。

虚拟机规范的这三点要求实际上并不具体，因此虚拟机实现与具体应用的灵活度相当大。例如“通过一个类的全限定名来获取定义此类的二进制字节流”，并没有指明二进制字节流要从一个Class文件中获取，准确地说是根本没有指明要从哪里获取及怎样获取。  
例如：

1.  从ZIP包中读取，这很常见，最终成为日后JAR、EAR、WAR格式的基础。
2.  从网络中获取，这种场景最典型的应用就是Applet。
3.  运行时计算生成，这种场景使用得最多的就是动态代理技术，在java.lang.reflect.Proxy中，就是用了ProxyGenerator.generateProxyClass来为特定接口生成\*$Proxy的代理类的二进制字节流。
4.  由其他文件生成，典型场景：JSP应用。
5.  从数据库中读取，这种场景相对少见些，有些中间件服务器（如SAP  
    Netweaver）可以选择把程序安装到数据库中来完成程序代码在集群间的分发。

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

## 验证 ##

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

虚拟机如果不检查输入的字节流，对其完全信任的话，很可能会因为载入了有害的字节流而导致系统崩溃，所以验证是虚拟机对自身保护的一项重要工作。

尽管验证阶段是非常重要的，并且验证阶段的工作量在虚拟机的类加载子系统中占了很大一部分，但虚拟机规范对这个阶段的限制和指导显得非常笼统，仅仅说了一句如果验证到输入的字节流不符合Class文件的存储格式，就抛出一个java.lang.VerifyError异常或其子类异常，具体应当检查哪些方面，如何检查，何时检查，都没有强制要求或明确说明，

所以不同的虚拟机对类验证的实现可能会有所不同，但大致上都会完成下面四个阶段的检验过程：文件格式验证、元数据验证、字节码验证和符号引用验证。

## 准备 ##

准备阶段是**正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中进行分配。**

这个阶段中有两个容易产生混淆的概念需要强调一下，

1.  首先是这时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。
2.  其次是这里所说的初始值“通常情况”下是数据类型的零值。

假设一个类变量的定义为： `public static int value=123；` 那么变量value在准备阶段过后的初始值为0而不是123，因为这时候尚未开始执行任何Java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器＜clinit＞（）方法之中，所以把value赋值为123的动作将在初始化阶段才会被执行。

如果类字段的字段属性表中存在`ConstantValue`属性，那在准备阶段变量value就会被初始化为`ConstantValue`属性所指定的值，假设上面类变量value的定义变为： `public static fnal int value=123；` 编译时Javac将会为value生成ConstantValue属性，**在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为123**。

## 解析 ##

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。

1.  符号引用（Symbolic  
    References）：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。
2.  直接引用（Direct  
    References）：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机实现的内存布局相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在内存中存在。

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

## 初始化 ##

初始化阶段是类加载过程的最后一步，到了初始化阶段，才**真正开始执行类中定义的Java程序代码（或者说是字节码）。**

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

*  `＜clinit＞（）`方法是由编译器自动收集类中所有类变量的赋值动作和静态语句块（`static{}`块）中的语句合并产生的，编译器收集的顺序一定是先变量赋值，再静态语句块（无论两者在源文件中出现的顺序如何），因此在静态语句块中可以访问到类变量的初始值了。
 *  `＜clinit＞（）`方法与类的构造函数（或者说实例构造器`＜init＞（）`方法）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的`＜clinit＞（）`方法执行之前，父类的`＜clinit＞（）`方法已经执行完毕。

**因此在虚拟机中第一个被执行的`＜clinit＞（）`方法的类肯定是java.lang.Object**。 由于父类的`＜clinit＞（）`方法先执行，也就意味着**父类中定义的静态语句块要优先于子类的变量赋值操作。**

*  `＜clinit＞（）`方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成`＜clinit＞（）`方法。
 *  接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成`＜clinit＞（）`方法。
 *  但接口与类不同的是，执行接口的`＜clinit＞（）`方法不需要先执行父接口的`＜clinit＞（）`方法。
 *  只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也一样不会执行接口的`＜clinit＞（）`方法。

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNjU4NjEyMA_size_16_color_FFFFFF_t_70]: /images/20220310/beae1fddd2ba4e159b9b7e13208f0b6c.png