类的生命周期

类加载过程

类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。

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

加载

在加载阶段，虚拟机需要完成以下三件事情：

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

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

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

二进制字节流不一定要从一个Class文件中获取，还可以通过以下几种方式获取：

  • 从ZIP包读取，成为JAR、EAR、WAR格式的基础。
  • 从网络中获取，最典型的应用是Applet。
  • 运行时计算生成，例如动态代理技术，在java.lang.reflect.Proxy中使用ProxyGenerator.generateProxyClass来为特定接口生成代理类的二进制字节流。
  • 由其他文件生成，例如由JSP文件生成对应的Class类。

验证

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

  • 文件格式验证：验证字节流是否符合Class文件格式的规范。
  • 元数据验证：对类的元数据信息进行语义校验，保证不存在不符合Java语言规范的元数据信息。（例如：这个类是否有父类）。
  • 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的，保证被校验类的方法在运行时不会做出危害虚拟机安全的事件。
  • 符号引用验证：确保解析动作能正确执行。

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

准备

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

注意：

  • 这时候进行内存分配的仅包括类变量（被static修饰的变量），实例变量将会在对象实例化时（实例化不是类加载的一个过程）随着对象一起分配在Java堆中。
  • 初始值通常情况下是数据类型的零值，但如果类字段同时被final和static修饰（即为常量），那么在准备阶段就会被初始化为所指定的值。

解析

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

符号引用：符号引用以一组符号来描述所引用的目标，可以是任何形式的字面量，与虚拟机实现的内存布局无关，引用的目标不一定已经加载到内存中。

直接引用：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的，引用的目标必定已经在内存中存在。

更通俗的解释：符号引用就是字符串，这个字符串包含足够的信息，以供实际使用时可以找到相应的位置。比如说某个方法的符号引用如：java/io/PrintStream.println:(Ljava/lang/String;)V。里面有类的信息，方法名，方法参数等信息。当第一次运行时，要根据字符串的内容，到该类的方法表中搜索这个方法。运行一次之后，符号引用会被替换为直接引用，下次就不用搜索了。直接引用就是偏移量，通过偏移量虚拟机可以直接在该类的内存区域中找到方法字节码的起始位置。 —– 来自知乎 https://www.zhihu.com/question/30300585

其中解析过程在某些情况下可以在初始化阶段之后再开始，这是为了支持Java的动态绑定。

动态绑定是指在执行期间（非编译期）判断所引用对象的实际类型，根据其实际的类型调用其相应的方法。 程序运行过程中，把函数（或过程）调用与响应调用所需要的代码相结合的过程称为动态绑定。

初始化

初始化阶段才真正开始执行类中定义的Java程序代码。初始化阶段即虚拟机执行类构造器<clinit>()方法的过程。

  • <clinit>()方法是由编译器自动收集类中所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序由语句在源文件中出现的顺序决定。特别注意的是，静态语句块只能访问到定义在它之前的类变量，定义在它之后的类变量只能赋值，不能访问。
  • 与类的构造函数（或者说实例构造器<init>()）不同，不需要显式的调用父类的构造器。虚拟机会自动保证在子类的<clinit>()方法运行之前，父类的<clinit>()方法已经执行结束。因此虚拟机中第一个执行<clinit>()方法的类肯定为java.lang.Object。
  • 由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块的执行要优先于子类。
  • <clinit>()方法对于类或接口不是必须的，如果一个类中不包含静态语句块，也没有对类变量的赋值操作，编译器可以不为该类生成<clinit>()方法。
  • 接口中不可以使用静态语句块，但仍然有类变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法。但接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。
  • 虚拟机会保证一个类的<clinit>()方法在多线程环境下被正确的加锁和同步，如果多个线程同时初始化一个类，只会有一个线程执行这个类的<clinit>()方法，其它线程都会阻塞等待，直到活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时的操作，就可能造成多个线程阻塞，在实际过程中此种阻塞很隐蔽。

