您的位置: 首页 > 技术杂谈 > 正文

TMD，JVM类加载原来是这样的！！！！

2022-11-24 15:00 https://my.oschina.net/jiagoushi/blog/5598456 博学谷狂野架构师次阅读条评论

接上篇：https://my.oschina.net/jiagoushi/blog/5597878

通过字节码，我们了解了class文件的结构

通过运行数据区，我们了解了jvm内部的内存划分及结构

接下来，让我们看看，字节码怎么进入jvm的内存空间，各自进入那个空间，以及怎么跑起来。

file

4.1 加载

4.1.1 概述

类的加载就是将class文件中的二进制数据读取到内存中，然后将该字节流所代表的静态数据结构转化为方法区中运行的数据结构，并且在堆内存中生成一个java.lang.Class对象作为访问方法区数据结构的入口。

file

注意：

加载的字节码来源，不一定非得是class文件，可以是符合字节码规范的任意地方，甚至二进制流等
从字节码到内存，是由加载器（ClassLoader）完成的，下面我们详细看一下加载器相关内容

4.1.2 系统加载器

jvm提供了3个系统加载器，分别是Bootstrp loader、ExtClassLoader 、AppClassLoader

这三个加载器互相成父子继承关系

file

1）Bootstrp loader

Bootstrp加载器是用C++语言写的，它在Java虚拟机启动后初始化

它主要负责加载以下路径的文件：

