绝了! 华为技术专家居然把 JVM 内存模型讲解这么细致!
栈中的元素用于支持虚拟机进行方法调用,每个方法从开始调用到执行完成的过程,就是栈帧从入栈到出栈的过程。
栈帧是方法运行的基本结构。
在活动线程中,只有位于栈顶的帧才是有效的,称为
当前栈帧
正在执行的方法称为
当前方法
在执行引擎运行时,所有指令都只能针对当前栈帧操作,StackOverflowError
表示请求的栈溢出,导致内存耗尽,通常出现在递归方法。
当前方法的栈帧,都是正在战斗的战场,其中的操作栈是参与战斗的士兵
操作栈的压栈与出栈
虚拟机栈通过压/出栈,对每个方法对应的活动栈帧进行运算处理,方法正常执行结束,肯定会跳转到另一个栈帧上。
在执行的过程中,如果出现异常,会进行异常回溯,返回地址通过异常处理表确定。
栈帧在整个 JVM 体系中的地位颇高,包括:局部变量表、操作栈、动态连接、方法返回地址等。
局部变量表
存放方法参数和局部变量。
相对于类属性变量的准备阶段和初始化阶段,局部变量没有准备阶段,必须显式初始化。
如果是非静态方法,则在 index[0]位置上存储的是方法所属对象的实例引用,随后存储的是参数和局部变量。
字节码指令中的 STORE 指令就是将操作栈中计算完成的局部变量写回局部变量表的存储空间内。
操作数栈
一个初始状态为空的桶式结构栈。由于 Java 没有寄存器,所有参数传递使用操作数栈。在方法执行过程中,会有各种指令往栈中写入和提取信息。JVM 的执行引擎是基于栈的执行引擎,其中的栈指的就是操作栈。
字节码指令集的定义都是基于栈类型的,栈的深度在方法元信息的 stack 属性中。
操作栈与局部变量表交互
详细的字节码操作顺序如下:
第 1 处说明:局部变量表就像个中药柜,里面有很多抽屉,依次编号为 0, 1, 2,3,.,. n
字节码指令istore_ 1
就是打开 1 号抽屉,把栈顶中的数 13 存进去
栈是一个很深的竖桶,任何时候只能对桶口元素进行操作,所以数据只能在栈顶进行存取
某些指令可以直接在抽屉里进行,比如inc
指令,直接对抽屉里的数值进行+1 操作
程序员面试过程中,常见的 i++和++i 的区别,可以从字节码上对比出来
iload_ 1
从局部变量表的第 1 号抽屉里取出一个数,压入栈顶,下一步直接在抽屉里实现+1 的操作,而这个操作对栈顶元素的值没有影响
所以 istore_ 2 只是把栈顶元素赋值给 a
表格右列,先在第 1 号抽屉里执行+1 操作,然后通过 iload_ 1 把第 1 号抽屉里的数压入栈顶,所以 istore_ 2 存入的是+1 之后的值
i++并非原子操作。即使通过 volatile 关键字进行修饰,多个线程同时写的话,也会产生数据互相覆盖的问题。
动态连接
每个栈帧中包含一个在常量池中对当前方法的引用,目的是支持方法调用过程的动态连接。
方法返回地址
方法执行时有两种退出情况:
正常退出
正常执行到任何方法的返回字节码指令,如 RETURN、IRETURN、ARETURN 等。
异常退出
无论何种,都将返回至方法当前被调用的位置。方法退出的过程相当于弹出当前栈帧。
退出可能有三种方式:
返回值压入,上层调用栈帧
异常信息抛给能够处理的栈帧
PC 计数器指向方法调用后的下一条指令
Java 虚拟机栈是描述 Java 方法运行过程的内存模型。Java 虚拟机栈会为每一个即将运行的 Java 方法创建“栈帧”。用于存储该方法在运行过程中所需要的一些信息。
局部变量表
存放基本数据类型变量、引用类型的变量、returnAddress 类型的变量
操作数栈
动态链接
当前方法的常量池指针
当前方法的返回地址
方法出口等信息
每一个方法从被调用到执行完成的过程,都对应着一个个栈帧在 JVM 栈中的入栈和出栈过程
注意:人们常说,Java 的内存空间分为“栈”和“堆”,栈中存放局部变量,堆中存放对象。
这句话不完全正确!这里的“堆”可以这么理解,但这里的“栈”就是现在讲的虚拟机栈,或者说 Java 虚拟机栈中的局部变量表部分.
真正的 Java 虚拟机栈是由一个个栈帧组成,而每个栈帧中都拥有:局部变量表、操作数栈、动态链接、方法出口信息.
局部变量表的创建是在方法被执行的时候,随栈帧创建而创建。
表的大小在编译期就确定,在创建的时候只需分配事先规定好的大小即可。在方法运行过程中,表的大小不会改变。Java 虚拟机栈会出现两种异常:
StackOverFlowError
若 Java 虚拟机栈的内存大小不允许动态扩展,那么当线程请求的栈深度大于虚拟机允许的最大深度时(但内存空间可能还有很多),就抛出此异常
栈内存默认最大是 1M,超出则抛出 StackOverflowError
OutOfMemoryError
若 Java 虚拟机栈的内存大小允许动态扩展,且当线程请求栈时内存用完了,无法再动态扩展了,此时抛出 OutOfMemoryError 异常
Java 虚拟机栈也是线程私有的,每个线程都有各自的 Java 虚拟机栈,而且随着线程的创建而创建,随线程的死亡而死亡。
=============================================================================================
和虚拟机栈功能类似,虚拟机栈是为虚拟机执行 JAVA 方法而准备的。虚拟机规范并未规定具体实现,由不同虚拟机厂商自行实现。
HotSpot 虚拟机中虚拟机栈和本地方法栈的实现式一样的。
本地方法栈和 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 调用方式。
=================================================================================
JVM 启动时创建,存放所有的类实例及数组对象。
除实例数据,还保存对象的其他信息,如 Mark Word(存储对象哈希码,GC 标志,GC 年龄,同步锁等信息),Klass Pointy(指向存储类型元数据的指针)及一些字节对齐补白的填充数据(若实例数据刚好满足 8 字节对齐,则可不存在补白)。
垃圾回收器主要就是管理堆内存。
Heap 是 OOM 主要发源地,它存储着几乎所有的实例对象,堆由垃圾收集器自动回收,由各子线程共享使用。通常它占用的空间是所有内存区域中最大的,但若无节制创建大量对象,也容易消耗完所有空间。
堆的内存空间,既可以固定大小,也可运行时动态调整,通过如下参数设定初始值和最大值,比如
-Xms 256M
-Xmx 1024M
其中-X 表示它是 JVM 运行参数
ms 是 memorystart 的简称,最小堆容量
mx 是 memory max 的简称,最大堆容量
通常情况下,服务器在运行过程中,堆空间不断地扩容与回缩,势必形成不必要系统压力,所以在线上生产环境中,JVM 的 Xms 和 Xmx 设置成一样大小,避免在 GC 后调整堆大小时带来的额外压力。
堆分成两大块:新生代和老年代
对象产生之初在新生代,步入暮年时进入老年代,但是老年代也接纳在新生代无法容纳的超大对象。
新生代
1 个 Eden 区+ 2 个 Survivor 区。绝大部分对象在 Eden 区生成,当 Eden 区填满,会触发 Young GC(后文简称 YGC)。GC 时,在 Eden 区实现清除策略,没有被引用的对象则直接回收。依然存活的对象会被复制到 Survivor 区。
Survivor 区分为 S0 和 S1 两块内存空间,送到哪块空间呢?
每次 YGC 时,将存活的对象复制到未使用的那块空间,然后将当前正在使用的空间完全清除,交换两块空间的使用状态。
若 YGC 要移送的对象大于 Survivor 区容量上限,则直接移交给老年代。假如一些没有进取心的对象以为可以一直在新生代的 Survivor 区交换来交换去,那就错了。每个对象都有一个计数器,每次 YGC 都会加 1。
-XX:MaxTenuringThreshold
参数能配置计数器的值到达某个阈值的时候,对象从新生代晋升至老年代。若该参数配置为 1,则从新生代的 Eden 区直接移至老年代。
默认值是 15
可以在 Survivor 区交换 14 次之后,晋升至老年代
对象分配与简要 GC 流程图
若Survivor
区无法放下,或超大对象的阈值超过上限,则尝试在老年代中进行分配。
若老年代也无法放下,则会触发 Full Garbage Collection(Full GC),若依然无法放下,则抛 OOM。
堆出现 OOM 的概率是所有内存耗尽异常中最高的,出错时的堆内信息对解决问题非常有帮助,所以给 JVM 设置运行参数
-XX:+HeapDumpOnOutOfMemoryError
让 JVM 遇到 OOM 异常时能输出堆内信息。
在不同的 JVM 实现及不同的回收机制中,堆内存的划分方式是不一样的。
Java 虚拟机所需要管理的内存中最大的一块.
堆内存物理上不一定要连续,只需要逻辑上连续即可,就像磁盘空间一样.
堆是垃圾回收的主要区域,所以也被称为 GC 堆.
堆的大小既可以固定也可以扩展,但主流的虚拟机堆的大小是可扩展的(通过-Xmx 和-Xms 控制),因此当线程请求分配内存,但堆已满,且内存已满无法再扩展时,就抛出 OutOfMemoryError.
线程共享
整个 Java 虚拟机只有一个堆,所有的线程都访问同一个堆.
它是被所有线程共享的一块内存区域,在虚拟机启动时创建.
而程序计数器、Java 虚拟机栈、本地方法栈都是一个线程对应一个
[](ht
tps://blog.csdn.net/qq_33589510/article/details/116423830)5 方法区
====================================================================
Java 虚拟机规范中定义方法区是堆的一个逻辑区划部分,具体实现根据不同虚拟机来实现。
HotSpot 在:
JDK7 时,方法区放在永久代
JDK8 时,方法区放在元数据空间,通过 GC 对该区域进行管理
别名 Non-Heap(非堆),以与 Java 堆区分。
方法区主要存放已经被虚拟机加载的类型的相关信息:
类信息
类名、访问修饰符、字段描述、方法描述
运行时常量池
常量存储在【运行时常量池】
静态变量
即时编译器(JIT)编译后的代码等数据
线程共享
方法区是堆的一个逻辑部分,因此和堆一样,都是线程共享的。整个虚拟机中只有一个方法区。
永久代
方法区中的信息一般需要长期存在,而且它又是堆的逻辑分区,因此用堆的划分方法,我们把方法区称为永久代。
内存回收效率低
Java 虚拟机规范对方法区的要求比较宽松,可以不实现垃圾收集。方法区中的信息一般需要长期存在,回收一遍内存之后可能只有少量信息无效。对方法区的内存回收的主要目标是:对常量池的回收和对类型的卸载。
和堆一样,允许固定大小,也可扩展大小,还允许不实现 GC。
当方法区内存空间无法满足内存分配需求时,将抛出 OutOfMemoryError 异常.
5.3 运行时常量池(Runtime Constant Pool)
5.3.1 定义
方法区的一部分。
.java
文件被编译之后生成的.class
文件中除了包含:类的版本、字段、方法、接口等描述信息外,还有一项就是常量池。
常量池中存放编译时期产生的各种字面量和符号引用,.class
文件中的常量池中的所有的内容在类被加载后存放到方法区的运行时常量池中。
// age 是一个变量,可被赋值
// 21 是一个字面值常量,不能被赋值
PS:int age = 21;
// pai 是一个符号常量,一旦被赋值之后就不能被修改
int final pai = 3.14;
JDK6、7、8 三个版本中, 运行时常量池的所处区域一直在不断的变化:
6 时,是方法区的一部分
7 时,又放到堆内存
8 时,出现了元空间,又回到了方法区
这也说明了官方对“永久代”的优化从 7 就已经开始了。
5.3.2 特性
运行时常量池相对于 class 文件常量池的另外一个特性是具备动态性,Java 语言并不要求常量一定只有编译器才产生,也就是并非预置入 class 文件中常量池的内容才能进入方法区运行时常量池,运行期间也可能将新的常量放入池中。
String 类的 intern()方法就是采用了运行时常量池的动态性。当调用 intern 方法时,看池中已包含一个等于此 String 对象的字符串:
是
则返回池中的字符串
否
将此 String 对象添加到池中,并返回此 String 对象的引用
5.3.3 可能抛出的异常
运行时常量池是方法区的一部分,所以会受到方法区内存的限制,因此当常量池无法再申请到内存时就会抛出 OutOfMemoryError 异常.
我们一般在一个类中通过 public static final 来声明一个常量。这个类被编译后便生成 Class 文件,这个类的所有信息都存储在这个 class 文件中。
当这个类被 Java 虚拟机加载后,class 文件中的常量就存放在方法区的运行时常量池中。而且在运行期间,可以向常量池中添加新的常量。如:String 类的 intern()方法就能在运行期间向常量池中添加字符串常量。
当运行时常量池中的某些常量没有被对象引用,同时也没有被变量引用,那么就需要垃圾收集器回收。
====================================================================================
直接内存不是虚拟机运行时数据区的一部分,也不是 JVM 规范中定义的内存区域,但在 JVM 的实际运行过程中会频繁地使用这块区域,而且也会抛 OOM 。
在 JDK 1.4 中加入了 NIO(New Input/Output)类,引入了一种基于管道和缓冲区的 IO 方式,它可以使用 Native 函数库直接分配堆外内存,然后通过一个存储在堆里的DirectByteBuffer
对象作为这块内存的引用来操作堆外内存中的数据。
这样能在一些场景中显著提升性能,因为避免了在 Java 堆和 Native 堆中来回复制数据。
综上,程序计数器、Java 虚拟机栈、本地方法栈是线程私有的,即每个线程都拥有各自的程序计数器、Java 虚拟机栈、本地方法区。并且他们的生命周期和所属的线程一样。
而堆、方法区是线程共享的,在 Java 虚拟机中只有一个堆、一个方法栈。并在 JVM 启动的时候就创建,JVM 停止才销毁。
================================================================================
到了 JDK8,元空间的前身 Perm 区(永久代)被淘汰,在 JDK7 及之前的版本中,只有 Hotspot 才有 Perm 区,它在启动时固定大小,很难调优,并且 Full GC 时会移动类元信息。
在某些场景下,若动态加载类过多,容易产生 Perm 区的 OOM。比如某工程因为功能点较多,运行过程中,要不断动态加载很多类,经常出现错误:
Exception in thread ‘dubbo client x.x connector'
java.lang.OutOfMemoryError: PermGenspac
为解决该问题,需要设定运行参数
-XX:MaxPermSize=1280m
如果部署到新机器上,往往会因为 JVM 参数没有修改导致故障再现。不熟悉此应用的人排查问题时都苦不堪言。此外,永久代在 GC 过程中还存在诸多问题。
所以,JDK8 使用元空间替换永久代。区别于永久代,元空间在本地内存中分配。即
只要本地内存足够,它不会出现类似永久代的java.lang.OutOfMemoryError: PermGen space
对永久代的设置参数 PermSize
和MaxPermSize
也会失效。在 JDK8 及以上版本,设定MaxPermSize
参数,JVM 在启动时并不会报错,但会提示:
评论