JVM学习第二章——类加载子系统

---

类加载子系统细节架构图

一、类加载子系统的作用

1. 类加载子系统负责从文件系统或者是网络系统等中加载class文件，class文件在文件的开头之中有特定的文件标识，即16进制的模数CA FE BA BE；
2. 加载后的Class类信息存放于一块名为方法区的内存空间；除了类信息之外，方法区还会存放运行时常量池信息，可能还包括字符串字面量和数字常量(这部分常量信息是Class文件中常量池部分的内存映射)；
3. 一张经典的JVM内存结构图：其中类加载子系统只会作用于下图的左半部分，不包括调用构造器实例化对象。
   
4. ClassLoader只负责将class文件进行加载，至于它是否可以运行，则由执行引擎做决定；
5. 如果调用构造器实例化对象，则对象存放在堆区。

二、类加载子系统功能的细分

加载

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

链接

链接分为三大块，即验证，准备，解析

验证

1. 目的在于确认当前Class文件的字节流中所包含的字节流信息符合当前虚拟机的要求，保证被加载类的正确性，以确保其不会危害虚拟机自身的安全；
2. 主要包括四种验证：文件格式验证，字节码验证，源数据验证，符号引用验证；

准备

1. 为类变量分配内存空间并设置该类变量的默认初始值，即零值；
2. 这里不包括用final修饰的static类变量，因为final在编译的时候就会被分配，在准备阶段会对其进行显式初始化；
3. 这里不会对实例变量分配初始化，因为类变量会被分配在方法区中，而实例变量会随着对象一起被分配到Java堆中。

解析

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

初始化，初始化阶段就是执行类构造器方法clinit()的过程

1. clinit()即"class or interface initialization method"，此处应注意它并不是指构造器init()；
2. 此方法不需要定义，是javac编译器自动收集类中的所有类变量的赋值动作以及静态代码块中的语句合并而来；
3. 如果我们没有静态变量static，那么在字节码文件中就不会有clinit()；而且构造器方法clinit()中的指令按照语句在源文件中出现的顺序执行；
4. 虚拟机必须保证一个类的clinit()方法在多线程的情况下会被同步加锁，即每一个类只需要被clinit一次，之后该类的内部信息就会被存储在方法区中。

三、类加载器的分类

1. JVM支持两种类型的类加载器，分别是引导类加载器(BootStrap ClassLoader，由C/C++编写)和自定义类加载器(由Java实现)；
2. 从概念上讲，自定义类加载器一般指的是由我们这种开发人员自己定义的一种类加载器，但是Java虚拟机规范将所有的派生于ClassLoader的类加载器都划分为自定义类加载器。
   
3. 值得注意的是，这里四者之间的关系是包含的关系，不是上层下层的关系，也不是子类父类的关系；
4. 在程序中我们最常见的类加载器是引导类加载器(BootStrapClassLoader)，自定义类加载器(ExtensionClassLoader、SystemClassLoader、User-Defined ClassLoader)

四、自定义类与核心类库的加载器

1. 对于用户自定义类加载器来说，它们使用的都是系统类加载器(SystemClassLoader)中的ApplicationClassLoader进行加载的；
2. Java核心类库都是使用引导类加载器进行加载的

public class ClassLoderTest {
    
    
    public static void main(String[] args) {
    
    
        //获取系统类加载器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println(systemClassLoader); //sun.misc.Launcher$AppClassLoader@18b4aac2

        //获取其上层，即扩展类加载器
        ClassLoader extClassLoader = systemClassLoader.getParent();
        System.out.println(extClassLoader); //sun.misc.Launcher$ExtClassLoader@1b6d3586

        //获取其上层，结果为null，因为引导类加载器是由C/C++编写的
        ClassLoader bootStrapClassLoader = extClassLoader.getParent();
        System.out.println(bootStrapClassLoader); //null

        //对于用户自定义类来说，使用系统类加载器进行加载
        ClassLoader classLoader = ClassLoderTest.class.getClassLoader();
        System.out.println(classLoader); //sun.misc.Launcher$AppClassLoader@18b4aac2

        //String类是通过引导类加载器进行加载的-->Java核心类库都是使用引导类加载器加载的
        ClassLoader classLoader1 = String.class.getClassLoader();
        System.out.println(classLoader1); //null
    }
}

五、虚拟机自带的类加载器

