关于java:TMDJVM类加载原来是这样的

接上篇：https://segmentfault.com/a/11…

通过字节码，咱们理解了 class 文件的构造

通过运行数据区，咱们理解了 jvm 外部的内存划分及构造

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

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

留神：

加载的字节码起源，不肯定非得是 class 文件，能够是合乎字节码标准的任意中央，甚至二进制流等
从字节码到内存，是由加载器（ClassLoader）实现的，上面咱们具体看一下加载器相干内容

jvm 提供了 3 个零碎加载器，别离是Bootstrp loader、ExtClassLoader、AppClassLoader

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

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);
        }

    }
}

除了下面的零碎提供的 3 种 loader，jvm 容许本人定义类加载器，典型的在 tomcat 上：

拓展：感兴趣的同学也能够本人写一下，继承 ClassLoader 这个抽象类，并笼罩对应的 findClass 办法即可

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

1）概述

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

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

与一般类继承属性不同，类加载器会优先调父类的 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 库被随便篡改。

加载实现后，class 里定义的类构造就进入了内存的办法区。

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

而之所以把验证放在加载的前面，是因为除了根本的 class 文件格式，还须要其余很多验证，咱们一一来看：

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

是不是 CAFEBABYE 结尾
主次版本号是否在以后 jvm 虚拟机可运行的范畴内
常量池类型对不对
有没有其余不可辨认的信息
……等

总之，依据咱们上节讲的字节码剖析，要满足非法的字节码束缚

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

是否有父类？除了 Object 其余类必须有
是否继承了不该被继承的类，比方 final
是不是抽象类，是的话，办法都齐备了没
字段有没问题？是不是笼罩了父类里的 final
……等

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

最简单的一个阶段。

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

下面的验证是根本字节表格局验证。而这里次要验证 class 里定义的办法，看办法外部的 code 是否非法。

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

通过本阶段，能够确保你的代码执行时，不会产生大的意外

留神！不是齐全不会产生。比方你写了一段代码，jvm 只会晓得你的办法执行时合乎零碎规定。

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

最初一个阶段。

这个阶段也好了解，咱们下面的字节码解读时，晓得字节码里有的是间接援用，有的是指向了其余的字节码地址。

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

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

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

所做的事件好了解，然而要留神几点：

留神是类变量，也就是类里的动态变量，而不是 new 的那些实例变量。new 的在上面的初始化阶段

类变量 = 动态变量
实例变量 = 实例化 new 进去的那些

实践上这些值都在办法区里，然而留神，办法区自身就是一个逻辑概念。

1.6 里，在永恒代

1.8 当前，动态类变量如果是一个对象，其实它在堆里。这个下面咱们讲办法区的时候验证过。

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

留神！

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

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

看上面两个实例：

// 一般类变量：在筹备阶段为它开了内存空间，然而它的 value 是 int 的初始值，也就是 0！// 而真正的 123 赋值，是在类结构器，也就是上面的初始化阶段
public static int a = 123;

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

解析阶段开始解析类之间的关系，须要关联的类被加载。

这波及到：

类或接口的解析：类相干的父子继承，实现的接口都有哪些类型？
字段的解析：字段对应的类型？
办法的解析：办法的参数、返回值、关联了哪些类型
接口办法的解析：接口上的类型？

通过解析后，以后 class 里的办法字段父子继承等对象级别的关系解析实现。

这些操作上相干的类信息也被加载。

最初一个步骤，通过这个步骤后，类信息齐全进入了 jvm 内存，直到它被垃圾回收器回收。

后面几个阶段都是虚拟机来搞定的。咱们也干预不了，从代码上只能听从它的语法要求。

而这个阶段，是赋值，才是咱们应用程序中编写的有主导权的中央

在筹备阶段，jvm 曾经初始化了对应的内存空间，final 也有了本人的值。然而其余类变量，是在这里赋值实现的。

也就是咱们说的：

public static int a = 123;

这行代码的 123 才真正赋值实现。

1）类变量与实例变量的辨别

留神一件事件！

这里所说的初始化是一个 class 类加载到内存的过程，所谓的初始化值得是类里定义的类变量。也就是动态变量。

这个初始化要和 new 一个类辨别开来。new 的是实例变量，是在执行阶段才创立的。

2）实例变量创立的过程

当咱们在办法里写了一段代码，执行过程中，要 new 一个类的时候，会产生以下事件：

在办法区中找到对应类型的类信息
在以后办法栈帧的本地变量表中搁置一个 reference 指针
在堆中开拓一块空间，放这个对象的实例
将指针指向堆里对象的地址，竣工！

本文由 传智教育博学谷 教研团队公布。

如果本文对您有帮忙，欢送 关注 和点赞 ；如果您有任何倡议也可 留言评论 或私信，您的反对是我保持创作的能源。

转载请注明出处！

关于java:TMDJVM类加载原来是这样的

4.1 加载

4.1.1 概述

4.1.2 零碎加载器

4.1.3 自定义加载器

4.1.4 双亲委派

4.2 验证

4.2.1 文件格式验证

4.2.2 元数据验证

4.2.3 字节码验证

4.2.4 符号援用验证

4.3 筹备

4.3.1 变量类型

4.3.2 存储地位

4.3.3 初始化值

4.4 解析

4.4 初始化

4.4.1 概述

4.4.2 两个初始化