图解JVM内存模型和JVM线程模型

╰半橙微兮° 2023-09-28 16:13 53阅读 0赞

各位亲爱的读者朋友，我正在创作 Java多线程系列 文章，严格的说，JVM内存模型的知识并不隶属于Java多线程范畴，但在讨论多线程的过程中，会涉及到相关概念，考虑到它作为 面试常客，故单独成篇进行知识梳理。

*在各种有意无意地渲染之下，环境中已经充斥着焦虑，我并不认为正经面试真的有必要考察这些，毕竟没有几个岗位是开发JVM的。本篇文章将尽最大努力做到容易记忆，帮助各位克服焦虑！*

在本篇中，将JVM内存模型以及JVM线程模型的关键知识，形成**凝练的图**、辅以文字，同读者一起 **回顾并掌握** 这些知识。

作者按：本篇按照自己有限的知识进行整理，**如有谬误，还请读者在评论区不吝指出**

先来看一张 **较为完整** 的图：

![df589ca36d374d37be42da5464bf9d2c.png][]

在右侧再补充GC部分后，就比较完整了。今天的文章中，类加载部分略去，GC部分略去。

*作者按：读者朋友们还是应当将这两部分吃透的，如果面试遇到，可以顺着图展开作答*

图中的 **Java栈** 又称为 **Java虚拟机栈** 、 **虚拟机栈** 、 **JVM栈** 等；**本地栈** 即 **本地方法栈**

## / **JVM内存模型** / ##

从上图中，我们将运行时数据区剥出来，形成下图，即JVM内存模型 **(内存区域)**：

![caeca2db39904a348f5cfa4586bb7949.png][]

在JVM1.8中，图中的 **方法区** 为 **元数据区**

在多线程背景下，我们应个景：

*  堆和方法区是 **线程共享** 的
 *  虚拟机栈、本地方法栈、程序计数器是 **线程隔离** 的

下面展开谈一谈这五个区域的作用。*以Java虚拟机规范为界，不讨论具体实现*

#### **方法区（JVM1.8为元数据区）：** ####

方法区的作用为：存放虚拟机加载的：类型信息，域（Field）信息，方法（Method）信息，常量，静态变量，即时编译器编译后的代码缓存  
值得注意的是，无法申请到内存时，将抛出 OutOfMemoryError  
方法区中存在运行时常量池，字面量、符号引用等存放入其中。  
在Hotspot的演变过程中：

*  Java6及之前：方法区存在永久代，保存有静态变量
 *  Java7：进行去永久代工作，虽然还保留着，但静态常量池，如字符串常量池，已经移动到堆中
 *  Java8：移除永久代，类型信息、域（Field）信息、方法（Method）信息存放在元数据区；字符串常量池、静态变量存放在堆区

#### **虚拟机栈：** ####

虚拟机栈中保存了 **每一次** **方法调用** 的信息。  
每个Java线程创建时，都会创建对应的 虚拟机栈 ，每一次方法调用，都会往栈中压入一个 栈帧。如下图：  
![f858adb4ce3a44e8982f52461a85e3b3.png][]  
而栈帧中，包含：

*  局部变量表：保存函数 （即方法） 的局部变量
 *  操作数栈：保存计算过程中的结果，即临时变量
 *  动态链接：指向方法区的运行时常量池。字节码中的 方法调用指令 以常量池中指向方法的 符号引用 为参数。
 *  方法的返回地址

#### **本地方法栈：** ####

和虚拟机栈功能上类似，它管理了native方法的一些执行细节，而虚拟机栈管理的是Java方法的执行细节。

#### **程序计数器：** ####

程序计数器记录线程执行的字节码行号，如果当前线程正在运行native方法则为空。也有称之为 PC寄存器  
字节码解释器在工作时，通过改变计数器的值来选取下一跳需要执行的字节码指令，分支 、 循环 、跳转 、 异常处理 、线程恢复 等基本功能都需要依赖计数器来完成。  
*Java虚拟机的多线程实现方式：通过 **轮流切换并分配处理器执行时间** 实现*  
所以，在任意确定的时间点，一个处理器只会处理一个线程中的指令。为了正确地处理 **线程切换后的任务恢复** ，每一个线程都具有自身的程序计数器

#### **堆：** ####

堆提供了类实例和数组的内存，可以按如下方式划分：  
![ab14300d3cdc4f4fad6eb720fcf9dc32.png][]  
如下图所示：  
  
划分和对象创建与GC有关

