JVM从1%到99%【精选】-运行时数据区

目录

1.运行时数据区概括

2.什么是内存溢出 

3..程序计数器

4.Java虚拟机栈

5.本地方法栈

6.堆 

7.方法区

8.直接内存

1.运行时数据区概括

  • Java虚拟机在运行Java程序过程中管理的内存区域,称之为运行时数据区
  • 主要分为两大类:线程不共享线程共享
  • 线程不共享:
    • 程序计数器
    • Java虚拟机栈
    • 本地方法栈
  • 线程共享:
    • 方法区

2.什么是内存溢出 

  • 内存溢出:指的是程序在使用某一块内存区域时,存放的数据需要占用的内存大小超过了虚拟机能提供的内存上限

3..程序计数器

  • 程序计数器(Program Counter Register)也叫PC寄存器,每个线程会通过程序计数器记录当前要执行的的字节码指令的地址。 
    • 在加载阶段,虚拟机将字节码文件中的指令读取到内存之后,会将原文件中的偏移量转换成内存地址
    • 每一条字节码指令都会拥有一个内存地址。
  • 作用:
    • 1.程序计数器可以控制程序指令的进行,实现分支、跳转、异常等逻辑。
    • 2.在多线程执行情况下,Java虚拟机需要通过程序计数器记录CPU切换前解释执行到那一句指令并继续解释运行
  • 内存溢出:不会出现内存溢出
    • 因为每个线程只存储一个固定长度的内存地址,程序计数器是不会发生内存溢出的
    • 程序员无需对程序计数器做任何处理。

4.Java虚拟机栈

  • Java虚拟机栈(Java Virtual Machine Stack)采用栈的数据结构来管理方法调用中的基本数据,先进后出(First In Last Out) ,每一个方法的调用使用一个栈帧(Stack Frame)来保存。 
  • Java虚拟机栈随着线程的创建而创建,随着线程的销毁而回收
    • 由于方法可能会在不同线程中执行每个线程都会包含一个自己的虚拟机栈
  • 栈帧的组成:
    • 局部变量表:局部变量表的作用是在运行过程中存放所有的局部变量
      • 栈帧中的局部变量表是一个数组,数组中每一个位置称之为槽(slot), long和double类型占用两个槽,其他类型占用一个槽。
    • 操作数栈:操作数栈是栈帧中虚拟机在执行指令过程中用来存放临时数据的一块区域
    • 帧数据:帧数据主要包含动态链接方法出口异常表的引用
      • 当前类的字节码指令引用了其他类的属性或者方法时,需要将符号引用(编号)转换成对应的运行时常量池中的内存地址动态链接保存了编号到运行时常量池的内存地址的映射关系
      • 方法出口指的是方法在正确或者异常结束时当前栈帧会被弹出,同时程序计数器应该指向上一个栈帧中的下一条指令的地址。所以在当前栈帧中需要存储此方法出口的地址
      • 异常表存放的是代码中异常的处理信息,包含了异常捕获的生效范围以及异常发生后跳转到的字节码指令位置
  • 内存溢出:会出现内存溢出
    • Java虚拟机栈如果栈帧过多,占用内存超过栈内存可以分配的最大大小就会出现内存溢出。
    • 要修改Java虚拟机栈的大小,可以使用虚拟机参数-Xss 。
    • 语法: -Xss栈大小  (-Xss1024k)
    • Windows (64位)下的JDK8测试最小值为180k,最大值为1024m。
    • 一般情况下,工作中即便使用了递归进行操作,栈的深度最多也只能到几百,不会出现栈的溢出。所以此参数可以手动指定为-Xss256k节省内存。

5.本地方法栈

  • 本地方法栈(Native Method Stacks)与虚拟机栈相似,区别在于
    • 虚拟机栈是为 JVM 执行 Java 编写的方法服务的
    • 本地方法栈是为 Java 调用本地(native)方法C服务的,由 C/C++ 编写。
  • 本地方法栈中,主要存放了 native 方法的局部变量、动态链接和方法出口等信息。当一个 Java 程序调用一个 native 方法时,JVM 会切换到本地方法栈来执行这个方法。
  • 在Hotspot虚拟机中,Java虚拟机栈本地方法栈实现上使用了同一个栈空间
    • 本地方法栈会在栈内存上生成一个栈帧,临时保存方法的参数同时方便出现异常时也把本地方法的栈信息打印出来。

6.堆 

  • 堆(heap)是 JVM 中最大的一块内存区域,被所有线程共享,在 JVM 启动时创建,主要用来存储对象的。
  • 堆空间有三个需要关注的值,:used、 total、 max。
    • used是当前已使用的堆内存。
    • total是java虚拟机已经分配的可用堆内存。
    • max是java虚拟机可以分配的最大堆内存。

  • 内存溢出:会出现内存溢出

