Java类加载机制学习笔记

Java类加载

​ Java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这个过程被称作虚拟机的类加载机制。

​ 类的加载的最终产品是位于堆区中的 Class对象， Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口。

类的加载时机

​ 一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期将会经历加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）七个阶段，其中验证、准备、解析三个部分统称为连接（Linking）。

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

会触发类初始化的场景

​ 《Java虚拟机规范》严格规定了有且只有六种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

1. 遇到new、getstatic、putstatic或invokestatic这四条字节码指令（注意，newarray指令触发的只是数组类型本身的初始化，而不会导致其相关类型的初始化，比如，new String[]只会直接触发String[]类的初始化，也就是触发对类[Ljava.lang.String的初始化，而直接不会触发String类的初始化）时，如果类没有进行过初始化，则需要先对其进行初始化。生成这四条指令的最常见的Java代码场景是：

• 使用new关键字实例化对象的时候；
• 读取或设置一个类的静态字段（被final修饰，已在编译器把结果放入常量池的静态字段除外）的时候；
• 调用一个类的静态方法的时候。

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

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

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

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

6）当一个接口定义JDK8新加入的默认方法（被default关键字修饰的接口方法），若这个接口的实现类初始化，该接口要在其之前被初始化。

几种不会触发类初始化的情况：

1.通过子类引用父类的静态字段，只会引发父类初始化而不会引发子类初始化。

2.创建该类的数组不会触发该类的初始化。

3.引用类的常量不会触发类的初始化。

4.初始一个类会要求其父类全部初始化了，但是初始化一个接口并不要求其父接口全部完成了初始化。

类加载的过程

1.加载

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

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

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

1.从ZIP压缩包中读取，这很常见，最终成为日后JAR、EAR、WAR格式的基础。
2.从网络中获取，这种场景最典型的应用就是Web Applet。
3.运行时计算生成，这种场景使用得最多的就是动态代理技术，在java.lang.reflect.Proxy中，就是用了ProxyGenerator.generateProxyClass()来为特定接口生成形式为“*$Proxy”的代理类的二进制字节流。
4.由其他文件生成，典型场景是JSP应用，由JSP文件生成对应的Class文件。
5.从数据库中读取，这种场景相对少见些，例如有些中间件服务器（如SAP Netweaver）可以选择
把程序安装到数据库中来完成程序代码在集群间的分发。
6.可以从加密文件中获取，这是典型的防Class文件被反编译的保护措施，通过加载时解密Class文
件来保障程序运行逻辑不被窥探。

​ 相对于类加载过程的其他阶段，非数组类型的加载阶段（准确地说，是加载阶段中获取类的二进制字节流的动作）是开发人员可控性最强的阶段。加载阶段既可以使用Java虚拟机里内置的引导类加载器来完成，也可以由用户自定义的类加载器去完成，开发人员通过定义自己的类加载器去控制字节流的获取方式（重写一个类加载器的findClass()或loadClass()方法），实现根据自己的想法来赋予应用程序获取运行代码的动态性。

2.验证

​ 验证是连接阶段的第一步，这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全。验证阶段大致会完成4个阶段的检验动作：

• 文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以 0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
• 元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了 java.lang.Object之外。
• 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
• 符号引用验证：确保解析动作能正确执行。

3.准备

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

1. 这时候进行内存分配的仅包括类变量（ Class Variables ，即静态变量，被 static 关键字修饰的变量，只与类相关，因此被称为类变量），而不包括实例变量。实例变量会在对象实例化时随着对象一块分配在 Java 堆中。

2. 这里所设置的初始值"通常情况"下是数据类型默认的零值（如 0、0L、null、false 等），比如我们定义了public static int value=111 ，那么 value 变量在准备阶段的初始值就是 0 而不是 111（初始化阶段才会赋值）。特殊情况：比如给 value 变量加上了 final 关键字public static final int value=111 ，那么准备阶段 value 的值就被赋值为 111。

   基本数据类型的零值：

4.解析

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

​ 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符这7类符号引用进行，分别对应于常量池的CONSTANT_Class_info、CON-STANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info、CONSTANT_MethodType_info、CONSTANT_MethodHandle_info、CONSTANT_Dyna-mic_info和CONSTANT_InvokeDynamic_info 8种常量类型。

符号引用和直接引用

符号引用就是一组符号来描述目标，可以是任何字面量。例如：Java.Util.List。

直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。在程序实际运行时，只有符号引用是不够的。在程序执行方法时，系统需要明确知道这个方法所在的位置。Java 虚拟机为每个类都准备了一张方法表来存放类中所有的方法。例如：List类的java.lang.Class对象的地址的指针。

5.初始化

​ 初始化阶段是执行初始化方法 <clinit> ()方法的过程，是类加载的最后一步，这一步 JVM 才开始真正执行类中定义的 Java 程序代码(字节码)。 <clinit> ()方法是编译之后自动生成的。

​ 对于<clinit> () 方法的调用，虚拟机会自己确保其在多线程环境中的安全性。因为 <clinit> () 方法是带锁线程安全，所以在多线程环境下进行类初始化的话可能会引起多个进程阻塞，并且这种阻塞很难被发现。

类加载器

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

类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远超类加载阶段。对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。

这句话可以表达得更通俗一些：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

​ JVM 中内置了三个重要的 ClassLoader，除了 BootstrapClassLoader 其他类加载器均由 Java 实现（启动类加载器使用C++语言实现)且全部继承自java.lang.ClassLoader：

