JVM内存模型

1. 前言

内存是非常重要的系统资源，是硬盘和CPU的中间仓库及桥梁。任何程序都需要加载到内存才能与CPU进行交流。

JVM内存布局规定了Java在运行过程中内存申请、分配、管理的策略，保证了JVM的高效稳定运行。

JVM 的内存布局：

2. 程序计数存储器（Program Counter Register ）

Register 的命名源于CPU的寄存器，CPU只有把数据装载到寄存器才能够运行 寄存器存储指令相关的现场信息。

由于CPU时间片轮限制，众多线程在并发执行过程中，任何一个确定的时刻，一个处理器或者多核处理器中的一个内核，只会执行某个线程中的一条指令。这样必然导致经常中断或恢复。

每个线程在创建后，都会产生自己的程序计数器和栈帧，程序计数器用来存放执行指令的偏移量和行号指示器等，线程执行或恢复都要依赖程序计数器。

程序计数器在各个线程之间互不影。此区域也不会发生内存溢出异常。

2.1 定义

程序计数器是一块较小的内存空间，可看作当前线程正在执行的字节码的行号指示器 如果当前线程正在执行的是 java方法，计数器记录的就是当前线程正在执行的字节码指令的地址。如果执行的是本地方法，计数器的值为undefined。

2.2 作用

程序计数器有两个作用

• 字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。
• 在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。

3.Java虚拟机栈(JVM Stack)

JVM 中的虚拟机栈是描述Java方法执行的内存区域。是线程私有的。

栈中的元素用于支持虚拟机进行方法调用的，每个方法从开始调用到执行王城的过程，就是栈帧从入栈到出栈的过程。

栈帧是方法运行的基本机构。

在执行引擎运行时，所有指令都只能争对当前栈帧（活动线程中位于栈顶的栈帧）进行操作。

虚拟机栈通过压/出栈的方式，对每个方法对应的活动栈帧进行运算处理。方法正常执行结束后，栈帧出栈，接着执行下一个栈帧。

在执行的过程中，如果出现异常，会进行异常回溯，返回地址通过异常处理表确定 栈帧在整个JVM体系中的地位颇高,包括局部变量表、操作栈、动态连接、方法返回地址等。

3.1 栈帧结构

3.1.1 局部变量表

存放方法参数和局部变量。 相对于类属性变量的准备阶段和初始化阶段来说，局部变量没有准备阶段，必须显式初始化。如果是非静态方法，则在index[0]位置上存储的是方法所属对象的实例引用，随后存储的是参数和局部变量 。字节码指令中的STORE指令就是将操作栈中计算完成的局部变量写回局部变量表的存储空间内。

局部变量表的创建是在方法被执行的时候,随着栈帧的创建而创建. 而且表的大小在编译期就确定,在创建的时候只需分配事先规定好的大小即可. 在方法运行过程中,表的大小不会改变

3.1.2 操作栈

操作栈是一个初始状态为空的桶式结构，在方法执行的过程中，会有各种指令往栈中写入和提取信息。
JVM 执行引擎是基于栈的执行引擎，其中的栈值得就是操作栈。字节码指令集的定义都是基于栈类型的，栈的深度在方法元信息的stack属性中。

public class simple {
    public int simpleMethod(){
        int x=13;
        int y=14;
        int z= x + y;
        return z;
    }
}

详细的字节码操作顺序：

Classfile /D:/temp/java_class/simple.class
  Last modified 2021-10-13; size 278 bytes
  MD5 checksum e258ecfd482fafa1384a6b5fce5e9fe0
  Compiled from "simple.java"
