02、JVM 实战 - 类加载子系统

1、作用

1、 负责从文件系统或者网络中加载Class文件，Class文件开头有特定文件标识；
2、 Classloader只负责class文件的加载，是否可以运行，由ExecutionEngine执行引擎决定；
3、 加载的类信息存放于一块称为方法区的内存空间除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是class文件中常量池部分的内存映射)；

2、类的加载过程

（面试常问）类装载的执行过程：（5步）

• 加载：根据查找路径找到相应的 class 文件然后导入
• 验证：检查加载的 class 文件的正确性
• 准备：给类中的静态变量分配内存空间
• 解析：虚拟机将常量池中的符号引用替换成直接引用的过程。符号引用就理解为一个标识，而在直接引用直接指向内存中的地址
• 初始化：对静态变量和静态代码块执行初始化工作

2.1、加载

加载刚好是加载过程的一个阶段，二者意思不能混淆，具体步骤：

1、 通过一个类的全限定名获取定义此类的二进制字节流；

• 本地系统获取
• 网络获取，Web Applet
• zip压缩包获取，jar，war
• 运行时计算生成，动态代理 2、 将这个字节流所代表的的静态存储结果转化为方法区的运行时数据结构；
  3、 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据访问入口；

2.2、链接

1、验证

目的： 确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全

四种验证：

1、 文件格式验证：；

• 开头：CA FE BA BE(魔数，Java虚拟机识别)
• 主次版本号
• 常量池的常量中是否有不被支持的常量类型
• 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量

2、 元数据验证：；

• 对字节码描述的信息进行语义分析，保证描述符合Java规范

• 类是否有父类，除了Object之外，所有的类都应该有父类

• 类的父类是否继承了不允许被继承的类（被final修饰的类）

• 如果这个类不是 抽象类，是否实现了其父类或接口中要求实现的所有方法

• 类的字段，方法是否与父类的产生矛盾。例如方法参数都一样，返回值不同 3、 字节码验证：；

• 通过数据流分析和控制流分析，确定程序语义是合法的，符合逻辑的

• 对类的方法体，进行校验分析，保证在运行时不会做出危害虚拟机的行为

• 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，不会出现类似于在操作数栈放了一个int类型的数据，使用时却按照long类型加载到本地变量表中的情况。

• 保障任何跳转指令都不会跳转到方法体之外的字节码指令上 4、 符号引用验证：；

• 通过字符串描述的全限定名是否能找到对应的类

• 符号引用中的类、字段、方法的可访问性是否可被当前类访问

2、准备

• 为类变量（静态变量）分配内存，并且设置该类变量的初始值，即零值

• 不包含用final修饰的static，因为final在编译的时候就会分配了，准备阶段会显示初始化
• 不会为实例变量分配初始化，类变量会分配在方法区中，实例变量会随着对象一起分配到Java堆中

3、解析

• 将常量池内的符号引用转换为直接引用的过程
• 事实上，解析操作往往会伴随着JVM在执行完初始化之后再执行
• 符号引用就是一组符号来描述引用的目标。符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中
• 直接引用就是直接指向目标的指针，相对偏移量或一个间接定位到目标的句柄
• 解析动作主要针对类，或接口，字段，类方法，接口方法，方法类型等。对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info

2.3、初始化

• 初始化阶段是执行类构造器方法<clinit>()的过程
• 此方法不需要定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来，如果没有类变量和静态代码块，也不会有clinit
• 构造器方法中指令按照语句在源文中出现的顺序执行
• <clinit>()不同于类的构造器（关联：构造器是虚拟机视角下的<init>()）
• 若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕

• 虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁

2.4、补充说明

加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的。解析阶段不一定，在某些情况下可以在初始化阶段之后再开始，为了支持Java语言的运行时绑定特性（也称为动态绑定或晚期绑定）

ava虚拟机规范严格规定了，有且只有六种情况，必须立即对类进行初始化：

1、 遇到new、getstatic、putstatic或invokestatic这四条字节码指令时；

• 使用new关键字实例化对象
• 读取或设置一个类型的静态字段（final修饰已在编译期将结果放入常量池的静态字段除外）
• 调用一个类型的静态方法的时候 2、 对类型进行反射调用，如果类型没有经过初始化，则需要触发初始化；
  3、 初始化类的时候，发现父类没有初始化，则先触发父类初始化；
  4、 虚拟机启动时，用户需要指定一个要执行的主类（包含main方法的那个类），虚拟机会初始化这个主类；
  5、 只用JDK7中新加入的动态语言支持，如果一个java.lang.invoke.MethodHandler实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法对应的类没有进行初始化，则先触发其初始化；
  6、 当一个接口中定了JDK8新加入的默认方法时，如果这个接口的实现类发生了初始化，要先将接口进行初始化；

除了以上几种情况，其他使用类的方式被看做是对类的被动使用，都不会导致类的初始化

（面试常问）简述java类加载机制？

VM把描述类的数据从Class文件加载到内存（方法区），并对数据进行校验，解析和初始化，最终形成可以被JVM直接使用的java类型。

3、类加载器ClassLoader

（面试常问）描述一下JVM加载Class文件的原理机制？

（面试常问）什么是类加载器，类加载器有哪些？

