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

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

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

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

4.1 加载

4.1.1 概述

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

留神：

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

4.1.2 零碎加载器

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

4.1.3 自定义加载器

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

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

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

4.1.4 双亲委派

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库被随便篡改。

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;

4.4 解析

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

这波及到：

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

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

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

4.4 初始化

4.4.1 概述

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

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

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

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

也就是咱们说的：

public static int a = 123;

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

4.4.2 两个初始化

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

留神一件事件！

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

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

2）实例变量创立的过程

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

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

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

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

转载请注明出处！