public class com.hope.simple
  minor version: 0
  major version: 52
  flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
   #1 = Methodref          #3.#12         // java/lang/Object."<init>":()V
   #2 = Class              #13            // com/hope/simple
   #3 = Class              #14            // java/lang/Object
   #4 = Utf8               <init>
   #5 = Utf8               ()V
   #6 = Utf8               Code
   #7 = Utf8               LineNumberTable
   #8 = Utf8               simpleMethod
   #9 = Utf8               ()I
  #10 = Utf8               SourceFile
  #11 = Utf8               simple.java
  #12 = NameAndType        #4:#5          // "<init>":()V
  #13 = Utf8               com/hope/simple
  #14 = Utf8               java/lang/Object
{
  public com.hope.simple();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 3: 0

  public int simpleMethod();
    descriptor: ()I
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=4, args_size=1  // 最大深度为2 局部变量个数为4
         0: bipush        13  // 常量13压入操作栈
         2: istore_1		  // 并保存到局部变量表的slot_1中(第一处)
         3: bipush        14  // 常量14压入操作栈
         5: istore_2          // 并保存到局部变量表的slot_2中
         6: iload_1			  // 把局部变量表slot_1 元素(int x)压入操作栈
         7: iload_2 		  // 把局部变量表slot_2 元素(int y) 压入操作栈
         8: iadd			  // 把上方的两个数都取出来，在CPU相加，并压会操作栈的栈顶
         9: istore_3 		  // 把栈顶的结果存储到局部变量表solt_3 中
        10: iload_3
        11: ireturn			  // 返回栈顶元素
      LineNumberTable:
        line 5: 0
        line 6: 3
        line 7: 6
        line 8: 10
}
SourceFile: "simple.java"

局部变量表就像个中药柜，里面有很多抽屉,依次编号为0, 1, 2,3，.,. n 字节码指令istore_ 1就是打开1号抽屉，把栈顶中的数13存进去 栈是一个很深的竖桶，任何时候只能对桶口元素进行操作，所以数据只能在栈顶进行存取。

某些指令可以直接在抽屉中进行。比如inc 指令，直接对抽屉里的数值进行+1 操作。

从字节码上对比 i++ 和 ++i 的区别。

a=i++	a=++i
0:iload_1 // 从局部变量表中取出第一个数，压入栈顶	0: iinc 1,1 // 在抽屉实现 +1 c操作
1: iinc 1,1 // 在抽屉+1 ,操作栈栈顶数值不变	3: iload_1 // 去除变量表中数据，压入栈顶
4:istore_2 // 将栈顶数值赋值给变量a	4:istore_2 // 栈顶数据赋值给 变量a

• iload_ 1 从局部变量表的第1号抽屉里取出一个数,压入栈顶，下一步直接在抽屉里实现+1的操作，而这个操作对栈顶元素的值没有影响 所以istore_ 2只是把栈顶元素赋值给a
• 表格右列，先在第1号抽屉里执行+1操作，然后通过iload_ 1 把第1号抽屉里的数压入栈顶，所以istore_ 2存入的是+1之后的值

i++并非原子操作。即使通过volatile关键字进行修饰，多个线程同时写的话，也会产生数据互相覆盖的问题.

3.1.3 动态链接

每个栈帧中包含一个在常量池中对当前方法的引用，目的是支持方法调用过程的动态连接

3.1.4 方法返回地址

方法正常退出的两种情况：

• 正常退出： 正常执行到任何方法的返回字节码指令，如RETURN、IRETURN、ARETURN等
• 异常退出

无论何种退出情况，都将返回至方法当前被调用的位置。方法退出的过程相当于弹出当前栈帧

退出可能有三种方式:

• 返回值压入，上层调用栈帧
• 异常信息抛给能够处理的栈帧
• PC计数器指向方法调用后的下一条指令

4. 本地方法栈（Native Method Stack）

本地方法栈和Java虚拟机栈实现的功能与抛出异常几乎相同 只不过虚拟机栈是为虚拟机执行Java方法(也就是字节码)服务,本地方法区则为虚拟机使用到的Native方法服务.

在JVM内存布局中，也是线程对象私有的,但是虚拟机栈“主内”，而本地方法栈“主外” 这个“内外”是针对JVM来说的，本地方法栈为Native方法服务 线程开始调用本地方法时，会进入一个不再受JVM约束的世界 本地方法可以通过JNI(Java Native Interface)来访问虚拟机运行时的数据区，甚至可以调用寄存器,具有和JVM相同的能力和权限 当大量本地方法出现时,势必会削弱JVM对系统的控制力,因为它的出错信息都比较黑盒. 对于内存不足的情况，本地方法栈还是会拋出native heap OutOfMemory