启动类加载器

1. 这个类加载器是由C/C++编写的，嵌套在JVM之中；
2. 它用于加载Java的核心类库(JAVA_HOME/jre/lib/rt.jar/resources.jar或sun.boot.class.path路径下的内容)，用于提供JVM自身需要的类；
3. 并不继承自java.lang.ClassLoader，没有父加载器；
4. 加载扩展类加载器和应用程序类加载器，并指定为他们的父类，即ClassLoader；
5. 出于安全考虑，启动类加载器只加载包名以java，javax，sun等来头的类

扩展类加载器

1. Java语言编写，由sun.misc.Launcher$ExtClassLoader实现;
2. 派生于ClassLoader类；
3. 从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录(扩展目录)下加载类库，如果用户创建的JAR放在此目录下，也会由扩展类加载器自动加载；

应用类加载器

1. Java语言编写，由sun.misc.Launcher$AppClassLoader实现；
2. 派生于ClassLoader类；
3. 它负责加载环境变量classpath或者是系统属性java.class.path指定路径下的类库
4. 该类加载器是程序默认的类加载器，一般来说，Java应用的类都是由它来加载的；
5. 通过getSystemClassLoader()可以获得此类加载器；

import sun.security.ec.CurveDB;

import java.net.URL;
import java.security.Provider;

public class ClassLoaderTest1 {
    
    
    public static void main(String[] args) {
    
    
        System.out.println("********启动类加载器*********");
        URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
        //获取BootStrapClassLoader能够加载的API路径
        for (URL e:urls){
    
    
            System.out.println(e.toExternalForm());
        }
        //Provider由引导类加载器加载
        ClassLoader classLoader = Provider.class.getClassLoader();
        System.out.println(classLoader); //null
        System.out.println("********拓展类加载器********");
        String extDirs = System.getProperty("java.ext.dirs");
        for (String path : extDirs.split(";")){
    
    
            System.out.println(path);
        }
        ClassLoader classLoader1 = CurveDB.class.getClassLoader();
        System.out.println(classLoader1); //sun.misc.Launcher$ExtClassLoader@4dc63996
    }
}

从下图中我们可以看到启动类加载器以及扩展类加载器可以加载的API路径

六、用户自定义类加载器

为什么要使用用户自定义类加载器

1. 隔离加载类
2. 修改类的加载方式
3. 扩展加载源
4. 防止源码泄露

用户自定义类加载器的实现步骤

1. 开发人员可以通过继承抽象类加载器java.lang.ClassLoader类的方式，实现自己的类加载，以满足一些特定的需求；
2. 在JDK1.2之前，在自定义类加载器的时候，总是会继承ClassLader类并重写loadClass()方法，从而实现自定义的类加载器，但是在JDK1.2之后，已经不再建议用户去覆盖loadClass()方法，而是建议把自定义的类加载逻辑编写在findClass()方法中；
3. 在编写自定义类加载器的时候，如果没有太过于复杂的需求，可以直接继承URLClassLoader类，这样就可以避免自己去编写findClass()方法逻辑以及获取字节流的方式，使自定义类加载器的编写更加简洁；

七、ClassLoader的常用方法以及获取方式

方法名称	描述
getParent()	返回该类加载器的超类加载器
loadClass(String name)	加载名称为name的类，返回结果为java.lang.Class类的实例
findClass(String name)	加载名称为name的类，返回结果为java.lang.Class类的实例
findLoadedClass(String name)	查找名称为name的已经被加载过的类，返回结果为java.lang.Class类的实例
defineClass(String name, byte[] b, int off, int len)	把字节数组b中的内容转换为一个Java类，返回结果为java.lang.Class类的实例
resolveClass(Class<?> c)	连接指定的一个类

获取ClassLoader的途径

代码示例

public class ClassLoaderTest2 {
    
    
    public static void main(String[] args) {
    
    
        try {
    
    
            ClassLoader classLoader = Class.forName("java.lang.String").getClassLoader();
            System.out.println(classLoader);

            ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
            System.out.println(contextClassLoader);

            ClassLoader parent = ClassLoader.getSystemClassLoader().getParent();
            System.out.println(parent);
        } catch (ClassNotFoundException e) {
    
    
            e.printStackTrace();
        }
    }
}

八、双亲委派机制

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

双亲委派机制的工作原理

