jvm内存说明（自己整理）

阳光穿透心脏的1/2处 2023-10-05 14:58 29阅读 0赞

JVM的逻辑内存模型

![jvm内存模型详解记录][jvm]

JVM在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而存在，有些区域则是依赖用户线程的启动和结束而建立和销毁。具体如下图所示：

![jvm内存模型详解记录][jvm 1]

## 1、程序计数器（Program Counter Register） ##

首先我们要搞清楚JVM的多线程实现方式。JVM的多线程是**通过CPU时间片轮转（即线程轮流切换并分配处理器执行时间）算法**来实现的。也就是说，某个线程在执行过程中可能会因为时间片耗尽而被挂起，而另一个线程获取到时间片开始执行。当被挂起的线程重新获取到时间片的时候，它要想从被挂起的地方继续执行，就必须知道它上次执行到哪个位置，在JVM中，通过**程序计数器来****记录某个线程的字节码执行位置**。

程序计数器是一块比较小的内存空间，可以看作是**当前线程所执行的字节码的行号指示器**。在虚拟机概念模型中，字节码解释器 工作时就是通过改变计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能 都需要依赖 程序计数器来完成。

程序计数器是一块 **线程私有** 的内存，每个线程都有一个独立的程序计数器，各线程间的计数器互不影响，独立存储。这样设计使多线程环境下，线程切换后能恢复到正确的执行位置。

**特点**

> 1.线程隔离性，每个线程工作时都有属于自己的独立计数器。
> 
> 2.**执行java方法时**，程序计数器是有值的，且**记录的是正在执行的字节码指令的地址**。
> 
> 3.**执行native本地方法**时，程序计数器的值为空（Undefined）。因为native方法是java通过JNI直接调用本地C/C++库，可以近似的认为native方法相当于C/C++暴露给java的一个接口，java通过调用这个接口从而调用到C/C++方法。由于该方法是通过C/C++而不是java进行实现。那么自然无法产生相应的字节码，并且C/C++执行时的内存分配是由自己语言决定的，而不是由JVM决定的。
> 
> 4.程序计数器占用内存很小，在进行JVM内存计算时，可以忽略不计。
> 
> 5.程序计数器，是唯一一个在java虚拟机规范中没有规定任何OutOfMemoryError的区域。

## ![jvm内存模型详解记录][jvm 2] ##

## 2、Java虚拟机栈（Java Virtual Machine Stacks） ##

**虚拟机栈**是 **线程私有**的内存区域。它描述的是java方法执行的内存模型：

**每个方法在执行的同时，都会创建一个 栈帧（Stack Frame**），**栈帧中存储**着局部变量表、操作数栈、动态链接、方法出口 等信息。每个方法从调用直到执行完成的过程，会对应一个栈帧在虚拟机栈中入栈到出栈过程。每个方法从调用直至完成的过程，都对应着一个栈帧从入栈到出栈的过程。每当**一个方法执行完成时，该栈帧就会弹出栈帧的元素作为这个方法的返回值**，并且清除这个栈帧，Java栈的栈顶的栈帧就是当前正在执行的活动栈，也就是当前正在执行的方法。就像是组成动画的一帧一帧的图片，方法的调用过程也是由栈帧切换来产生结果。

**局部变量表**中存放了编译期可知的各种：