• 启动类加载器（Bootstrap Class Loader）：前面已经介绍过，这个类加载器负责加载存放在<JAVA_HOME>\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的类库加载到虚拟机的内存中。启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器去处理，那直接使用null代替即可。
• 扩展类加载器（Extension Class Loader）：这个类加载器是在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现的。它负责加载<JAVA_HOME>\lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中所有的类库。由于扩展类加载器是由Java代码实现的，开发者可以直接在程序中使用扩展类加载器来加载Class文件。
• 应用程序类加载器（Application Class Loader）：这个类加载器由sun.misc.Launcher$AppClassLoader来实现。它负责加载用户类路径（ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

双亲委派模型

双亲委派模型的工作流程分为两个部分：

（1）自底向上检查类是否已被加载

如果一个类加载器收到了类加载的请求，它首先查看自己是否已经加载过这个类，如果已经加载过，则直接返回，否则，不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上。(父类委托)

（2）自顶向下尝试加载类

若所有的父类都没有加载过该类，则的类加载请求最终都应该被传递到顶层的启动类加载器中，此时开始自顶向下尝试加载该类（实际的加载过程）。加载过程中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类，一次向下。

双亲委派机制的代码分析：

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);//如果父类加载器不为空，调用父加载器的loadClass方法
            }else{
                c = findBootstrapClassOrNull(name);//父加载器为空，则使用启动类加载器作为父加载器
            }catch(ClassNotFountException e){
                //如果父加载器抛出ClassNotFound，说明父加载器无法完成加载请求
            }
            if(c==null){
                //父加载器无法完成加载，此时再调用自身的findClass方法进行类加载
                c = findClass(name);
            }
        }
    }
    if(resolve){
        resolveClass(c);
    }
    return c;
}

双亲委派模型的优点：

1.防止系统内出现多份相同的字节码

​ 例如：两个类A和B在使用System.out.printLn静态方法时，实际需要的是System的静态Class，并且只需要一份，如果不用委托，而是自己加载自己的，那么类A打印时需要加载一份System字节码，类B打印时也需加载一份System字节码，那么内存中则保存了两份同样的System字节码。若采用双亲委派，类A加载System类时需要从BootStrapClassLoader加载，当B类调用时则逐层向上检查该类是否已经加载，最终发现BootStrapClassLoader已经加载过，则可以直接返回同一个System，而不需要再次加载，这样内存中就只存在一个System字节码。

2.保证系统安全稳定运行

​ 例如：类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都能够保证是同一个类。如果没有使用双亲委派模型，都由各个类加载器自行去加载的话，如果用户自己也编写了一个名为java.lang.Object的类，并放在程序的ClassPath中，那系统中就会出现多个不同的Object类，Java类型体系中最基础的行为也就无从保证，应用程序将会变得一片混乱。

双亲委派机制是可以被破坏的!