通过类的权限定名获取该类的二进制字节流的代码块叫做类加载器，主要分为四种类加载器：

1、 启动类加载器(BootstrapClassLoader)：用来加载java核心类库，无法被java程序直接引用；
2、 扩展类加载器(extensionsclassloader)：它用来加载Java的扩展库JVM的实现会提供一个扩展库目录该类加载器在此目录里面查找并加载Java类；
3、 系统类加载器（systemclassloader）：它根据Java应用的类路径（CLASSPATH）来加载Java类一般来说，Java应用的类都是由它来完成加载的可以通过ClassLoader.getSystemClassLoader()来获取它；
4、 用户自定义类加载器，通过继承java.lang.ClassLoader类的方式实现；

3.1、加载器的分类

引导类加载器和自定义加载器：概念上，将所有派生于抽象类ClassLoader的类加载器都划分为自定义加载器

类图：

下面通过代码来获取类加载器

从结果可以看出：

• 对于用户自定义类来说，默认使用系统类加载器进行加载
• Java的核心类库，使用引导类加载器进行加载

3.2、启动类加载器

• C/C++语言实现，嵌套JVM内部
• 用来加载Java核心类库，rt.jar、resources.jar、sun.boot.class.path路径下的内容
• 并不继承java.lang.ClassLoader，没有父加载器
• 加载扩展类和应用程序类加载器，并指定为他们的父类加载器
• 出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类

下面通过代码来获取启动类加载器的加载路径

public class ClassLoaderTest {
   
     
    public static void main(String[] args) {
   
     
        URL[] urLs = Launcher.getBootstrapClassPath().getURLs();
        for (URL urL : urLs) {
   
     
            System.out.println(urL.toExternalForm());
        }
    }
}

3.3、扩展类加载器

• Java语言编写，由sun.misc.Launcher$ExtClassLoader实现
• 派生于ClassLoader类（这个不是启动类加载器）
• 父类加载器为启动类加载器
• 从java.ext.dirs系统属性所指定的目录中加载类库，或从jre/lib/ext子目录下加载类库

public class ClassLoaderTest {
   
     
    public static void main(String[] args) {
   
     
        System.out.println("扩展类加载器的加载路径：");
        String extDirs = System.getProperty("java.ext.dirs");
        for (String path : extDirs.split(";")) {
   
     
            System.out.println(path);
        }
    }
}

3.4、应用程序类加载器（系统类加载器）

• Java语言编写，由sun.misc.Launcher$AppClassLoader实现
• 派生于ClassLoader类
• 父类加载器为扩展类加载器
• 负责加载环境变量classpath或系统属性java.class.path指定路径下的类库

3.5、用户自定义类加载器

自定义类加载器的好处：

• 隔离加载类：例如使中间件的Jar包与应用程序Jar包不冲突
• 修改类加载的方式：启动类加载器必须使用，其他可以根据需要自定义加载
• 扩展加载源
• 防止源码泄露：对字节码进行加密，自定义类加载器实现解密

实现步骤：

1、 继承抽象类java.lang.ClassLoader类的方式，实现自己的类加载器；
2、 jdk1.2之前，继承并重写loadClass方法，1.2之后，建议把自定义的类加载逻辑写在findClass()方法中；
3、 如果没有太过复杂的需求，可以直接继承URLClassLoader类，可以避免自己编写findClass()方法，及其获取字节码流的方式，使自定义类加载器编写更加简洁；

示例代码：

public class CustomClassLoader extends ClassLoader {
   
     
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
   
     

        try {
   
     
            byte[] result = getClassFromCustomPath(name);
            if (result == null) {
   
     
                throw new FileNotFoundException();
            }
            return defineClass(name, result, 0, result.length);
        } catch (FileNotFoundException e) {
   
     
            e.printStackTrace();
        }
        return null;
    }

    private byte[] getClassFromCustomPath(String name) {
   
     
        // 从自定义路径中加载指定类：细节略
        // 如果指定路径的字节码文件进行了加密，则需要再次方法中进行解密操作
        return null;
    }
}

3.6、关于ClassLoader

ClassLoader是一个抽象类，除了启动类加载器（使用C或C++编写的），其他类加载器都继承自它。

4、双亲委派

（面试常问）什么是双亲委派模型？

原理：Java虚拟机对class文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象。而且加载某个类的class文件时，Java虚拟机采用的是双亲委派模式，即把请求交由父类处理，它是一种任务委派模式。

1、 如果一个类加载器收到了类加载请求，它并不会自己先去加载而是把这个请求委托给父类的加载器去执行；
2、 如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将达到顶层的启动类加载器；
3、 如果父类的加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式；

优点：

• 避免类的重复加载
• 保护程序安全，防止核心API被篡改

沙箱安全机制：保证对Java核心源代码的保护

在JVM中表示两个Class对象，是否为同一个类存在两个必要条件：

• 类的完整类名必须一致，包括包名
• 加载这个类的ClassLoader必须相同

JVM必须知道一个类型是由启动类加载器加载的，还是由用户类加载器加载的。如果是用户类加载器加载的，JVM会将这个类加载器的一个引用作为类型信息的一部分，保存到方法区中。