7.方法区

  • 方法区是用来存储每个类的基本信息(元信息),主要包含三部分内容: 
    • 类的元信息:保存了所有类的基本信息
    • 运行时常量池:保存了字节码文件中的常量池内容
      • 静态常量池:字节码文件中通过编号查表的方式找到常量
      • 运行时常量池:当常量池加载到内存中之后,可以通过内存地址快速的定位到常量池中的内容
    • 字符串常量池:保存了字符串常量
  • 方法区并不真实存在,属于 Java 虚拟机规范中的一个逻辑概念,每款Java虚拟机在实现上都各不相同。
    • JDK7及之前的版本方法区存放在堆区域中的永久代空间堆的大小由虚拟机参数来控制
    • JDK8及之后的版本方法区存放在元空间中,元空间位于操作系统维护的直接内存中,默认情况下只要不超过操作系统承受的上限,可以一直分配
  • 内存溢出:会出现内存溢出

8.直接内存

  • 直接内存(Direct Memory)并不在《Java虚拟机规范》中存在,所以并不属于Java运行时的内存区域。 
  • 使用了直接内存,主要为了解决以下两个问题:
    • 1.Java堆中的对象如果不再使用要回收,回收时会影响对象的创建和使用。
    • 2.IO操作比如读文件,需要先把文件读入直接内存(缓冲区)再把数据复制到Java堆中。现在直接放入直接内存即可,同时Java堆上维护直接内存的引用,减少了数据复制的开销。

