一文打穿JVM体系结构

小灰灰 2022-12-08 05:22 180阅读 0赞

# JVM体系结构概述 #

## JVM的位置 ##

![image-20200820113544947][]

## JVM体系结构 ##

![image-20200820113802853][]

### 类装载器 ClassLoader ###

#### ClassLoader功能 ####

负责加载class文件，class文件在**文件开头有特定的文件标识**，将class文件字节码内容加载到内存中，并将这些内容转换成方法区中的运行时数据结构并且ClassLoader只负责class文件的加载，至于他是否可以运行，则Execution Engine决定

![image-20200820121030085][]

.class文件中特定的文件标识：

cafe babe

通过特定的文件标识和其他识别内容，JVM能识别是否为class文件

![image-20200820121201746][]

#### ClassLoader分类 ####

ClassLoader主要分为四种

![image-20200820221138147][]

##### 系统自带ClassLoader #####

*  **启动类加载器**（Bootstrap）：
    
     *  如果JDK自带类，使用该加载器；
     *  Java输出为null，因为是C++编写
     *  rt.jar包下的内容
 *  **扩展类加载器**（Extension）：
    
     *  jre/ext/\*.jar包的内容，使用该加载器；
     *  扩展类加载器只能加载jar包
     *  在java运行时可以指定拓展类路径
        
            -Djava.ext.dirs=$PATH
 *  **应用程序类加载器**（AppClassLoader）：
    
     *  用户自己创建的类加载，使用该类加载器；

package com.yankaizhang;
    
    import com.sun.crypto.provider.AESKeyGenerator;
    
    public class MyObject {
        
        public static void main(String[] args) {
        
    
            // 启动类加载器
            Object o = new Object();
            System.out.println(o.getClass().getClassLoader());
    
            // 拓展类加载器
            AESKeyGenerator aesKeyGenerator = new AESKeyGenerator();
            System.out.println(aesKeyGenerator.getClass().getClassLoader());
    
            // 用户自定义类加载器
            MyObject myObject = new MyObject();
            System.out.println(myObject.getClass().getClassLoader());
    
    
            // 从自定义类加载器开始的继承关系
            System.out.println("------------------------");
            System.out.println(myObject.getClass().getClassLoader().getParent().getParent());
            System.out.println(myObject.getClass().getClassLoader().getParent());
            System.out.println(myObject.getClass().getClassLoader());
        }
    }

上面代码输出结果如下：

null
    sun.misc.Launcher$ExtClassLoader@77459877
    sun.misc.Launcher$AppClassLoader@18b4aac2
    ------------------------
    null
    sun.misc.Launcher$ExtClassLoader@77459877
    sun.misc.Launcher$AppClassLoader@18b4aac2

除此之外，启动类加载器的parent会报NPE，因为null没有父类

##### 用户自定义ClassLoader #####

*  **用户自定义加载器**（Java.lang.ClassLoader的子类）：
    
     *  继承于抽象类ClassLoader
     *  用于用户自己定义加载器

#### ClassLoader双亲委派机制 ####

为了保证用户自定义的代码不污染jdk自带内容，于是有双亲委派机制

当一个类收到了类加载请求，他首先不会尝试自己去加载这个类，而是把请求委派给父类去完成，每一个层次类加载器都是如此，因此所有的加载请求都应该传送到启动类加载器（Bootstrap），只有当其父类加载器反馈自己无法完成这个请求的时候（在它的加载路径下面没有找到所需加载的Class），子类加载器才会尝试自己去加载。

双亲委派的好处是，比如加载位于rt.jar包中的类java.lang.Object，不管是哪个加载器加载的这个类，最终都是委托给顶层的Bootstrap进行加载，这样就保证了使用不同的类加载器最终得到的都是同一个Object对象。

#### ClassLoader沙箱安全机制 ####

