JVM 内存模型

/ Java / 没有评论 / 4225浏览

JVM内存模型

JVM 内存模型

内存是非常重要的系统资源，是硬盘和 CPU 的中间仓库及桥梁，承载着操作系统和应用程序的实时运行。 JVM内存布局规定了Java 在运行过程中内存申请、分配、管理的策略，保证了JVM 的高效稳定运行，不同的 JVM对于内存的划分方式和管理机制存在着部分差异，结合JVM虚拟机规范，来探讨经典的JVM内存布局。

202031916852-jvm-model

2020319161221-jvm-model-2

Program Counter Register (程序计数寄存器)

Register 的命名源于 CPU 的寄存器，CPU只有把数据装载到寄存器才能够运行。寄存器存储指令相关的现场信息，由于 CPU时间片轮限制，众多线程在并发执行过程中，任何一个确定的时刻，一个处理器或者多核处理器中的一个内核，只会执行某个线程中的一条指令。这样必然导致经常中断或恢复，如何保证分毫无差呢?

每个线程在创建后，都会产生自己的程序计数器和栈帧，程序计数器用来存放执行指令的偏移量和行号指示器等，线程执行或恢复都要依赖程序计数器。程序计数器在各个线程之间互不影响，此区域也不会发生内存溢出异常。

定义

程序计数器是一块较小的内存空间，可看作当前线程正在执行的字节码的行号指示器，如果当前线程正在执行的是：

作用

程序计数器有两个作用

特点

  1. 一块较小的内存空间
  2. 线程私有，每个线程都有一个独立的程序计数器。
  3. 是唯一一个不会出现 OOM的内存区域。
  4. 生命周期随着线程的创建而创建，随着线程的结束而死亡。

Java虚拟机栈(JVM Stack)

定义

相对于基于寄存器的运行环境来说，JVM 是基于栈结构的运行环境，栈结构移植性更好，可控性更强，JVM中的虚拟机栈是描述 Java方法执行的内存区域，它是线程私有的。

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

在活动线程中，只有位于栈顶的帧才是有效的，称为当前栈帧，正在执行的方法称为当前方法，栈帧是方法运行的基本结构。

在执行引擎运行时，所有指令都只能针对当前栈帧进行操作，StackOverflowError 表示请求的栈溢出，导致内存耗尽，通常出现在递归方法中。

JVM能够横扫千军，虚拟机栈就是它的心腹大将，当前方法的栈帧，都是正在战斗的战场，其中的操作栈是参与战斗的士兵。

2020319162524-stack

虚拟机栈通过压/出栈的方式，对每个方法对应的活动栈帧进行运算处理，方法正常执行结束，肯定会跳转到另一个栈帧上。

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

下面用一段简单的代码说明操作栈与局部变量表的交互

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

对应的字节码操作顺序如下：

2020319215838-stack-bytecode

20203192247-i-puls-plus-i

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

退出可能有三种方式：

Java 虚拟机栈是描述 Java 方法运行过程的内存模型，Java虚拟机栈会为每一个即将运行的Java方法创建“栈帧”，用于存储该方法在运行过程中所需要的一些信息

每一个方法从被调用到执行完成的过程，都对应着一个个栈帧在JVM 栈中的入栈和出栈过程

注意：人们常说，Java的内存空间分为“栈”和“堆”，栈中存放局部变量，堆中存放对象。 这句话不完全正确！这里的“堆”可以这么理解，但这里的“栈”就是现在讲的虚拟机栈，或者说 Java 虚拟机栈中的局部变量表部分。真正的Java虚拟机栈是由一个个栈帧组成，而每个栈帧中都拥有：局部变量表、操作数栈、动态链接、方法出口信息。

特点

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

Java虚拟机栈会出现两种异常：

若 Java虚拟机栈的内存大小不允许动态扩展,那么当线程请求的栈深度大于虚拟机允许的最大深度时(但内存空间可能还有很多)，就抛出此异常

若Java虚拟机栈的内存大小允许动态扩展，且当线程请求栈时内存用完了，无法再动态扩展了，此时抛出OutOfMemoryError异常

Java虚拟机栈也是线程私有的，每个线程都有各自的 Java 虚拟机栈，而且随着线程的创建而创建，随着线程的死亡而死亡。