最著名的本地方法应该是System.currentTimeMillis()，JNI 使Java深度使用OS的特性功能，复用非Java代码 但是在项目过程中，如果大量使用其他语言来实现JNI,就会丧失跨平台特性，威胁到程序运行的稳定性 假如需要与本地代码交互，就可以用中间标准框架进行解耦，这样即使本地方法崩溃也不至于影响到JVM的稳定 当然，如果要求极高的执行效率、偏底层的跨进程操作等，可以考虑设计为JNI调用方式

5. Java堆(Java Heap)

Heap是OOM(Outofmemory)故障最主要的发源地，它存储着几乎所有的实例对象。
堆由垃圾收集器自动回收，堆区由各子线程共享使用 通常情况下，它占用的空间是所有内存区域中最大的，但如果无节制地创建大量对象，也容易消耗完所有的空间 堆的内存空间既可以固定大小，也可运行时动态地调整，通过如下参数设定初始值和最大值，比如

-Xms256M. -Xmx1024M
其中-X表示它是JVM运行参数

• ms是memorystart的简称 最小堆容量
• mx是memory max的简称 最大堆容量

但是在通常情况下，服务器在运行过程中，堆空间不断地扩容与回缩，势必形成不必要的系统压力，所以在线上生产环境中，JVM的Xms和Xmx设置成一样大小，避免在GC后调整堆大小时带来的额外压力。

堆分成两大块:新生代和老年代 对象产生之初在新生代，步入暮年时进入老年代，但是老年代也接纳在新生代无法容纳的超大对象

新生代= 1个Eden区+ 2个Survivor区
绝大部分对象在Eden 区生成，当Eden区装填满的时候，会触发Young GC。

垃圾回收的时候，在Eden区实现清除策略，没有被引用的对象则直接回收。
依然存活的对象会被移送到Survivor区。

Survivor 区分为S0和S1两块内存空间，每次Young GC的时候，将存活的对象复制到未使用的那块空间，然后将当前正在使用的空间完全清除，交换两块空间的使用状态。

每个对象都有一个计数器，每次YGC都会加1。

如果YGC要移送的对象大于Survivor区容量上限，则直接移交给老年代。

-XX:MaxTenuringThreshold 能配置计数器的值到达某个阈值的时候，对象从新生代晋升至老年代。默认值是15，可以在Survivor 区交换14次之后，晋升至老年代。

若Survivor区无法放下，或者超大对象的阈值超过上限，则尝试在老年代中进行分配; 如果老年代也无法放下，则会触发Full Garbage Collection(Full GC); 如果依然无法放下，则抛OOM.

堆出现OOM的概率是所有内存耗尽异常中最高的 出错时的堆内信息对解决问题非常有帮助，所以给JVM设置运行参数-
XX:+HeapDumpOnOutOfMemoryError
让JVM遇到OOM异常时能输出堆内信息

