Java虚拟机-类加载子系统

本文最后更新于：2 年前

初始化顺序？

（非静态：默认初始化-显示初始化-代码块初始化-无参构造初始化 or 有参构造初始化）

（静态：默认-显示-静态代码块-非静态代码块-无参构造初始化 or 有参构造初始化）

A 类引用了 B,C,C 引用 B，程序入口 A，类加载顺序？

BCA，先加载父类。

怎样将两个全路径相同的类加载到内存？

类相同还需类加载器相同，自定义类加载器即可

类加载过程

加载

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

加载 class 文件的方式：

从本地系统中直接加载
通过网络获取，典型场景：Web Applet
从 zip 压缩包中读取，成为日后 jar、war 格式的基础
运行时计算生成，使用最多的是：动态代理技术
由其他文件生成，典型场景：JSP 应用从专有数据库中提取.class 文件，比较少见
从加密文件中获取，典型的防 Class 文件被反编译的保护措施

链接（验证-准备-解析）

链接分为三个子阶段：验证 —> 准备 —> 解析

验证(Verify)

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

准备(Prepare)

为类变量（static 变量）分配内存并且设置该类变量的默认初始值，即零值
这里不包含用 final 修饰的 static，因为final 在编译的时候就会分配好了默认值，准备阶段会显式初始化
注意：这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到 Java 堆中

解析(Resolve)

将常量池内的符号引用转换为直接引用的过程
事实上，解析操作往往会伴随着 JVM 在执行完初始化之后再执行
符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《java 虚拟机规范》的 class 文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的 CONSTANT Class info、CONSTANT Fieldref info、CONSTANT Methodref info 等

初始化

java 类的初始化时机（对类的使用）：
主动使用：
创建类的实例
访问某个类或接口的静态变量，或者对该静态变量赋值
调用类的静态方法
反射（比如：Class.forName(“com.atguigu.Test”)）
初始化一个类的子类
Java 虚拟机启动时被标明为启动类的类
JDK7 开始提供的动态语言支持：

java.lang.invoke.MethodHandle 实例的解析结果 REF_getStatic、REF putStatic、REF_invokeStatic 句柄对应的类没有初始化，则初始化
除了以上七种情况，其他使用 Java 类的方式都被看作是对类的被动使用，都不会导致类的初始化，会加载，不会初始化。即不会执行初始化阶段（不会调用 clinit() 方法和 init() 方法）

clinit()
初始化阶段就是执行类构造器方法**()**的过程
此方法不需定义，是 javac 编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。也就是说，当我们代码中包含 static 变量的时候，就会有 clinit 方法
()方法中的指令按语句在源文件中出现的顺序执行
()不同于类的构造器。（关联：构造器是虚拟机视角下的()）

若该类具有父类，JVM 会保证子类的()执行前，父类的()已经执行完毕（父类先执行）。Son 类的父类是 Father 类，所以需要先执行 Father 类的加载，再执行 Son 类的加载

类加载器

JVM 严格来讲支持两种类型的类加载器 。分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）

虚拟机自带的加载器

启动类加载器（引导类加载器，Bootstrap ClassLoader）
这个类加载使用 C/C++语言实现的，嵌套在 JVM 内部
它用来加载Java 的核心库（JAVA_HOME/jre/lib/rt.jar、resources.jar 或 sun.boot.class.path 路径下的内容），用于提供 JVM 自身需要的类
并不继承自 java.lang.ClassLoader，没有父加载器
加载扩展类和应用程序类加载器，并作为他们的父类加载器
出于安全考虑，Bootstrap 启动类加载器只加载包名为java、javax、sun等开头的类

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

应用程序类加载器（也称为系统类加载器，AppClassLoader）
Java 语言编写，由 sun.misc.LaunchersAppClassLoader 实现
派生于 ClassLoader 类
父类加载器为扩展类加载器
它负责加载环境变量 classpath 或系统属性 java.class.path 指定路径下的类库
该类加载是程序中默认的类加载器，一般来说，Java 应用的类都是由它来完成加载
通过 classLoader.getSystemclassLoader()方法可以获取到该类加载器

用户自定义类加载器

什么时候需要自定义类加载器？
在 Java 的日常应用程序开发中，类的加载几乎是由上述 3 种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。那为什么还需要自定义类加载器？

隔离加载类（比如说我假设现在 Spring 框架，和 RocketMQ 有包名路径完全一样的类，类名也一样，这个时候类就冲突了。不过一般的主流框架和中间件都会自定义类加载器，实现不同的框架，中间价之间是隔离的）

修改类加载的方式
扩展加载源（还可以考虑从数据库中加载类，路由器等等不同的地方）
防止源码泄漏（对字节码文件进行解密，自己用的时候通过自定义类加载器来对其进行解密）