本地方法栈(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调用方式

Java堆(Java Heap)

Heap 是 OOM 故障最主要的发源地，它存储着几乎所有的实例对象，堆由垃圾收集器自动回收，堆区由各子线程共享使用。

通常情况下，它占用的空间是所有内存区域中最大的，但如果无节制地创建大量对象，也容易消耗完所有的空间。

堆的内存空间既可以固定大小，也可运行时动态地调整，通过如下参数设定初始值和最大值，比如：

-Xms256M. -Xmx1024M

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

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

堆分成两大块：新生代和老年代，需要注意的是：Perm Gen 不是 Heap 的一部分(java8以上已经没有Perm，元空间代替，元空间在本地内存)，如下图：

|<--Minor GC->|     |<--------Major GC-------->|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||            |  |  |                          |                       ||
||     Eden   |s0|s1|         Old Memory       |         Perm          ||
||            |  |  |                          |                       ||
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|<--------------JVM Heap(-Xms -Xmx)----------->|   -XX:PermSize
|<-Young Gen(-Xmn)->|                              -XX:MaxPermSize

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

新生代= 1个Eden区+ 2个Survivor区

绝大部分对象在 Eden 区生成，当Eden区装填满的时候，会触发 Young GC。垃圾回收的时候，在Eden区实现清除策略，没有被引用的对象则直接回收。依然存活的对象会被移送到Survivor区，这个区真是名副其实的存在。

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

有没有思考过，为什么需要Survivor区？并且是2个Survivor区，s0，s1呢？

如果 YGC 要移送的对象大于Survivor区容量上限，则直接移交给老年代，假如一些没有进取心的对象以为可以一直在新生代的Survivor区交换来交换去，那就错了。每个对象都有一个计数器，每次YGC都会加1。

-XX:MaxTenuringThreshold参数能配置计数器的值到达某个阈值的时候，对象从新生代晋升至老年代。如果该参数配置为1,那么从新生代的Eden区直接移至老年代。默认值是15，可以在Survivor 区交换14次之后，晋升至老年代

2020319232859-gc-process

若 Survivor区无法放下，或者超大对象的阈值超过上限，则尝试在老年代中进行分配;

如果老年代也无法放下，则会触发Full Garbage Collection(Full GC);

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

在不同的 JVM 实现及不同的回收机制中，堆内存的划分方式是不一样的

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

特点

方法区

定义

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

特点

和堆一样，允许固定大小，也允许可扩展的大小，还允许不实现垃圾回收。当方法区内存空间无法满足内存分配需求时，将抛出OutOfMemoryError异常。

运行时常量池(Runtime Constant Pool)

定义

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

我们知道，.java 文件被编译之后生成的.class文件中除了包含：类的版本、字段、方法、接口等信息外，还有一项就是常量池。

常量池中存放编译时期产生的各种字面量和符号引用，.class文件中的常量池中的所有的内容在类被加载后存放到方法区的运行时常量池中。例如：

//age是一个变量，可以被赋值；21就是一个字面值常量，不能被赋值；
int age = 21;
//pai就是一个符号常量，一旦被赋值之后就不能被修改。
int final pai = 3.14;

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

在近三个JDK版本（6、7、8）中， 运行时常量池的所处区域一直在不断的变化：

其实，这也说明了官方对“永久代”的优化从7就已经开始了

特性

class文件中的常量池具有动态性，Java并不要求常量只能在编译时候产生，Java允许在运行期间将新的常量放入方法区的运行时常量池中。String类中的intern()方法就是采用了运行时常量池的动态性。当调用 intern 方法时，如果池已经包含一个等于此 String 对象的字符串，则返回池中的字符串。否则，将此 String 对象添加到池中，并返回此 String 对象的引用。

可能抛出的异常

运行时常量池是方法区的一部分，所以会受到方法区内存的限制，因此当常量池无法再申请到内存时就会抛出OutOfMemoryError异常。

我们一般在一个类中通过 public static final 来声明一个常量。这个类被编译后便生成Class文件，这个类的所有信息都存储在这个class文件中。

当这个类被Java虚拟机加载后，class文件中的常量就存放在方法区的运行时常量池中。而且在运行期间，可以向常量池中添加新的常量。如：String类的intern()方法就能在运行期间向常量池中添加字符串常量。

当运行时常量池中的某些常量没有被对象引用，同时也没有被变量引用，那么就需要垃圾收集器回收。

直接内存(Direct Memory)

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

在JDK 1.4中加入了NIO(New Input／Output)类,引入了一种基于管道和缓冲区的IO方式,它可以使用Native函数库直接分配堆外内存,然后通过一个存储在堆里的DirectByteBuffer对象作为这块内存的引用来操作堆外内存中的数据。

这样能在一些场景中显著提升性能，因为避免了在 Java堆和Native堆中来回复制数据。

综上看来：

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 区所有内容中

2020320141113-constant-pool

比如上图中的Object类元信息、静态属性System.out、整型常量000000等，图中显示在常量池中的String，其实际对象是被保存在堆内存中的。

元空间特色

GC

元空间内存分配模型

最后从线程共享的角度来看：

从这个角度看一下Java内存结构：

2020320141816-memory-model

从GC角度看Java堆

堆和方法区都是线程共享的区域，主要用来存放对象的相关信息。我们知道，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序运行期间才能知道会创建哪些对象，因此， 这部分的内存和回收都是动态的，垃圾收集器所关注的就是这部分内存（本节后续所说的“内存”分配与回收也仅指这部分内存）而在JDK1.7和1.8对这部分内存的分配也有所不同，下面我们来详细看一下：

Java8 中堆内存分配如下图：

2020320142055-java8-memory

配置打印GC日志

nohup java -Xms400m -Xmx400m -verbose:gc -Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -Dfile.encoding=UTF-8 -jar tale-latest.jar --app.env=prod > tale.log 2>&1 &

分析GC日志

2019-05-13T10:17:10.902+0800: 37622.895: [GC (Allocation Failure) 2019-05-13T10:17:10.902+0800: 37622.895: [DefNew: 109585K->282K(122880K), 0.0020507 secs] 117507K->8205K(395968K), 0.0021385 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2019-05-13T10:21:43.112+0800: 37895.104: [GC (Allocation Failure) 2019-05-13T10:21:43.112+0800: 37895.104: [DefNew: 109530K->268K(122880K), 0.0018163 secs] 117453K->8191K(395968K), 0.0018836 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

下面对整个第一条 GC 日志做个详细的分析：

JVM关闭

在某些情况下，我们需要在 JVM关闭时做一些扫尾的工作，比如删除临时文件、停止日志服务。为此 JVM提供了关闭钩子（shutdown hocks）来做这些事件。

Runtime 类封装 java应用运行时的环境，每个java应用程序都有一个Runtime类实例，使用程序能与其运行环境相连。

关闭钩子本质上是一个线程（也称为hock线程），可以通过Runtime的addshutdownhock （Thread hock）向主jvm注册一个关闭钩子。hock线程在jvm正常关闭时执行，强制关闭不执行。

对于在jvm中注册的多个关闭钩子，他们会并发执行，jvm并不能保证他们的执行顺序。

本文由 zealzhangz 创作，采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: 2020/04/14 09:47

→ ← ↓ ↑