所以当我们自定义了一个java.lang.String从而尝试覆盖核心类库中的String的时候，由于双亲委派机制的存在，启动类加载器会加载Java核心类库中的String类，所以我们尝试并不会成功，如果我们在自己的String中加入main方法，IDEA会报错，因为核心类库中的String并没有main方法。

双亲委派机制的优势

1. 防止类的重复加载；
2. 保护程序安全，防止核心API被随意篡改：启动类加载器可以抢在标准扩展类装载器之前去装载类，而标准扩展类装载器可以抢在类路径加载器之前去装载那个类，类路径装载 器又可以抢在自定义类加载器之前去加载它。所以Java虚拟机先从最可信的Java核心API查找类型，这是为了防止不可靠的类扮演被信任的类，试想一 下，网络上有个名叫java.lang.Integer的类，它是某个黑客为了混进java.lang包所起的名字，实际上里面含有恶意代码，但是这种伎俩在双亲模式加载体系结构下是行不通的，因为网络类加载器在加载它的时候，它首先调用双亲类加载器，这样一直向上委托，直到启动类加载器，而启动类加载器在核心Java API中发现了这个名字的类，所以它就直接加载Java核心API的java.lang.Integer类，然后将这个类返回，所以自始至终网络上的 java.lang.Integer的类都不会被加载；
3. 设置核心API包的访问权限：但是如果这个移动代码不是去试图替换一个被信任的类（就是前面说的那种情况），而是想在一个被信任的包中插入一个全新的类型，情况会怎样呢？比如一个名为 java.lang.Virus的类，经过双亲委托模式，最终类装载器试图从网络上下载这个类，因为网络类装载器的双亲们都没有这个类。假设成功下载了这个类，那你肯定会想，Virus和lang下的其他类同在java.lang包下，暗示这个类是Java API的一部分，那么它是不是也拥有修改Java.lang包中数据的权限呢？答案当然不是，因为要取得访问和修改java.lang包中的权 限，java.lang.Virus和java.lang下其他类必须是属于同一个运行时包的，什么是运行时包？运行时包是指由同一个类装载器装载的、属于同一个包的、多个类型的集合。考虑一下，java.lang.Virus和java.lang其他类是同一个类装载器装载的吗？当然不是，java.lang.Virus是由网络类装载器装载的；

双亲委派机制在SPI中的应用

1. 某个应用程序通过双亲委派机制找到引导类加载器，首先调用rt.jar包中的SPI核心，但是由于SPI核心中有各种各样的接口需要实现（这里指具体的服务提供商），这里我们以JDBC.jar为例，JDBC.jar可以为我们提供具体的实现；
2. 那么这个时候我们需要反向委托，找到线程上下文类加载器去加载JDBC.jar；
3. 线程上下文类加载器属于系统类加载器；
   

九、JVM中表示两个class对象是否是同一个类

1. 在JVM中表示两个class对象是否为同一个类存在两个必要条件：类的完整类名必须一致；两个类的ClassLoader(这里是指ClassLoader实例对象)必须相同；
2. 换句话说，在JVM中，即使两个class对象来源于同一个Class文件且被同一个虚拟机加载，只要他们的类加载器实例不同，那么这两个类对象也是不相等的；
3. 对类加载器的使用，JVM必须知道一个类型是由引导类加载器加载的还是由用户类加载器加载的，如果一个类型是由用户类加载器加载的，那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中；当解析一个类型到另一个类型的引用的时候，JVM需要保证两个类型的类加载器是相同的；

十、类的主动使用和被动使用

Java程序对类的使用方式分为两种：主动使用和被动使用，即是否调用了clinit()方法；主动使用会在类加载系统中的第三阶段Initialization也就是初始化阶段会调用clinit()方法，而被动使用则不会调用。其中主动使用主要分为以下七种情况：

1. 创建类的实例；
2. 访问某个类或者是接口的静态变量，或者是对静态变量进行赋值；
3. 调用类的静态方法；
4. 反射，比如Class.forName(XXX)；
5. 初始化一个类的子类；
6. Java虚拟机在启动时被标记为启动类的类；
7. JDK 7 开始提供的动态语言支持：java.lang.invoke.MethodHandle实例的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic句柄对应的类没有初始化，则初始化；
   除了以上七种情况之外，其他使用Java类的方式都被看做是对类的被动使用，都不会导致类的初始化。