沙箱安全机制是由基于双亲委派机制上，采取的一种JVM的自我保护机制；假设自己写一个java.lang.String 的类，在类中自定义方法，由于双亲委派机制的原理,此请求会先交给Bootstrap试图进行加载，但是Bootstrap在加载类时首先通过包和类名查找rt.jar中有没有该类，有则优先加载rt.jar包中的类，没有自定义方法会报错，因此就保证了java的运行机制不会被破坏。

### 执行引擎 Execution Engine ###

#### Execution Engine介绍 ####

**执行引擎是JVM的核心组成部分之一**。

虚拟机是一个相对于“物理机”的概念，这两种机器都有代码执行能力，其区别是物理机的执行引擎是直接建立在处理器、缓存、指令集和操作系统层面上的，而虚拟机的执行引擎则是由软件自行实现的，因此可以不受物理条件制约地定制指令集与执行引擎的结构体系，能够执行那些不被硬件直接支持的指令集格式。

JVM的主要任务是负责装载字节码到其内部，但字节码并不能够直接运行在操作系统之上，因为字节码指令并非等价于本地机器指令，它内部包含的仅仅只是一些能够被JVM锁识别的字节码指令、符号表和其他辅助信息。那么，如果**想让一个Java程序运行起来、执行引擎的任务就是将字节码指令解释/编译为对应平台上的本地机器指令**才可以。简单来说，JVM中的执行引擎充当了将高级语言翻译为机器语言的译者。

#### Execution Engine工作过程 ####

从外观上来看，所有的Java虚拟机的执行引擎输入、输出都是一致的：输入的是字节码二进制流，处理过程是字节码解析执行的等效过程，输出的是执行结果。

*  执行引擎在执行的过程中究竟需要执行什么样的字节码指令完全依赖于PC寄存器。
 *  每当执行完一项指令操作后，**PC寄存器就会更新下一条需要被执行的指令地址**。
 *  当然方法在执行的过程中，执行引擎有可能会通过存储在**局部变量表中的对象引用准确定位到存储在Java堆区中的对象实例信息，以及通过对象头中的元数据指针定位到目标对象的类型信息**。

![image-20200820124252630][]

### 本地方法栈 Native ###

*  本地方法栈（Native Method Stack）
    
    在本地方法栈中登记native方法，在Execution Engine执行时加载本地方法库
 *  本地方法接口（Native Interface）
    
    本地方法接口时融合其他语言程序
 *  本地方法库（Native library）
    
    存放本地方法

### 程序计数器 PC ###

PC寄存器就是程序计数器（Program Counter Register）

*  每个线程都有一个程序计数器，是**线程私有的**
 *  PC寄存器指向方法区中的方法字节码（存储下一条指令的地址，即将要执行的指令代码）
 *  PC寄存器的占用的内存区域很小，是当前线程所执行的字节码的行号指示器，字节码解释器通过改变这个计数器的值来选取下一条指令
 *  如果执行的是native方法，则PC寄存器为空
 *  不产生OOM
 *  几乎不存在GC

### 方法区 Method Area ###

方法区是供**各线程共享的运行时内存区域，存储内容为类的结构信息（类的模板）。**

例如运行时常量池、字段和方法数据、构造函数和普通方法的字节码内容。

*  方法区就是一种规范，不同的虚拟机里面实现不一样（例如永久代和元空间）
 *  存在垃圾回收（少量）
 *  实例变量存储在堆空间，和方法区无关，方法区只存储一些公用的、可以成为模板的内容

public class Test {
        
    
        public void change(String str){
        
            str = "change";
        }
    
        public static void main(String[] args) {
        
            String str = "111";
            new Test().change(str);
            System.out.println(str);
        }
    
    }

上面这个例子，str指向的地址是运行时常量池，而change方法的str参数引用在执行时重新指向了运行时常量池"change"字符串，所以这时的str引用和原来的str引用已经没关系了

所以最终打印的str仍然是111

### Java栈 Java Stack ###

Java栈存放运行时内容

主要存放内容有：8种基本类型的变量、对象的引用变量、实例方法

