JVM系列之类加载

Posted 2020-11-25 yrjns

什么是类的加载

类加载是指将源代码编译后的.class加载到内存中初始化待程序使用的过程，类加载的最终结果就是将.class字节码加载到JVM中生成一个java.lang.Class对象，提供给程序使用的访问入口。

类加载的过程

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

 

 其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持 Java 语言的运行时绑定（也称为动态绑定或晚期绑定）

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

静态绑定：即前期绑定。在程序执行前方法已经被绑定，此时由编译器或其它连接程序实现。针对 Java，简单的可以理解为程序编译期的绑定。Java 当中的方法只有 final，static，private 和构造方法是前期绑定的。
动态绑定：即晚期绑定，也叫运行时绑定。在运行时根据具体对象的类型进行绑定。在 Java 中，几乎所有的方法都是后期绑定的。

 

加载

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

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

其中第一步获取二进制字节流的阶段是可控性最强的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器来完成加载。

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

类加载器分成两类：启动类加载器（bootstrap）和用户自定义的类加载器（user-defined），区别在于启动类加载器是JVM内部实现的，而用户自定义的类加载器是继承自ClassLoader的java实现。 
站在 Java 开发人员的角度来看，类加载器可以大致划分为以下三类：

• 启动类加载器：Bootstrap ClassLoader，跟上面相同。它负责加载存放在JDKjrelib(JDK 代表 JDK 的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如 rt.jar，所有的java.*开头的类均被 Bootstrap ClassLoader 加载）。启动类加载器是无法被 Java 程序直接引用的。
• 扩展类加载器：Extension ClassLoader，该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载JDKjrelibext目录中，或者由 java.ext.dirs 系统变量指定的路径中的所有类库（如javax.*开头的类），开发者可以直接使用扩展类加载器。
• 应用程序类加载器：Application ClassLoader，该类加载器由 sun.misc.Launcher$AppClassLoader 来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。可通过class.getClassLoader()或ClassLoader.getSystemClassLoaser()获取应用程序默认的类加载器。
• 自定义类加载器：是我们自己自定义的类加载器，同样继承自ClassLoader类，父类加载器是Application ClassLoader,通过自定义加载器我们能够实现在执行非置信代码之前，自动验证数字签名；动态地创建符合用户特定需要的定制化构建类；从特定的场所取得 java class，例如数据库中和网络中。

Java类加载器有两个比较重要的特征：层次组织结构和代理模式。层次组织结构指的是每个类加载器都有一个父类加载器，通过getParent()方法可以获取到。类加载器通过这种父亲-后代的方式组织在一起，形成树状层次结构。代理模式则指的是一个类加载器既可以自己完成Java类的定义工作，也可以代理给其它的类加载器来完成。由于代理模式的存在，启动一个类的加载过程的类加载器和最终定义这个类的类加载器可能并不是一个。前者称为初始类加载器，而后者称为定义类加载器。两者的关联在于：一个Java类的定义类加载器是该类所导入的其它Java类的初始类加载器。比如类A通过import导入了类 B，那么由类A的定义类加载器负责启动类B的加载过程。

一般的类加载器在尝试自己去加载某个Java类之前，会首先代理给其父类加载器。当父类加载器找不到的时候，才会尝试自己加载。这个逻辑是封装在java.lang.ClassLoader类的loadClass()方法中的。一般来说，父类优先的策略就足够好了。在某些情况下，可能需要采取相反的策略，即先尝试自己加载，找不到的时候再代理给父类加载器。这种机制不是JVM强制实现的，而是通过java代码的逻辑实现，所以我们可以覆盖java.lang.ClassLoader类的loadClass()方法来自定义自己类加载逻辑。

 

什么时候导致类加载

类的加载是通过类加载器（Classloader）完成的，它既可以是饿汉式[eagerly load]（只要有其它类引用了它就加载）加载类，也可以是懒加载[lazy load]（等到类初始化发生的时候才加载）。不过我相信这跟不同的JVM实现有关，然而他又是受JLS保证的（当有静态初始化需求的时候才被加载）。

除了通过jvm类加载器加载类，还可以通过Class.forName()来显示的加载一个类。 

Class.forName()和ClassLoader.loadClass()区别

• Class.forName()：将类的.class文件加载到jvm中之外，还会对类进行解释，执行类的初始化过程。
• ClassLoader.loadClass()：只干一件事情，就是将.class文件加载到jvm中，不会执行static中的内容,只有在newInstance才会去执行static块。
• Class.forName(name, initialize, loader)带参函数也可控制是否加载static块。并且只有调用了newInstance()方法采用调用构造函数，创建类的对象 。

 

Java类的链接

在链接之前，这个类必须被成功加载。类的链接包括验证、准备和解析等几个步骤

验证：确保被加载的类的正确性

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

文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。 
元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了java.lang.Object之外。 
字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。 
符号引用验证：确保解析动作能正确执行。 
验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

类的准备

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

• 这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在 Java 堆中。
• 这里所设置的初始值通常情况下是数据类型默认的零值（如 0、0L、null、false 等），而不是被在 Java 代码中被显式地赋予的值。

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

public static int value = 3;

这句话在准备阶段只是将value初始化为int的默认值0,而不是3,因为这时候尚未开始执行任何 Java 方法，而把 value 赋值为 3 的 putstatic 指令是在程序编译后，存放于类构造器 <clinit>（）方法之中的(关于<clinit>（）方法在下面类初始化时有说明)，所以把 value 赋值为 3 的动作将在初始化阶段才会执行。

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

public static final int value = 3；

编译时 Javac 将会为 value 生成 ConstantValue 属性，在准备阶段虚拟机就会根据 ConstantValue 的设置将 value 赋值为 3。回忆上一篇博文中对象被动引用的第 2 个例子，便是这种情况。我们可以理解为 static final 常量在编译期就将其结果放入了调用它的类的常量池中。

类的初始化

什么时候初始化

Java 虚拟机规范为类的初始化时机做了严格定义：”initialize on first active use”–” 在首次主动使用时初始化” 
以下情况一个类被初始化：

• 实例通过使用new()关键字创建或者使用class.forName()反射，但它有可能导致ClassNotFoundException。
• 类的静态方法被调用
• 类的静态域被赋值
• 静态域被访问，而且它不是常量,即不是static final 修饰的字段
• 在顶层类中执行assert语句

反射同样可以使类初始化，比如java.lang.reflect包下面的某些方法，JLS严格的说明：一个类不会被任何除以上之外的原因初始化。

 

类是怎么被初始化的

初始化是类加载过程的最后一步，到了此阶段，才真正开始执行类中定义的 Java 程序代码。在准备阶段，类变量已经被赋过一次系统要求的初始值，而在初始化阶段，则是根据程序员通过程序指定的主观计划去初始化类变量和其他资源，或者可以从另一个角度来表达：初始化阶段是执行类构造器<clinit>（）方法的过程。

初始化阶段主要执行类构造器<clinit>（）方法，<clinit>（）方法是由编译器自动收集类中所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句中可以赋值，但是不能访问。另外需要注意以下几个比较重要的地方:

• <clinit>（）方法与实例构造器<init>()方法不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的()方法执行之前，父类的<clinit>（）方法已经执行完毕。因此，在虚拟机中第一个被执行的()方法的类肯定是java.lang.Object。

• <clinit>（）是在类初始化时候执行的，所以当一个类实例化是肯定要保证这个类已经被正确的加载(包括类加载、连接、初始化),所以<clinit>（）肯定先于实例构造器<init>()。

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

• 接口中不能使用静态语句块，但仍然有类变量（final static修饰,且非ConstValue 属性常量）初始化的赋值操作，因此接口与类一样会生成()方法。但是接口鱼类不同的是：执行接口的()方法不需要先执行父接口的<clinit>（）方法，只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>（）方法。只有当接口的静态变量被使用是才会被加载初始化。所以可以基于这种机制来实现一种单例模式的写法：

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

public class Singleton {
private static Singleton instance = new Singleton();
private Singleton (){}
public static Singleton getInstance() {
return instance;
}
}

 

类初始化总结：

• 类初始化过程就是在类的静态变量已经被准备阶段赋予零值之后重新赋值或者初始化过程,即<clinit>()方法的执行过程。
• <clinit>()是有编译器编译代码时按代码编写顺序收集类的静态变量赋值和静态代码块的集合
• <clinit>()在类或者接口的首次访问时初始(包括类Class.forName、new实例、反射newInstance()、静态变量的访问或赋值、静态方法被访问)时执行。
• 子类的<clinit>()晚于父类的<clinit>(),即执行子类的<clinit>()会触发父类的<clinit>()执行
• 接口和类一样也可以有静态变量(接口中字段不修饰时默认是static)，但是不能有静态代码块，所以也会编译器初始化接口时也会生成<clinit>()方法。与类不同的是接口的<clinit>()执行不会触发父类接口的<clinit>()执行，接口的实现类也不会触发接口的<clinit>()。
• <clinit>()执行是多线程安全的

注意：如果即同时被 final 和 static 修饰的基础类型变量，那么在准备阶段变量 value 就会被初始化为 ConstValue 属性所指定的值，在初始化阶段就不会再次初始化，即不会在 <clinit>（）中再次赋值。而如果是final static 修饰的引用类型就会生成<clinit>（）并在初始化阶段执行。

 

 

原文 ：  http://blog.leanote.com/post/zhangyue/JVM系列之类加载