*  新生成的对象在Eden区
 *  触发 Minor GC后，还 "幸存" 的对象移动到S0
 *  再次触发Minor GC后，S0和Eden 中存活的对象被移动到S1中，S0清空
 *  每次移动时，自动递增计数器，超过默认值时 （印象中是16），移动到老年代，如果Eden中没有足够内存分配，也将直接在老年代中分配内存
 *  老年代中依靠Major GC

**小总结**  
将上文的知识点进行汇总后，我们可以得到一张新图：  
![48a5f17df3ba45628819d54f5f3b64ec.png][]

## / JVM线程模型 / ##

##  ##

一个Java线程的实现方式可以有三种：

*  使用内核线程实现
 *  使用用户线程实现
 *  使用用户线程加轻量级进程混合实现

印象中JVM没有规定线程实现的规范，具体研究需要结合具体的JVM实现，下面我们简单探索一下

#### **内核线程模型：** ####

内核线程模型: 完全依赖操作系统内核提供的内核线程（Kernel-Level Thread ，KLT）来实现多线程。这种方式下：线程的切换调度 由 系统内核 完成。  
一般而言，程序不会直接使用内核线程，而是使用一种 高级接口 即 轻量级进程（Light Weight Process,LWP）。  
![d2a714cc7da8478d823d80d58add9d6a.png][]  
用户进程中，通过 LWP 使用系统的 内核线程 。由于其一对一的关系，又称为 一对一模型  
由于 用户线程 与 LWP 一一对应，LWP 是独立的调度单元，因此某个LWP在 **用户进程调用过程中** 发生阻塞，以及在 **系统调用中** 发生了阻塞，都不会影响整个进程的执行。  
但是LWP依托内核线程，所以 **线程操作** 需要 **依赖系统调用** ，代价是较高的，需要在 用户态（User Mode） 和 内核态（Kernel Mode） 中来回切换；而且每个 LWP 都需要一个 内核线程 进行支持，因此 LWP 要消耗一定的内核资源，因此一个系统仅可支持 **少量有限** 的 LWP。

#### **用户线程模型：** ####

排除掉 内核线程 ，JVM平台也可以实现 用户线程 User Thread 下文简称 UT ，完全自行实现创建、调度、销毁。  
区别于内核线程模型，此时线程的调度不再依赖内核，极少占据内核资源，基本限定在用户态内，所以可以突破量的限制，并且减少线程切换时的损耗。  
这样看起来似乎很美好，但难以利用多核CPU的优势，并且一旦产生系统调用发生中断，其他线程也将被中断。  
这种 多对一模型 的实用性较低。  
![9baead5e96944f05b06b478cd21f8baa.png][]

#### **混合模型：** ####

又称 多对多模型 ，这种方式充分利用了上面两种方式的优点。  
![b5b73cdbacbd47bc866de4b5a932b31b.png][]  
这种模型中，既存在UT，也存在LWP。

创建、切换线程(UT)依旧是廉价的，并且可以拥有大量的线程；同时利用 LWP作为UT到KLT（内核线程）的桥梁， 享受了系统内核的线程调度、CPU映射，免去了自行实现系统调用的部分，进行系统调用时，阻塞整个进程的概率也低于 用户线程模型 。

[df589ca36d374d37be42da5464bf9d2c.png]: https://img-blog.csdnimg.cn/df589ca36d374d37be42da5464bf9d2c.png
[caeca2db39904a348f5cfa4586bb7949.png]: https://img-blog.csdnimg.cn/caeca2db39904a348f5cfa4586bb7949.png
[f858adb4ce3a44e8982f52461a85e3b3.png]: https://img-blog.csdnimg.cn/f858adb4ce3a44e8982f52461a85e3b3.png
[ab14300d3cdc4f4fad6eb720fcf9dc32.png]: https://img-blog.csdnimg.cn/ab14300d3cdc4f4fad6eb720fcf9dc32.png
[48a5f17df3ba45628819d54f5f3b64ec.png]: https://img-blog.csdnimg.cn/48a5f17df3ba45628819d54f5f3b64ec.png
[d2a714cc7da8478d823d80d58add9d6a.png]: https://img-blog.csdnimg.cn/d2a714cc7da8478d823d80d58add9d6a.png
[9baead5e96944f05b06b478cd21f8baa.png]: https://img-blog.csdnimg.cn/9baead5e96944f05b06b478cd21f8baa.png
[b5b73cdbacbd47bc866de4b5a932b31b.png]: https://img-blog.csdnimg.cn/b5b73cdbacbd47bc866de4b5a932b31b.png