*  生命周期和线程一致，并且是线程私有的，线程结束栈内存一并释放不存在GC
 *  栈内的抽象存储单元称为栈帧，栈帧所含内容具体如下：
    
     *  本地变量（Local Variables）：压栈方法输入参数、输出参数和中间变量
     *  栈操作（Operand Stack）：出栈、入栈的操作记录
     *  栈帧数据（Frame Data）：包括类文件、方法等
 *  每个方法执行的同时都会创建一个栈帧，用于存储局部变量表、操作数栈、指向运行时常量池的引用、动态链接、方法返回地址等信息
 *  栈的大小和JVM的实现有关，通常在256K~756K之间，约为1MB

**StackOverflowError**

public class Overflow {
        
    
        public void run(){
        
            run();
        }
    
        public static void main(String[] args) {
        
            new Overflow().run();
        }
    }

以下代码由于递归调用，栈内方法数量无限增长，超出栈内存上线就会抛出StackOverflowError错误，注意这不是异常而是错误Error级别

![image-20200820231847976][]

### 堆 Heap ###

逻辑组成：

![image-20200820233855600][]

物理组成：新生代+老年代

新生代是累的诞生、成长、消亡的区域；一个类在这里产生、应用，最后被GC回收，结束生命。

新生代分为两部分：伊甸区和幸存者区，所有类都是在伊甸区被new出来的，幸存者有2个：0区和1区。

当伊甸区的空间用完时，程序此时又需要创建对象，JVM的垃圾回收器将对伊甸区进行垃圾回收（Minor GC），将伊甸区中的不再被其他对象所引用的对象进行销毁，然后将伊甸区中剩余的对象移动到S0区。

如果S0区也满了，就再对该区进行GC，然后将剩余对象移动到S1区

如果S1区满了，就再对该区进行GC，然后将剩余对象移动到老年区

如果老年区满了，则会触发Major GC（Full GC）

如果Full GC之后发现依然无法进行对象的保存，会产生OOM错误

#### 新生代 Young/New ####

##### 伊甸区 Eden #####

伊甸区已满，触发YGC

GC = YGC（Young GC）轻GC

Eden区基本全部清空

##### 幸存0区 Survivor 0 Space #####

S0 = from 区

##### 幸存1区 Survivor 1 Space #####

S1 = to区

每次GC之后S0和S1交换

#### 老年代 Old ####

Old区已满，触发FGC

Full GC = FGC 重GC

Old区多次FGC无果后，会报**OutOfMemory**错误

![image-20200821221356690][]

#### 永久代Perm和元空间meta ####

逻辑上是堆的一部分，物理上对应Method Area方法区

虽然JVM规范将方法区描述为堆的一个逻辑部分，但他还有一个别名叫Non-Heap（非堆），目的就是要和堆区分开。

![image-20200821223325758][]

[image-20200820113544947]: https://gitee.com/dzzhyk/markdown-pics/raw/master/img/20200918140257.png
[image-20200820113802853]: /images/20221123/8f37aa5b733440aead05faf5c606e07a.png
[image-20200820121030085]: /images/20221123/b7b1d6ecdad54753b46889c48fdd655d.png
[image-20200820121201746]: /images/20221123/1a81b0d755be4039a2ecc22aeefb56db.png
[image-20200820221138147]: https://gitee.com/dzzhyk/markdown-pics/raw/master/img/20200918140318.png
[image-20200820124252630]: https://gitee.com/dzzhyk/markdown-pics/raw/master/img/20200918140324.png
[image-20200820231847976]: https://gitee.com/dzzhyk/markdown-pics/raw/master/img/20200918140329.png
[image-20200820233855600]: /images/20221123/99253d533d9d48ec80a102d032e2b838.png
[image-20200821221356690]: /images/20221123/1cf445d777934f38a74091bc0cf0969f.png
[image-20200821223325758]: /images/20221123/32f2675770cf47438fc159f27673e839.png