JVM详解

朱雀 2024-03-23 21:23 63阅读 0赞

#### 文章目录 ####

*  一、JVM 执行流程
 *  二、类加载
 *  三、双亲委派模型
 *  四、垃圾回收机制（GC）

## 一、JVM 执行流程 ##

程序在执行之前先要把java代码转换成字节码（class文件），JVM 首先需要把字节码通过一定的方式 类加载器（ClassLoader） 把文件加载到内存中 运行时数据区（Runtime Data Area） ，而字节码 文件是 JVM 的一套指令集规范，并不能直接交个底层操作系统去执行，因此需要特定的命令解析器 执 行引擎（Execution Engine）将字节码翻译成底层系统指令再交由CPU去执行，而这个过程中需要调 用其他语言的接口本地库接口（NativeInterface） 来实现整个程序的功能，这就是这4个主要组成部分的职责与功能。  
![在这里插入图片描述][e88d9d62e9a94d649df6ef73ac38f05b.png]  
总结来看， JVM 主要通过分为以下 4 个部分，来执行 Java 程序的，它们分别是：

1.  类加载器（ClassLoader）
2.  运行时数据区（Runtime Data Area）
3.  执行引擎（Execution Engine）
4.  本地库接口（Native Interface）

**JVM 运行时数据区**  
VM 运行时数据区域也叫内存布局，但需要注意的是它和 Java 内存模型（(Java Memory Model，简称 JMM）完全不同，属于完全不同的两个概念，它由以下 5 大部分组成：  
![在这里插入图片描述][b844e8376c064b6184d8bbdeb7d4674a.png]

1.  Nartiye Method Stacks就表示是JVM内部的C++代码，就是给调用native方法（JVM内部方法）准备的栈空间。（也就是说C++根本不需要虚拟机的，他是直接把代码编译成native code,也就是cpu能识别的机器指令。但是java因为有跨平台需求，需要用jvm）
2.  JVM Stacks给java代码使用的栈  
    注意：  
    这里的栈和数据结构里面的栈并不是同一个意思，此处所说的栈，指代的就是JVM一块特殊的存储空间，对于JVM虚拟栈而言，是存储的就是方法与方法之间的调用关系。本地方法栈存储的就是native方法的调用关系。  
    整个栈空间内部，包含很多元素，一个元素称之为一个栈帧，一个栈帧里包含这个方法的入口地址、方法参数、返回地址、局部变量等  
    这个栈也是先进后出的，但是和数据结构里面的栈是更广泛通用的概念
3.  progarm counter pegister（程序计数器）这是记录当前执行到那一条指令
4.  堆是JVM中空间最大的区域，new出来的对象就是放在堆上的，类的成员变量也是放在堆上的，一个进程对应一份堆对应N个栈，而栈是每个线程都有独立的栈（一个进程对应一个虚拟机，两个进程就是两个JVM）
5.  元数据去（方法区）：主要是常量池，静态成员变量，类对象就存在这
6.  **判断某个变量在啥区域  
    局部变量在栈上  
    普通成员变量在堆上  
    静态成员变量在方法区（元数据区）**

## 二、类加载 ##

类加载简单理解就是.class文件，从文件（硬盘）被加载的内存中（元数据）这样的过程  
![在这里插入图片描述][f0106972553b4473b13ec89c68aa79c0.png]  
**1.加载**：  
1）通过一个类的全限定名来获取定义此类的二进制字节流。  
2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。  
3）在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。  
简单来说就是：把.class文件找到，打开文件，读取文件，把文件内容读到内存中。

**2.验证**：  
这一阶段的目的是确保Class文件的字节流中包含的信息符合java虚拟机规范

这里在说一下类对象实际究竟是什么  
![在这里插入图片描述][6438a52bfa19483ea5f3f9ee1b0e294a.png]  
这是java虚拟机规范里面标准的类对象结构，也就是说在我们java代码写好之后，点击运行，首先要做的就是将我们代码里面的定义类进行重新定义（书写）书写的格式就是按照这种类似（C++）结构体的方式去书写，这就是我们.class文件。  
![在这里插入图片描述][81ad3b0a917a4a818c389710d58ee595.png]注意.class文件和类对象是同一个东西的不同形态，类对象是我们描述内存里实际存储的对象，class文件是这个对象以文件的形式打开后呈现的样子。

**3.准备：**  
准备阶段是正式为类中定义的变量（即静态变量，被static修饰的变量）分配内存并设置类变量初始值 的阶段  
简单来说：给类对象分配内存空间（先在元数据占个位置），将静态成员变量赋值为0。

**4.解析：**  
针对字符串常量进行初始化（将符号引用转化为直接引用）。一个字符串常量得有一块内存空间，存这个字符的实际内容，还得有一个引用，来保存这个内存空间的起始地址。  
在类加载之前，字符串常量，此时处于.class文件中，此时这个引用记录的并不是字符串常量正在的地址，而是他在文件中的偏移量（或者说占位符，或者说符号引用）  
只有在类加载之后，才真的把这个字符常量放到内存中，才有了内存地址，这个引用才被真正的赋值成内存地址（直接引用）。  
（就像看电影之前我只知道自己相对位置，只有坐下来之后才知道自己的实际位置）

**5.初始化：**  
初始化阶段，Java 虚拟机真正开始执行类中编写的 Java 程序代码，将主导权移交给应用程序。初始化阶段就是执行类构造器方法的过程。（加载父类，执行静态代码块的代码等）

但是一个类啥时候会被加载，并不是java程序一运行就会加载，而是真正用到的时候才会去加载（懒汉模式）

常见的类加载时机

1.构造类的实例：new 了一个对象  
2.调用这个类的静态方法，使用静态属性（因为静态的都和类绑定在一起，只有类被加载了，静态属性才会赋值）  
3.如果加载一个子类，需要先加载其父类  
4.如果加载过，后续就不需要重新加载

还不太明白的同学可以去看这篇文章  
https://blog.csdn.net/Strange\_boy/article/details/125717606?ops\_request\_misc=%257B%2522request%255Fid%2522%253A%2522169200970816800226573234%2522%252C%2522scm%2522%253A%252220140713.130102334…%2522%257D&request\_id=169200970816800226573234&biz\_id=0&utm\_medium=distribute.pc\_search\_result.none-task-blog-2blogtop\_positive~default-1-125717606-null-null.268v1koosearch&utm\_term=%E7%B1%BB%E5%8A%A0%E8%BD%BD%E7%9A%84%E8%BF%87%E7%A8%8B&spm=1018.2226.3001.4450

## 三、双亲委派模型 ##

双亲委派模型描述的是在加载中找.class文件怎么去找的问题

JVM默认提供了三个类加载器  
BootstrapClassLoader：负责加载标准库中的类。(这是java规范要求提供哪些类，无论哪种jvm的实现，都会提供这些类)  
ExtensionClassLoader：负责加载JVM扩展库中的类（规范之外，由实现JVM厂商、组织提供的额外功能）  
ApplicationClassLoader:负责加载用户提供的第三方库、用户项目代码中的类  
三种构成父子关系，这个并不是说父类子类的那种继承关系，单纯只是比如说ApplicationClassLoader有一个parent引用指向ExtensionClassLoader  
![在这里插入图片描述][d975d6de612f42259539225833ce3cf3.png]  
![在这里插入图片描述][12d40abe47ed40008ad7c480f46b5a9b.png]

上述类是如何配合工作的呢？

首先加载一个类的时候，先从ApplicationClassLoader开始，但是他并不是真加载，而是委托给自己的父亲ExtensionClassLoader去加载，但是ExtensionClassLoader也委托给自己的父亲去加载BootstrapClassLoader,当BootstrapClassLoader发现没有上层了，那么就开始自己加载，去所有自己的标准库目录里面的类，如果找到就加载，如果没找到，就有子类加载进行加载。ExtensionClassLoader也是一样，最后才是ApplicationClassLoader加载用户定义的类。在ApplicationClassLoader加载完如果还有类没有加载，那么ApplicationClassLoader下面也没有子类了就会抛出异常。

之所以这样安排，是因为JVM实现这个功能的逻辑是用递归写的，目的是为了防止用户创建了一些奇怪的类，比如说用户写了个java.lang.String类，这样就保证JVM先加载的一定是JVM标准库里的java.lang.String类，而不是用户自定义的这个。这样就保证起码标准库和三方库的类不会加载错误，所以最多也就是用户自己定义的类加载错误。

## 四、垃圾回收机制（GC） ##

垃圾回收机制就是帮我们回收不再使用的内存。

在C或者C++中，我们new或者malloc一块空间，实际上是在堆上申请了一块内存空间（JAVA类似），堆上申请和栈上申请是不同的，因为堆申请的内存空间，必须手动释放（C++用free 或者delete）,但是栈实际上方法执行结束了就自动释放了。堆的这个特性在个人电脑上可能没有太大影响，随着进程结束，堆的空间即使没回收也会回收。但是如果是服务器就需要考虑这个问题了，因为服务器的进程是一直存活的，会运行很长时间，如果我们用完堆不及时回收的话，可能会导致剩余空间越来越少。

GC运行虽然很省心，可以帮我们自动回收一些不用的空间，但是GC也会带来更大的系统开销，对程序的执行效率肯定是会有影响的。因为C++追求极致的性能，所以并不引入GC机制

注意我们在之前的编程中比如说释放scanner 释放statement,这些不是释放内存，而是释放文件。

所以通过上面的背景我们知道**GC是针对堆中的数据进行垃圾回收，GC是以对象为基本单位进行回收的，而不是字节等**这样设定的目的就是为了简单。

**GC实际工作过程**

**1.找到垃圾、判定垃圾**  
关键思路  
抓住这个对象，看他到底有没有“引用”指向他。  
如果一个对象有引用，那么就有可能被使用但是如果么有引用，那么就一定不会再被使用了。  
那么怎么去做就能判断对象是不是被引用了呢？

1.  引用计数（这不是java的做法，而是python/php的方式）  
    给对象增加一个引用计数器，每当有一个地方引用它时，计数器就+1；当引用失效时，计数器就-1；任何时刻计数器为0的对象就是不能再被使用的，即对象已"死"。引用计数法实现简单，判定效率也比较高。  
    但是这个方法的缺点在于内存空间浪费的空间是比较大的。在主流的JVM中没有选用引用计数法来管理内存，最主要的原因就是引用计数法无法解决对象的循环引用问题。
2.  可达性分析  
    java中的对象，都是通过引用来指向并访问的  
    一般是一个引用指向一个对象，这个对象里的成员，又指向别的对象。  
    实际上整个java中的对象都是通过这样的链式或者树形结构给串起来的。  
    可达性分析就是把所有这些对象组织的结构看做树，从根节点区去遍历，所有能被访问到的对象，标记为可达，不能可达的就会作为垃圾进行回收。  
    上述操作类似与树遍历，这种操作相对于计数来说，效率上会慢一点，但是会解决循环引用问题，此外，这个可达性分析不是每时每刻都需要做，隔一段时间分析一下就可以了。  
    可达性遍历的起点（一个代码中可能由多个起点）可能是：  
    1.栈上的局部变量，  
    2.常量池中的对象，  
    3.静态变量。

**如何清除垃圾**

**标记清除**  
"标记-清除"算法是最基础的收集算法。算法分为"标记"和"清除"两个阶段 : 首先标记出所有需要回收的 对象，在标记完成后统一回收所有被标记的对象。后续的收集算法都是基于这种思路并对其不足加以改进而已。  
标记-清除"算法的不足主要有两个 :

1.  效率问题 : 标记和清除这两个过程的效率都不高
2.  空间问题 : 标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行中  
    需要分配较大对象时，无法找到足够连续内存而不得不提前触发另一次圾收集。

**复制算法**  
"复制"算法是为了解决"标记-清理"的效率问题。它将可用内存按容量划分为大小相等的两块，每次只使 用其中的一块。当这块内存需要进行垃圾回收时，会将此区域还存活着的对象复制到另一块上面，然后 再把已经使用过的内存区域一次清理掉。这样做的好处是每次都是对整个半区进行内存回收，内存分配 时也就不需要考虑内存碎片等复杂情况，只需要移动堆顶指针，按顺序分配即可。此算法实现简单，运 行高效。算法的执行流程如下图 :  
![在这里插入图片描述][c3c893ee16984167ab91337d077e36bb.png]

这样是解决了标记算法里面碎片空间的问题，但是也有缺点，就是空间利用率低，如果垃圾少，有效对象多，复制成本就会加大。

**3.整理标记**  
复制收集算法在对象存活率较高时会进行比较多的复制操作，效率会变低。因此在老年代一般不能使用 复制算法。  
针对老年代的特点，提出了一种称之为"标记-整理算法"。标记过程仍与"标记-清除"过程一致，但后续步 骤不是直接对可回收对象进行清理，而是让所有存活对象都向一端移动，然后直接清理掉端边界以外的内存。流程图如下:  
![在这里插入图片描述][69f907c9e1124527aafbde83b5fe2afd.png]  
但是这个做法效率也不高，如果搬运空间比较大，开销也还是比较大的。

**分代回收**  
基于上述，我们可以将垃圾回收分为不同的场景，不同场景使用不同的算法

**分代咋分的**  
实际就基于经验规律：如果一个东西，存在的时间比较长，那么大概率还会存在很长时间。这个经验会与java中的对象也是存在的（有相关的实验证明）所以可以根据对象生命周期的长短来使用不同的算法。  
此时我们对对象引入一个概念：对象的年龄，对象的年龄用GC扫过的轮次为基本单位，扫过一轮没有被销毁，就是一岁，扫过两轮没有被销毁，就是两岁。  
所以JVM按照对象的年龄将堆划分为多个区域

![在这里插入图片描述][23525ec4084d422bb2b66aeab7870fc5.png]  
刚刚new出来的放入伊甸区，年龄是0岁，经过一轮之后被放入幸存区。幸存区相对于伊甸区来说要小很多，这是因为大部分的对象都是朝生夕死的，生命周期是很短的。从伊甸区到幸存区用的就是复制算法，到了幸存区之后还是还是要接受周期性的GC考验，如果变成垃圾，就会被释放，如果不是垃圾，就拷贝到另外一个幸存区,这 两个幸存区同一时刻只会用一个，对象在一轮轮的GC扫描中在两个幸存区中来回拷贝，由于幸存区体积不大，此处空间浪费也可以接受。如果这个对象已经在两个幸存区中拷贝多次，就会进入老年代，针对老年代也会周期性的GC扫描，但频率会更低，如果老年代对象扫描为垃圾，就用标记整理的方式进行释放。

[e88d9d62e9a94d649df6ef73ac38f05b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/70c5b99a95794e27a444f31f9061dae5.png
[b844e8376c064b6184d8bbdeb7d4674a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/da1949cfdf6d494d82334887599d1058.png
[f0106972553b4473b13ec89c68aa79c0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/28eb969926bd4c70a099e5ec9ea8ebb0.png
[6438a52bfa19483ea5f3f9ee1b0e294a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/0ddbb73cc8b44dec8e9d0f1667dad8ed.png
[81ad3b0a917a4a818c389710d58ee595.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/66b37273ce1f4016847852e8b373a237.png
[d975d6de612f42259539225833ce3cf3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/83e4bf083edd486fa06c7f72b5520a84.png
[12d40abe47ed40008ad7c480f46b5a9b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/1315de78a0ae4f2ba60a9c445e2cdcf8.png
[c3c893ee16984167ab91337d077e36bb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/e3a51753b6114fd7be56fc2a22856e3f.png
[69f907c9e1124527aafbde83b5fe2afd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/e6a43ec671cc4d43b4e7791fb9744d1e.png
[23525ec4084d422bb2b66aeab7870fc5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/b65e79f6c9574efdba02a69073397d14.png