如何自定义类加载器？
开发人员可以通过继承抽象类java.lang.ClassLoader 类的方式，实现自己的类加载器，以满足一些特殊的需求
在 JDK1.2 之前，在自定义类加载器时，总会去继承 ClassLoader 类并重写 loadClass()方法，从而实现自定义的类加载类，但是在 JDK1.2 之后已不再建议用户去覆盖 loadClass()方法，而是建议把自定义的类加载逻辑写在findclass()方法中
在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承 URIClassLoader 类，这样就可以避免自己去编写 findclass()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。
ClassLoader 类，它是一个抽象类，其后所有的类加载器都继承自 ClassLoader（不包括启动类加载器）

双亲委派机制

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

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

父类加载器一层一层往下分配任务，如果子类加载器能加载，则加载此类，如果将加载任务分配至系统类加载器也无法加载此类，则抛出异常。

双亲委派机制优势

避免类的重复加载
保护程序安全，防止核心 API被随意篡改
自定义类：自定义 java.lang.String 没有被加载。
自定义类：java.lang.ShkStart（报错：阻止创建 java.lang 开头的类）

如何判断两个 class 对象是否相同？

在 JVM 中表示两个 class 对象是否为同一个类存在两个必要条件：
1，类的完整类名必须一致，包括包名
2，加载这个类的ClassLoader（指 ClassLoader 实例对象）必须相同

换句话说，在 JVM 中，即使这两个类对象（class 对象）来源同一个 Class 文件，被同一个虚拟机所加载，但只要加载它们的 ClassLoader 实例对象不同，那么这两个类对象也是不相等的

对类加载器的引用
JVM 必须知道一个类型是由启动加载器加载的还是由用户类加载器加载的
如果一个类型是由用户类加载器加载的，那么 JVM 会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中
当解析一个类型到另一个类型的引用的时候，JVM 需要保证这两个类型的类加载器是相同的。

打破双亲委派机制？

打破双亲委派机制的场景有很多：JDBC、Tomcat 等

为什么 JDBC 需要破坏双亲委派模式，原因是原生的 JDBC 中 Driver 驱动本身只是一个接口，并没有具体的实现，具体的实现是由不同数据库类型去实现的。例如，MySQL 的 mysql-connector-.jar 中的 Driver 类具体实现的。

原生的 JDBC 中的类是放在 rt.jar 包的，是由启动类加载器进行类加载的，在 JDBC 中的 Driver 类中需要动态去加载不同数据库类型的 Driver 类，而 mysql-connector-.jar 中的 Driver 类是用户自己写的代码，那启动类加载器肯定是不能进行加载的，既然是自己编写的代码，那就需要由应用程序启动类去进行类加载。

于是乎，这个时候就引入线程上下文件类加载器(Thread Context ClassLoader)。有了这个东西之后，程序就可以把原本需要由启动类加载器进行加载的类，由应用程序类加载器去进行加载了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
private static Connection getConnection(
        String url, java.util.Properties info, Class<?> caller) throws SQLException {
        /*
         * When callerCl is null, we should check the application's
         * (which is invoking this class indirectly)
         * classloader, so that the JDBC driver class outside rt.jar
         * can be loaded from here.
         */
        //callerCL为空的时候，其实说明这个ClassLoader是启动类加载器，但是这个启动类加载并不能识别rt.jar之外的类，这个时候就把callerCL赋值为Thread.currentThread().getContextClassLoader();也就是应用程序启动类
        ClassLoader callerCL = caller != null ? caller.getClassLoader() : null;
        synchronized(DriverManager.class) {
            // synchronize loading of the correct classloader.
            if (callerCL == null) {
                callerCL = Thread.currentThread().getContextClassLoader();
            }
        }

        if(url == null) {
            throw new SQLException("The url cannot be null", "08001");
        }

        println("DriverManager.getConnection(\"" + url + "\")");

        // Walk through the loaded registeredDrivers attempting to make a connection.
        // Remember the first exception that gets raised so we can reraise it.
        SQLException reason = null;

        for(DriverInfo aDriver : registeredDrivers) {
            // If the caller does not have permission to load the driver then
            // skip it.
            //继续看这里 
            if(isDriverAllowed(aDriver.driver, callerCL)) {
                try {
                    println("    trying " + aDriver.driver.getClass().getName());
                    Connection con = aDriver.driver.connect(url, info);
                    if (con != null) {
                        // Success!
                        println("getConnection returning " + aDriver.driver.getClass().getName());
                        return (con);
                    }
                } catch (SQLException ex) {
                    if (reason == null) {
                        reason = ex;
                    }
                }

            } else {
                println("    skipping: " + aDriver.getClass().getName());
            }

        }

        // if we got here nobody could connect.
        if (reason != null)    {
            println("getConnection failed: " + reason);
            throw reason;
        }

        println("getConnection: no suitable driver found for "+ url);
        throw new SQLException("No suitable driver found for "+ url, "08001");
    }

    private static boolean isDriverAllowed(Driver driver, ClassLoader classLoader) {
        boolean result = false;
        if(driver != null) {
            Class<?> aClass = null;
            try {
                //这一步会对类进行初始化的动作，而初始化之前自然也要进行的类的加载工作
                aClass =  Class.forName(driver.getClass().getName(), true, classLoader);
            } catch (Exception ex) {
                result = false;
            }

             result = ( aClass == driver.getClass() ) ? true : false;
        }

        return result;
    }