*  基本数据类型(boolen、byte、char、short、int、 float、 long、double）
 *  对象引用（reference类型，它不等于对象本身，可能是一个指向对象起始地址的指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）
 *  returnAddress类型（指向了一条字节码指令的地址）

> **局部变量表所需的****内存空间在编译期间完成分配**，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。

**操作数栈**：存放调用过程中的计算结果的临时存放区域。

**帧数据区**：存放的是异常处理表和函数的返回，访问常量池的指针。

**垃圾回收**：程序自动出栈释放。

函数的调用有完美的嵌套关系--调用者的生命期总是长于被调用者的生命期，并且后者在前者之内，这样被调用者的局部信息所占空间的分配总是后于调用者的（后入栈），而其释放则总是先于调用者（先出栈），所以正好尅满足栈的**LIFO**（**last in first out**）顺序。

在JVM规范中，对这个区域规定了两种异常状况：

*  **StackOverflowError**：线程请求的栈深度大于虚拟机所允许的深度，将会抛出此异常。
 *  **OutOfMemoryError**：当可动态扩展的虚拟机栈在扩展时无法申请到足够的内存，就会抛出该异常。

## 3、本地方法栈（Native Method Stack） ##

本地方法是由其它语言编写的，编译成和处理器相关的机器代码

本地方法保存在动态链接库中，即.dll(windows系统)文件中，格式是各个平台专有的

拓展：JAVA方法是由JAVA编写的，编译成字节码，存储在class文件中

> java使用起来非常方便，然而有些层次的任务用java实现起来不容易，或者我们对程序的效率很在意时，问题就来了。
> 
> **与java环境外交互**：
> 
> 有时java应用需要与java外面的环境交互。这是本地方法存在的主要原因，你可以想想java需要与一些底层系统如操作系统或某些硬件交换信息时的情况。本地方法正是这样一种交流机制：它为我们提供了一个非常简洁的接口，而且我们无需去了解java应用之外的繁琐的细节。
> 
> **与操作系统交互**：
> 
> JVM支持着java语言本身和运行时库，它是java程序赖以生存的平台，它由一个解释器（解释字节码）和一些连接到本地代码的库组成。然而不管怎样，它毕竟不是一个完整的系统，它经常依赖于一些底层（underneath在下面的）系统的支持。这些底层系统常常是强大的操作系统。通过使用本地方法，我们得以用java实现了jre的与底层系统的交互，甚至JVM的一些部分就是用C写的，还有，如果我们要使用一些java语言本身没有提供封装的操作系统的特性时，我们也需要使用本地方法。

**DLL的加载是通过调用System.loadLibrary(String filename)或System.load(String filename)方法实现的。**

#### 4、Java堆（Heap） ####

对于大多数应用而言，**堆**（Heap）是虚拟机所管理的**内存中最大的一块**，它被所有线程共享的，在虚拟机启动时创建。

>  *  此内存区域唯一的目的是**存放对象实例**，几乎所有的对象实例都在这里分配内存，且每次分配的空间是不定长的。
>  *  在Heap 中分配一定的内存来保存对象实例，**实际上只是保存对象实例的属性值，属性的类型和对象本身的类型标记等**，并**不保存对象的方法（方法是指令，保存在Stack中）**,在Heap 中分配一定的内存保存对象实例和对象的序列化比较类似。对象实例在Heap 中分配好以后，需要**在Stack中保存一个4字节的Heap 内存地址**，用来定位该对象实例在Heap 中的位置，便于找到该对象实例。

Java虚拟机规范中描述道：所有的对象实例以及数组都要在堆上分配，但是随着JIT编译器的发展和逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化发生，所有的对象都在堆上分配的定论也并不“绝对”了。

Java**堆**是**垃圾收集器管理的主要区域**，因此也被称为“GC堆（Garbage Collected Heap）”。从内存回收的角度看内存空间可如下划分：

![v2-3a19c0a39e4ff3be23f355007bb4b2b6\_hd.jpg][v2-3a19c0a39e4ff3be23f355007bb4b2b6_hd.jpg]

>  *  新生代（Young）： 新生成的对象优先存放在新生代中，新生代对象朝生夕死，存活率很低。在新生代中，常规应用进行一次垃圾收集一般可以回收70% ~ 95% 的空间，回收效率很高。新生代又可细分为Eden空间、From Survivor空间、To Survivor空间，默认比例为8:1:1。
>  *  老年代（Tenured/Old）：在新生代中经历了多次（具体看虚拟机配置的阀值）GC后仍然存活下来的对象会进入老年代中。老年代中的对象生命周期较长，存活率比较高，在老年代中进行GC的频率相对而言较低，而且回收的速度也比较慢。
>  *  永久代（Perm）：永久代存储类信息、常量、静态变量、即时编译器编译后的代码等数据，对这一区域而言，Java虚拟机规范指出可以不进行垃圾收集，一般而言不会进行垃圾回收。
> 
> [垃圾回收机制][Link 1]

其中新生代和老年代组成了Java堆的全部内存区域，而永久代不属于堆空间，它在JDK 1.8以前被Sun HotSpot虚拟机用作方法区的实现。

## 5、方法区（Method Area） ##

与Java堆一样，是所有线程共享的内存区域。Object Class Data(类定义数据)是存储在方法区的，此外，常量、静态变量、JIT编译后的代码也存储在方法区。正因为方法区所存储的数据与堆有一种类比关系，所以它还被称为 Non-Heap。

方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，虚拟机同样会抛出内存溢出的错误。

jdk1.6和jdk1.7方法区可以理解为永久区。

jdk1.8已经将方法区取消，替代的是元数据区。

jdk1.8的**元数据区**可以使用参数-XX:MaxMetaspaceSzie设定大小，这**是一块堆外的直接内存**，与永久区不同，如果不指定大小，默认情况下，虚拟机会耗尽可用系统内存

## 6、其他拓展 ##

**运行时常量池**

> 运行时常量池（Runtime Constant Pool），它是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述等信息外，还有一项信息是**常量池**（Constant Pool Table），用于存放编译期生成的各种**字面量**和**符号引用**，这部分内容将在类加载后存放到常量池中。
> 
> 运行时常量是相对于常量来说的，它具备一个重要特征是：动态性。当然，值相同的动态常量与我们通常说的常量只是来源不同，但是都是储存在池内同一块内存区域。Java语言并不要求常量一定只能在编译期产生，运行期间也可能产生新的常量，这些常量被放在运行时常量池中。这里所说的常量包括：基本类型包装类（包装类不管理浮点型，整形只会管理-128到127）和String（也可以通过String.intern()方法可以强制将String放入常量池）
> 
> [常量池相关说明][Link 2]

**直接内存**

> 直接内存（Direct Memory）就是**Java堆外内存**
> 
> 在JDK 1.4中新加入了NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。
> 
> 显然，本机直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，则肯定还是会受到本机总内存（包括RAM及SWAP区或者分页文件）的大小及处理器寻址空间的限制。服务器管理员配置虚拟机参数时，一般会根据实际内存设置-Xmx等参数信息，但经常会忽略掉直接内存，使得各个内存区域的总和大于物理内存限制（包括物理上的和操作系统级的限制），从而导致动态扩展时出现OutOfMemoryError异常。

## **7、总结：** ##

![jvm内存模型详解记录][jvm 3]

参考文章：

深入理解JVM，7种垃圾收集器：[深入理解JVM，7种垃圾收集器\_Java架构笔记的技术博客\_51CTO博客][Link 1]

彻底弄懂java中的常量池：[彻底弄懂java中的常量池 - 腾讯云开发者社区-腾讯云][Link 2]

[jvm]: https://img-blog.csdnimg.cn/img_convert/ebc56de8357abbfff54b325cc1e945ec.png
[jvm 1]: https://img-blog.csdnimg.cn/img_convert/93d4174afdf1adc7411633b8b2ec51d2.png
[jvm 2]: https://img-blog.csdnimg.cn/img_convert/bab8ac655756bf52db02bb8bd19fe1b5.png
[v2-3a19c0a39e4ff3be23f355007bb4b2b6_hd.jpg]: https://img-blog.csdnimg.cn/img_convert/2bc5b0ec85ff3794dc781c7a1282b01a.png
[Link 1]: https://blog.51cto.com/14440216/2437701
[Link 2]: https://cloud.tencent.com/developer/article/1450501
[jvm 3]: https://img-blog.csdnimg.cn/img_convert/bc758ee00780fa18f780f42db38a98c4.png