Java类的加载机制

一、类的生命周期

1、加载的生命周期

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

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

加载阶段，Java虚拟机规范中没有进行约束。但是初始化阶段，Java虚拟机规范中有严格的约束。（注：加载、验证、准备要在初始化之前开始）

下面5种情况必须立即对类进行初始化：

1）遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new 关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。

2）使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。

3）当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

4）当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。

5）当使用JDK 1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

注意：对于这5种会触发类进行初始化的场景，虚拟机规范中使用了一个强烈限定语：”有且只有“，这5种场景中的行为称为对一个类进行主动引用。除此之外，所有引用类的方式都不会触发初始化，称为被动引用。

2.被动使用类字段举例

(1)通过子类引用父类的静态字段，不会导致子类初始化。

定义一个类SuperClass：

public class SuperClass {

    static {
        System.out.println("SuperClass init!");
    }

    public static int value = 123;
}

定义SuperClass的一个子类：

public class ChildClass extends SuperClass {

    static {
        System.out.println("ChildClass init!");
    }

    public static int childvalue = 456;
}

测试1——通过子类获取父类的属性：

public class NotInitialization {

    public static void main(String[] args) {
        System.out.println(ChildClass.value);
    }
}

上述代码运行之后，只会输出”SuperClass init！“：

 测试1——通过子类获取自己的属性：

public class NotInitialization {

    public static void main(String[] args) {
        System.out.println(ChildClass.childvalue);
    }
}

打印结果：

对于静态字段，只有直接定义这个字段的类才会被初始化，因此通过其子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化。

(2)通过数组定义来引用类，不会触发此类的初始化

例如：

public class NotInitialization {

    public static void main(String[] args) {
        SuperClass[] sca=new SuperClass[10];
    }
}