%JAVA_HOME%/jre/lib/*.jar
%JAVA_HOME%/jre/classes/*
-Xbootclasspath参数指定的路径

System.out.println(System.getProperty("sun.boot.class.path"));

2）ExtClassLoader

ExtClassLoader是用Java写的，具体来说就是 sun.misc.Launcher$ExtClassLoader

ExtClassLoader主要加载：

%JAVA_HOME%/jre/lib/ext/*
ext下的所有classes目录
java.ext.dirs系统变量指定的路径中类库

System.getProperty("java.ext.dirs")

3）AppClassLoader

AppClassLoader也是用Java写成的，它的实现类是 sun.misc.Launcher$AppClassLoader，另外我们知道ClassLoader中有个getSystemClassLoader方法，此方法返回的就是它。

负责加载 -classpath 所指定的位置的类或者是jar文档
也是Java程序默认的类加载器

System.getProperty("java.class.path")

4）验证

很简单，使用一段代码打印对应的property信息就可以查到当前三个类加载器所加载的目录

package com.itheima.jvm.load;

public class SystemLoader {
    public static void main(String[] args) {
        String[] bootstrap = System.getProperty("sun.boot.class.path").split(":");
        String[] ext = System.getProperty("java.ext.dirs").split(":");
        String[] app = System.getProperty("java.class.path").split(":");

        System.out.println("bootstrap:");
        for (String s : bootstrap) {
            System.out.println(s);
        }

        System.out.println();

        System.out.println("ext:");
        for (String s : ext) {
            System.out.println(s);
        }

        System.out.println();

        //app是默认加载器，注意启动控制台的 -classpath 选项
        System.out.println("app:");
        for (String s : app) {
            System.out.println(s);
        }

    }
}

4.1.3 自定义加载器

除了上面的系统提供的3种loader，jvm允许自己定义类加载器，典型的在tomcat上：

拓展：感兴趣的同学也可以自己写一下，继承ClassLoader这个抽象类，并覆盖对应的findClass方法即可

file

接下来我们看一个重点：双亲委派

4.1.4 双亲委派

1）概述

file

类加载器加载某个类的时候，因为有多个加载器，甚至可以有各种自定义的，他们呈父子继承关系。

这给人一种印象，子类的加载会覆盖父类，其实恰恰相反！

与普通类继承属性不同，类加载器会优先调父类的load方法，如果父类能加载，直接用父类的，否则最后一步才是自己尝试加载，从源代码上可以验证。

ClassLoader.loadClass()方法：

protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        synchronized (getClassLoadingLock(name)) { 
          	// 首先，检测是否已经加载 
            Class<?> c = findLoadedClass(name);
            if (c == null) {
              	//如果没有加载，开始按如下规则执行：
                long t0 = System.nanoTime();
                try {
                    if (parent != null) { 
                      	//重点！父加载器不为空则调用父加载器的loadClass 
                        c = parent.loadClass(name, false);
                    } else { 
                      	//父加载器为空则调用Bootstrap Classloader 
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) { 
                }
                if (c == null) {
                    long t1 = System.nanoTime(); 
                  	//父加载器没有找到，则调用findclass，自己查找并加载
                    c = findClass(name); 
                }
            }
            if (resolve) { 
                resolveClass(c);
            }
            return c;
        }
    }

2）为什么这么设计呢？

避免重复加载、避免核心类篡改

采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。

其次是考虑到安全因素，java核心api中定义类型不会被随意替换，假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java。

API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class

即便是父类没加载，也会优先让父类去加载特定系统目录里的class，你获取到的依然是jvm内的核心类，而不是你胡乱改写的。这样便可以防止核心API库被随意篡改。

4.2 验证

加载完成后，class里定义的类结构就进入了内存的方法区。

而接下来，验证是连接阶段的第一步。实际上，验证和上面的加载是交互进行的（比如class文件格式验证）。

而之所以把验证放在加载的后面，是因为除了基本的class文件格式，还需要其他很多验证，我们逐个来看：

4.2.1 文件格式验证

这个好理解，就是验证加载的字节码是不是符合规范

是不是CAFEBABYE开头
主次版本号是否在当前jvm虚拟机可运行的范围内
常量池类型对不对
有没有其他不可识别的信息
……等

总之，根据我们上节讲的字节码分析，要满足合法的字节码约束

4.2.2 元数据验证

到java语法级别了。这个阶段主要验证属性、字段、类关系、方法等是否合规

是否有父类？除了Object其他类必须有
是否继承了不该被继承的类，比如final
是不是抽象类，是的话，方法都完备了没
字段有没问题？是不是覆盖了父类里的final
……等

总之，经过这个阶段，你的类对象结构是ok的了

4.2.3 字节码验证

最复杂的一个阶段。

等等，字节码前面不是验证过了吗？咋还要验证？

上面的验证是基本字节表格式验证。而这里主要验证class里定义的方法，看方法内部的code是否合法。

类型转换是不是有问题？
指令是否跳到了方法外的字节码上？
……

经过本阶段，可以确保你的代码执行时，不会发生大的意外

注意！不是完全不会发生。比如你写了一段代码，jvm只会知道你的方法执行时符合系统规则。

它也不知道你会不会执行很长很长时间导致系统卡死

4.2.4 符号引用验证

最后一个阶段。

这个阶段也好理解，我们上面的字节码解读时，知道字节码里有的是直接引用，有的是指向了其他的字节码地址。

而符号引用验证的就是，这些引用的对应的内容是否合法。

utf8里记了某个类的名字，这个类存在不？
方法或字段引用，这些方法在对应的类里存在不存在？
类、字段、方法等上面的可见性是否合法
……

4.3 准备

这个阶段为class中定义的各种类变量分配内存，并赋初始值。

所做的事情好理解，但是要注意几点：

4.3.1 变量类型

注意是类变量，也就是类里的静态变量，而不是new的那些实例变量。new的在下面的初始化阶段

类变量 = 静态变量
实例变量 = 实例化new出来的那些

4.3.2 存储位置

理论上这些值都在方法区里，但是注意，方法区本身就是一个逻辑概念。

1.6里，在永久代

1.8以后，静态类变量如果是一个对象，其实它在堆里。这个上面我们讲方法区的时候验证过。

4.3.3 初始化值

这个值进入了内存，那到底内存里放的value是啥？

注意！

即便是static变量，它在这个阶段初始化进内存的依然是它的初始值！

而不是你想要什么就是什么。

看下面两个实例：

//普通类变量：在准备阶段为它开了内存空间，但是它的value是int的初始值，也就是 0！
//而真正的123赋值，是在类构造器，也就是下面的初始化阶段
public static int a = 123;

//final修饰的类变量，编译成字节码后，是一个ConstantValue类型
//这种类型，在准备阶段，直接给定值123，后期也没有二次初始化一说
public static final int b = 123;