在准备阶段，类变量已经赋过一次系统要求的初始值，而在初始化阶段，根据程序员通过程序制定的主观计划去初始化类变量和其它资源。在Java中对类变量进行初始值设定有两种方式：

  • 声明类变量时指定初始值。
  • 使用静态代码块为类变量指定初始值。

只有当对类主动引用的时候才会导致类的初始化，主动引用有以下几种：

  • 创建类的实例，也就是new的方式。
  • 访问某个类或接口的静态变量，或者对该静态变量赋值。
  • 调用类的静态方法。
  • 使用java.lang.reflect包的方法对类进行反射调用的时候。
  • 当初始化一个类的时候，如果其父类还没有进行过初始化，则需要先触发其父类的初始化。
  • 当虚拟机启动时，用户需要指定一个要执行的主类（包含 main() 方法的那个类），虚拟机会先初始化这个主类。

除主动引用外的所有引用类的方式都不会触发初始化，被称为被动引用，常见有以下几个例子:

  • 通过子类引用父类的静态字段，不会导致子类初始化。
  • 通过数组定义来引用类，不会触发此类的初始化。该过程会对数组类进行初始化，数组类是一个由虚拟机自动生成的、直接继承自Object的子类，其中包含了数组的属性和方法。

类加载器

两个类相等需要类本身相等，并且使用同一个类加载器进行加载。这是因为每一个类加载器都拥有一个独立的类名称空间。

从 Java 虚拟机的角度来讲，只存在以下两种不同的类加载器：

  • 启动类加载器（Bootstrap ClassLoader），这个类加载器用C++实现，是虚拟机自身的一部分。
  • 所有其他类的加载器，这些类由Java实现，独立于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader，这些类加载器需要由启动类加载器加载到内存中之后才能去加载其他的类。

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

  • 启动类加载器（Bootstrap ClassLoader）：此类加载器负责将存放在 <JRE_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给启动类加载器，直接使用null代替即可。
  • 扩展类加载器（Extension ClassLoader）：此类加载器是由ExtClassLoader（sun.misc.Launcher$ExtClassLoader）实现的。它负责将<JAVA_HOME>/lib/ext或者被java.ext.dir系统变量所指定路径中的所有类库加载到内存中，开发者可以直接使用扩展类加载器。
  • 应用程序类加载器（Application ClassLoader）：此类加载器是由AppClassLoader（sun.misc.Launcher$AppClassLoader）实现的。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，因此一般称为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

双亲委派模型

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

该模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。这里类加载器之间的父子关系一般通过组合关系来实现，而不是通过继承的关系实现。

具体过程

  1. 当AppClassLoader加载一个class时，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器ExtClassLoader去完成。
  2. 当ExtClassLoader加载一个class时，它首先也不会自己去尝试加载这个类，而是把类加载请求委派给BootStrapClassLoader去完成。
  3. 如果BootStrapClassLoader加载失败（例如在<JRE_HOME>\lib里未查找到该class），会使用ExtClassLoader来尝试加载。
  4. 若ExtClassLoader也加载失败，则会使用AppClassLoader来加载，如果AppClassLoader也加载失败，则会报出异常ClassNotFoundException。

优点

使得Java类随着它的类加载器一起具有一种带有优先级的层次关系，从而使得基础类得到统一。

例如java.lang.Object存放在rt.jar中，如果编写另外一个java.lang.Object的类并放到ClassPath中，程序可以编译通过。由于双亲委派模型的存在，所以在rt.jar中的Object比在ClassPath中的Object优先级更高，这是因为rt.jar中的Object使用的是启动类加载器，而ClassPath中的Object使用的是应用程序类加载器。rt.jar中的Object优先级更高，那么程序中所有的Object都是这个Object。

自定义类加载器

通常情况下，我们都是直接使用系统类加载器，但是有的时候，我们也需要自定义类加载器。

自定义类加载器一般都是继承自ClassLoader类，而java.lang.ClassLoader的loadClass()实现了双亲委派模型的逻辑，因此自定义类加载器最好不要去重写它。

参考资料

  • 周志明. 深入理解 Java 虚拟机 [M]. 机械工业出版社, 2011.