堆存放的所有示例对象中， 除了实例数据，还保存了对象的其他信息，如Mark Word（存储对象哈希码，GC标志，GC年龄，同步锁等信息），Klass Pointy(指向存储类型元数据的指针）及一些字节对齐补白的填充数据（若实例数据刚好满足8字节对齐，则可不存在补白）

6. 方法区

6.1 定义

Java虚拟机规范中定义方法区是堆的一个逻辑部分,但是别名Non-Heap(非堆),以与Java堆区分. 方法区中存放已经被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据.

6.2 特点

• 线程共享 方法区是堆的一个逻辑部分,因此和堆一样,都是线程共享的.整个虚拟机中只有一个方法区.
• 永久代 方法区中的信息一般需要长期存在，而且它又是堆的逻辑分区，因此用堆的划分方法，我们把方法区称为永久代.
• 内存回收效率低 Java虚拟机规范对方法区的要求比较宽松,可以不实现垃圾收集. 方法区中的信息一般需要长期存在,回收一遍内存之后可能只有少量信息无效. 对方法区的内存回收的主要目标是:对常量池的回收和对类型的卸载

6.3 运行时常量池(Runtime Constant Pool)

运行时常量池是方法区的一部分. 方法区中存放三种数据：类信息、常量、静态变量、即时编译器编译后的代码.其中常量存储在运行时常量池中.

java文件被编译之后生成的.class文件中除了包含：类的版本、字段、方法、接口等信息外，还有一项就是常量池 常量池中存放编译时期产生的各种字面量和符号引用。
.class文件中的常量池中的所有的内容在类被加载后存放到方法区的运行时常量池中。PS：int age = 21;//age是一个变量，可以被赋值；21就是一个字面值常量，不能被赋值； int final pai = 3.14;//pai就是一个符号常量，一旦被赋值之后就不能被修改。

Class文件中除了有类的版本、字段、方法、接口等描述信息外,还有一项信息是常量池( Constant pool table)，用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入运行时常量池中存放。运行时常量池相对于class文件常量池的另外一个特性是具备动态性，java语言并不要求常量一定只有编译器才产生，也就是并非预置入class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中。

7. 直接内存 (Direct Memory)

直接内存不是虚拟机运行时数据区的一部分,也不是JVM规范中定义的内存区域,但在JVM的实际运行过程中会频繁地使用这块区域.而且也会抛OOM

在JDK 1.4中加入了NIO(New Input／Output)类,引入了一种基于管道和缓冲区的IO方式,它可以使用Native函数库直接分配堆外内存,然后通过一个存储在堆里的DirectByteBuffer对象作为这块内存的引用来操作堆外内存中的数据. 这样能在一些场景中显著提升性能,因为避免了在Java堆和Native堆中来回复制数据.

8. Metaspace (元空间)

在JDK8，元空间的前身Perm区已经被淘汰,在JDK7及之前的版本中，只有Hotspot才有Perm区(永久代),它在启动时固定大小,很难进行调优,并且Full GC时会移动类元信息

在某些场景下,如果动态加载类过多,容易产生Perm区的OOM. 比如某个实际Web工程中，因为功能点比较多，在运行过程中，要不断动态加载很多的类，经常出现致命错误:

Exception in thread ‘dubbo client x.x connector’ java.lang.OutOfMemoryError: PermGenspac
为解决该问题，需要设定运行参数

-XX:MaxPermSize= l280m
如果部署到新机器上，往往会因为JVM参数没有修改导致故障再现。不熟悉此应用的人排查问题时往往苦不堪言，除此之外，永久代在GC过程中还存在诸多问题

所以，JDK8使用元空间替换永久代.区别于永久代，元空间在本地内存中分配. 也就是说，只要本地内存足够，它不会出现像永久代中java.lang.OutOfMemoryError: PermGen space

同样的，对永久代的设置参数 PermSize 和MaxPermSize也会失效 在JDK8及以上版本中，设定MaxPermSize参数，JVM在启动时并不会报错，但是会提示:

Java HotSpot 64Bit Server VM warning:ignoring option MaxPermSize=2560m; support was removed in 8.0
默认情况下，“元空间”的大小可以动态调整，或者使用新参数MaxMetaspaceSize 来限制本地内存分配给类元数据的大小.

在JDK8里，Perm 区所有内容中

字符串常量移至堆内存
其他内容包括类元信息、字段、静态属性、方法、常量等都移动至元空间

8.1 元空间特色

• 充分利用了Java语言规范：类及相关的元数据的生命周期与类加载器的一致
• 每个类加载器都有它的内存区域-元空间
• 只进行线性分配
• 不会单独回收某个类（除了重定义类 RedefineClasses 或类加载失败）
• 没有GC扫描或压缩
• 元空间里的对象不会被转移
• 如果GC发现某个类加载器不再存活，会对整个元空间进行集体回收