运行之后发现没有输出”SuperClass init！“，说明并没有触发类com.example.mytestapplication.test.load.SuperClass的初始化阶段。但是这段代码里面触发了另外一个名为”[Lcom.example.mytestapplication.test.load.SuperClass“的类的初始化阶段，它是由虚拟机自动生成的、直接继承于java.lang.Object的子类，创建动作由字节码指令newarray出发。

这个类代表了com.example.mytestapplication.test.load.SuperClass的一维数组，数组中应由的属性和方法（用户可直接使用的只有被修饰为public的length属性和clone()方法）都实现在这个类里。

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

例如：

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类的常量池中，以后NotInitialization对常量ConstClass.HELLOWORLD的引用实际都被转化为NotInitialization类对自身常量池的引用了。也就是说，实际上NotInitialization的Class文件之中并没有ConstClass类的符号引用入口，这两个类在编译成Class之后就不存在任何联系了。

3.其他不会触发初始化的情况

（1）通过类名获取Class对象，不会触发类的初始化。如System.out.println(User.class);

（2）通过Class.forName加载指定类时，如果指定参数initialize为false时，也不会触发类初始化。

Class.forName有两个重载的方法：

其中只有一个参数的Class.forName方法默认initialize为true，即会触发类的初始化：

   public static Class<?> forName(String className)
                throws ClassNotFoundException {
        Class<?> caller = Reflection.getCallerClass();
        return forName(className, true, ClassLoader.getClassLoader(caller));
    }

有三个参数的Class.forName方法，initialize参数可以由外部传入：

   public static Class<?> forName(String name, boolean initialize,
                                   ClassLoader loader)

（3）通过ClassLoader默认的loadClass方法，也不会触发初始化动作。

4、接口的加载

接口的加载过程与类的加载过程稍有不同，针对接口需要做一些特殊说明：接口也有初始化过程，这点与类是一致的，上面的代码都是用静态语句块”static{}“来输出初始化信息的，而接口中不能使用”static{}“语句块，但编译器仍然会为接口生成”<clinit>()“类构造器，用于初始化接口中所定义的成员变量。接口与类真正有所区别的是上面提到的5种”有且仅有“需要开始初始化场景中的第3种：当一个类在初始化时，要求其父类全部都已经初始化过了，但是一个接口在初始化时，并不要求其父接口全部都完成了初始化，只有在真正使用到父接口的时候（如引用接口中定义的常量）才会初始化。

二、阶段详细分析

1、加载阶段

加载主要是将.class文件通过二进制字节流读入到JVM中。加载阶段，虚拟机需要完成以下三件事情：

（1）通过classloader在classpath中读取xxx.class文件，将其以二进制流的形式读入内存

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

（3）在内存中生成一个该类的java.lang.Class对象，这样便可以通过该对象访问方法区中的这些数据

class文件的加载方式：

• 从本地系统重直接加载
• 从zip、jar等归档文件中加载.class文件
• 从数据库中提取.class文件
• 将Java源文件动态编译为.class文件

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

2、链接阶段

当类被加载后，系统为之生成一个对应的Class对象，接着会进入链接阶段。类的链接阶段分为如下三个阶段：

• 验证：验证阶段用于检验被加载的类是否有正确的内部结构，并和其他类协调一致；
• 准备：准备阶段则负责为类的静态属性分配内存，并设置默认初始值
• 解析：将类的二进制数据中的符号引用替换成直接引用（符号引用是用一组符号描述所引用的目标；直接引用是指向目标的指针）

（1）验证

确保被加载的类的正确性

验证阶段主要是确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机的自身安全。

包括以下几个方面的验证：

文件格式验证：验证字节流是否符合Class文件格式的规范，如：是否以魔数0xCAFEBABE开头、主次版本号是否在当前虚拟机处理范围之内、常量池的常量中是否有不被支持的常量类型（检查常量tag标志）、指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量等等

元数据验证：对字节码的描述的信息进行了语义分析，以保证其描述的信息符合Java语言规范的要求；如：这个类是否有父类，是否实现了父类的抽象方法，是否重写了父类的final方法，是否继承了被final修饰的类等等。

字节码验证：通过数据流和控制流分析，确定程序语义是否是合法的、符合逻辑的，如：操作数栈的数据类型与指令代码序列能配合工作，保证方法中的类型转换有效等待。

符号引用验证：确保解析动作能正确执行；如：符号引用中通过字符串描述的全限定名是否能找到对应的类、在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段、符号引用中的类、字段、方法的访问性（private、protected、public、default）是否可被当前类访问。

符号引用验证的目的是确保解析动作能正常执行，如果无法通过符号引用验证，那么将会抛出一个java.lang.IncompatibleClassChangeError异常的子类，如java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等。

对于虚拟机的类加载机制来说，验证阶段是一个非常重要的、但不是一定必要（因为对程序运行期没有影响）的阶段。如果所运行的全部代码（包括自己编写的及第三方包中的代码）都已经被反复使用和验证过，那么在实施阶段就可以考虑使用-Xverify：none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

（2）准备

为类的静态变量分配内存，并将其赋默认值

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

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

public static int value = 123;

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

上面提到，在”通常情况“下初始值是零值，那相对的会有一些”特殊情况“：如果类字段的字段属性表中存在ConstantValue属性，那么在准备阶段变量value就会被初始化为ConstantValue属性所指定的值，假设上面类变量value的定义变为：

public static final int value=123;

编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为123。

小结：

• 对static修饰的静态变量进行内存分配、并赋默认值
• 对final static 修饰的静态字面值常量进行内存分配、直接赋初始值。
• 对final static修饰的静态非字面值常量进行内存分配、赋默认值

一句话：静态变量和静态非字面值常量赋默认值，静态字面值常量赋初始值

字面值常量和非字面值常量

public static final long id=IdGenerator.getIdWorker().nextId();//静态非字面值常量，需要初始化ClassInit类


public static final String str="abc";//静态字面值常量

（3）解析

将常量池中符号引用替换为直接引用（内存地址）的过程

符号引用：一组符号来描述目标，可以是任何字面量。

直接引用：直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄

假设一个类有一个静态变量，该静态变量是一个自定义的类型，那么经过解析后，该变量将是一个指针，指向该类在方法区的内存地址。

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄、调用点限定符这7类符号引用进行。

这7类符号引用解析分别对应于常量池的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_InterfaceMethodref_info、CONSTANT_MethodType_info、CONSTANT_MethodHandle_info、CONSTANT_InvokeDynamic_info 7中常量类型。

（4）初始化

为类的静态变量赋初始值

静态变量赋初始值的两种方式：

• 定义静态变量时指定初始值

private static String x="123";

• 静态代码块里为静态变量赋值

private static String x;

static{ 
	x="123"; 
} 

在编译生成class文件时，编译器会产生两个方法加于class文件中：

• clinit：类的初始化方法
• init：实例的初始化方法

初始化阶段是执行类构造器<clinit>()方法的过程。<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态代码块（static{} 块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块中可以赋值，但是不能访问。如下：

 <clinit>()方法与类的构造函数（或者说实例构造器<init>()方法）不同，它不需要显示地调用父类构造器，虚拟机会保证在子类的<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕。因此在虚拟机中第一个被执行<clinit>()方法的类肯定是java.lang.Object。由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。

示例：

public class Parent {

    public static int A=1;

    static{
        A=2;
    }

}

public class Sub extends Parent{

    public static int B=A;
}

public class Test {
    public static void main(String[] args) {
        System.out.println(Sub.B);
    }
}

如在上述代码中，打印字段B的结果是2而不是1。

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

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

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

小结

1.<clinit>()  类的初始化方法

clinit是类的构造器，主要作用是在类加载的过程中的初始化阶段进行执行，执行内容包括：静态变量初始化（赋初始值）和静态代码块的执行

• 如果类中没有静态变量或静态代码块，那么clinit方法将不会被生成
• 类在执行clinit方法时，必须先执行父类的clinit方法。而接口在执行clinit方法时，不会执行父接口的clinit方法。
• clinit方法只执行一次
• 静态变量的赋初始值和静态代码块的执行顺序由源文件中出现的顺序决定

2、<init>()  实例的初始化方法

init是实例的构造器，主要作用是在类实例化的过程中执行，执行内容包括：成员变量初始化和构造代码块的执行。

• 如果类中没有成员变量和构造代码块，那么init方法将不会被生成
• 在执行init方法时，必须先执行父类的init方法
• init方法每实例化一次就会执行一次
• init方法先为实例变量分配内存空间，再执行默认值，然后进行赋初值和构造代码块的执行（实例变量的赋初值和构造代码块的执行顺序由源文件中出现的顺序决定）

三、类加载器

虚拟机设计团队把类加载阶段中的”通过一个类的全限定名来获取描述此类的二进制字节流“这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为”类加载器“。

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。通俗地说：比较两个类是否”相等“，只有在这两个类是同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

这里所说的”相等“，包括代表类的Class对象的equals()方法、isAsignableFrom()方法、isInstance()方法的返回结果，也包括使用instanceof关键字做对象所属关系判定等情况。

1、双亲委派模型

从Java虚拟机的角度来讲，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；另一种就是所有其他的类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。

从Java开发人员的角度看，类加载器可以划分为：启动类加载器（BootstrapClassLoader）、扩展类加载器（ExtensionClassLoader）、应用程序类加载器（AppClassLoader）、自定义加载器（CustomClassLoader）。

（1）启动类加载器

负责加载$JAVA_HOME jre/lib/rt.jar里所有的class或者-Xbootclasspath参数所指定的路径中，并且是虚拟机识别的（仅按照文件名识别，如rt.jar,名字不符合的类库即使放在lib目录中也不会被加载）。由C++识别，不是ClassLoader子类

（2）扩展类加载器

负责加载java平台中扩展功能的一些jar包，包括$JAVA_HOME中jre/lib/*.jar  或者 -Djava.ext.dirs指定目录下的jar包

（3）应用程序类加载器

负责加载classpath中指定的jar包或者 -Djava.class.path所指定目录下的类和jar包。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器

（4）自定义加载器

通过java.lang.ClassLoader的子类自定义加载class，属于应用程序根据自身需要自定义的ClassLoader。如tomcat、jboss都会根据j2ee规范自行实现ClassLoader。

 双亲委派模型（Parents Delegation Model）要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承的关系来实现，而是都使用组合关系来复用父加载器的代码。

双亲委派模型的工作过程：

如果一个类加载器收到了类的加载请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子类加载器才会尝试自己去加载。

双亲委派模型的好处：

• 避免类的重复加载：在JVM中，每个类都由一个唯一的全限定名和一个对应的类加载器确定，类加载器根据全限定名和类路径来确定类的位置。因此一个JVM实例中，如果有两个类加载器分别加载了同一个类，JVM会认为这两个类是不同的，从而导致类型转换异常等问题。通过双亲委派机制，类加载器在加载类之前会先委托给自己的父类加载器去加载，从而保证一个类在JVM中只会有一份，并且由其父类加载器所加载。
• 保护程序安全，防止核心API被随意篡改：Java核心类库（java.lang 包下的类）都是由启动类加载器加载的，其他的类都是由其他类加载器加载的。这样，我们可以保证Java核心类库的安全性，因为不同的应用程序无法改变这些类的实现。

Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object,它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，Java类型体系中最基本的行为也就无法保证，应用程序也将会变得一片混乱。

双亲委派模型对于保证Java程序的稳定运作很重要，但它的实现却非常简单，实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法之中。逻辑清晰易懂：先检查是否已经被加载过，若没有加载则调用父加载器的loadClass()方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。

protected synchronized Class<?> loadClass(String name, boolean resolve) throws
ClassNotFoundException
   {
       //首先，检查请求的类是否已经被加载过了
       Class c = findLoadedClass(name);
       if (c == null) {
           try {
           if (parent != null) {
               c = parent.loadClass(name, false);
           } else {
               c = findBootstrapClassOrNull(name);
           }
           } catch (ClassNotFoundException e) {
               //如果父类加载器抛出ClassNotFoundException
               //说明父类加载器无法完成加载请求
           }
           if (c == null) {
               //在父类加载器无法加载的时候
               //再调用本身的findClass方法来进行类加载
               c = findClass(name);
           }
       }
       if (resolve) {
           resolveClass(c);
       }
       return c;
   }

四、问题

1、为什么Java中静态方法不能调用非静态方法和变量？

因为调用静态方法时，是没有传入this指针的，所以在静态方法中调用非静态方法，非静态方法的第一个参数是隐含的，静态方法没有这个隐含参数，所以不能调用。

例如：
 

class Hello{

    String name;

    
    void hello(){
        System.out.println('hello'+name);

    }

    
    static void greeting(){
        System.out.println('hello'+name);

    }
}

 在编译器看来，上面的代码就是数据结构+函数调用：

class Hello {
    String name;
}

void Hello::hello(Hello this) {
    System.out.println('hello, ' + this.name);
}

void Hello::greeting

非静态方法第一个隐含参数 Hello this是编译器自动加上的，静态方法没有这个隐含参数，所以hello()可以编译通过，但是greeting()不行，因为name undefined。