<think> 我们分析一下当前的JVM内存和GC情况: 堆内存(heap): 总大小:2924M 已使用:539M(18.45%) 分代情况: Eden区:1844M容量,已使用329M(17.88%) Survivor区:81408K(约79.5M),已使用0K(0%),说明Survivor区没有使用,这可能是刚发生Young GC后,或者对象直接进入了老年代? 老年代(Old Gen):1000M容量,已使用209M(20.96%) 非堆内存(nonheap): 总使用:262M(占最大容量275M的95.19%) 其中: Code Cache:91M/92M(99.46%),注意这里最大是240M,但当前使用已经接近设置的92M(可能是-XX:ReservedCodeCacheSize设置),但实际最大可以到240M,所以这里使用率是38.21%(91M/240M)?但是非堆内存的总使用率是95.19%,所以可能是非堆内存中的其他部分使用较多。 Metaspace:151M/162M(93.53%),使用率较高。 Compressed Class Space:18M/20M(90%),使用率也较高。 GC情况: Young GC(ps_scavenge)发生了54次,总耗889ms,平均每次约16.46ms。 Full GC(ps_marksweep)发生了5次,总耗675ms,平均每次135ms。 分析: 1. 堆内存使用率较低(18.45%),说明当前堆内存配置(-Xmx设置为2924M)是足够的,甚至可能过大。因为老年代只用了20%,年轻代Eden区用了17.88%,而Survivor区为0,这个现象需要关注。 2. Survivor区使用率为0,可能是由于刚进行过Young GC,存活对象全部晋升到老年代?或者由于对象过大直接进入老年代?另外,Survivor区的大小(约79.5M)相对于Eden区(1844M)来说比例较小(默认比例是8:1:1,但这里Eden区1844M,两个Survivor区各79.5M,比例约为23:1,明显Survivor区比例偏小)。这可能导致Young GC存活对象无法在Survivor区容纳而直接进入老年代。 3. 非堆内存中Metaspace和Compressed Class Space使用率较高(93.53%和90%),需要关注,如果类加载继续增加,可能会触发Full GC来回收Metaspace。 4. Code Cache使用了91M,但最大可到240M,所以还有空间,但当前使用率(91M)已经接近ReservedCodeCacheSize(如果设置了的话)的92M,所以需要关注。不过使用率指标(38.21%)是相对于240M计算的,所以暂安全。 5. Full GC发生了5次,平均每次135ms,这个间较长,需要尽量减少Full GC。 建议: 1. 堆内存:当前堆内存使用率不高,可以考虑适当降低-Xmx,比如减少到2G(2048M),以节省内存资源。但需要结合应用的实际运行情况,因为当前可能是低负载期。 2. 调整年轻代比例:当前Survivor区过小,容易导致对象直接晋升老年代。建议调整-XX:SurvivorRatio,例如设置为8(Eden与一个Survivor区的比例8:1,那么两个Survivor就是1:1,这样Eden占80%,每个Survivor占10%)。当前总年轻代大小=Eden+2*Survivor=1844M+2*79.5M≈2003M。如果调整SurvivorRatio=8,则Eden占年轻代的80%,Survivor各占10%。那么年轻代总大小不变的情况下,Eden为1602.4M,每个Survivor为200.3M。这样Survivor区变大,可以减少过早晋升。 3. 监控Metaspace:如果Metaspace持续增长,考虑增加-XX:MaxMetaspaceSize(比如256M)以避免Metaspace的Full GC。 4. Code Cache:如果经常达到92M(ReservedCodeCacheSize),可以适当增加-XX:ReservedCodeCacheSize(比如128M),但这里最大是240M,所以暂不需要调整。 是否调整-Xmx? 从当前使用情况看,堆内存使用率不高,可以降低-Xmx以节省资源。但也要考虑应用峰值情况。如果有监控数据,可以观察峰值内存使用情况,再决定。 注意:调整参数后需要重新观察GC日志和内存使用情况。 参数调整示例: -Xmx2048M -Xms2048M (堆内存调整为2G) -XX:SurvivorRatio=8 (调整Survivor区比例) -XX:MaxMetaspaceSize=256M (增大Metaspace最大大小) 重新调整后,监控Survivor区的使用率以及晋升到老年代的对象情况,同关注Full GC次数是否减少。 结论:建议调整-Xmx,同调整SurvivorRatio和MaxMetaspaceSize。 §§相关问题§§ 1. 为什么Survivor区使用率为0可能表示存在对象直接晋升老年代? 2. 如何通过GC日志验证对象晋升的原因? 3. 调整-XX:SurvivorRatio后如何确认新的内存分布生效? 4. 降低-Xmx后如何避免在流量高峰出现OOM? 5. Metaspace使用率达到什么阈值会触发Full GC? </think>### Arthas Dashboard 内存分析及 `-Xmx` 调整建议 基于当前内存数据,关键指标分析如下: --- #### **1. 堆内存使用情况(Heap)** | 区域 | 已使用 | 总容量 | 使用率 | 状态评估 | |--------------------|---------|--------|--------|-------------------| | **总堆** | 539M | 2924M | 18.45% | **空闲充足** | | Eden 区 | 329M | 1844M | 17.88% | 分配压力极低 | | Survivor 区 | 0K | 79.5M | 0% | 无存活对象 | | 老年代 (Old Gen) | 209M | 1000M | 20.96% | 对象驻留稳定 | #### **2. GC 行为分析** | GC 类型 | 次数 | 总耗 | 平均耗 | 健康度 | |--------------------|------|--------|----------|--------| | Young GC (Scavenge) | 54 | 889ms | 16.5ms | ✅ 优秀 | | Full GC (MarkSweep) | 5 | 675ms | 135ms | ⚠️ 偏高 | #### **3. 非堆内存** - **Metaspace**:151M/162M(93.53%)→ **接近临界值(需监控)** - **Code Cache**:91M/240M(38.21%)→ 空间充足 --- ### `-Xmx` 调整决策 **当前无需调整 `-Xmx`**,原因: 1. **堆利用率过低** - 总堆使用率仅 18.45%(539M/2924M),远未达到扩容阈值 - 老年代使用率 20.96%,无内存压力 2. **GC 表现健康** - Young GC 平均 16.5ms(<50ms 属优秀水平) - Full GC 频率极低(5 次),非主要瓶颈 3. **优化优先级更高点** - ⚠️ Metaspace 使用率 93.53% 是更紧迫问题 - Survivor 区 0% 使用率表明对象分配/晋升策略异常 --- ### 优化建议(优于调整 `-Xmx`) #### **1. 紧急措施:防止 Metaspace OOM** ```bash # 扩大 Metaspace 并启用卸载 -XX:MaxMetaspaceSize=256M -XX:+CMSClassUnloadingEnabled ``` #### **2. 修复 Survivor 区异常** ```bash # 增大 Survivor 区避免过早晋升 -XX:SurvivorRatio=6 # Eden:Survivor=6:1:1 # 检查大对象分配 vmtool --action getInstances --limit 10 --className *[size>1MB]* ``` #### **3. Full GC 深度排查** ```bash # 分析 Full GC 根因 gc --cause # 检查 finalize 队列 heapdump --live /tmp/dump.hprof -y ``` --- ### 内存配置调优参考 ```bash # 当前配置(无需改动堆大小) -Xmx2924m -Xms2924m # 优化后建议配置 -Xmx2924m -Xms2924m -XX:MetaspaceSize=192m -XX:MaxMetaspaceSize=256m -XX:SurvivorRatio=6 -XX:MaxTenuringThreshold=15 ``` > **结论**:优先解决 Metaspace 和对象分配问题,`-Xmx` 维持现状即可。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

会敲代码的小张

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值