JVM CMS GC算法如何配置堆内存比例

最新推荐文章于 2025-12-09 21:41:23 发布
原创 最新推荐文章于 2025-12-09 21:41:23 发布 · 833 阅读 · 12 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
标签
#jvm #java

1. CMS GC内存结构简述

JVM堆内存主要分为：

  • 新生代（Young Generation）：包括 Eden 区和两个 Survivor 区（S0/S1）
  • 老年代（Old Generation）
  • （还有永久代/元空间，但与 CMS GC 配置比例关系较小）

CMS GC主要作用于老年代，而新生代通常由 ParNew GC 回收。

2. 主要配置参数

2.1 总堆内存大小

-Xms<size>  # 初始堆大小
-Xmx<size>  # 最大堆大小

2.2 新生代大小

-Xmn<size>  # 新生代大小（包括Eden和Survivor区）

2.3 新生代与老年代比例

  • 新生代大小 = -Xmn
  • 老年代大小 = 总堆大小 - 新生代大小

例如：

-Xmx4g -Xms4g -Xmn1g

表示总堆4G，其中新生代1G，老年代3G。

2.4 Eden与Survivor比例

-XX:SurvivorRatio=<N>

Eden区与每个Survivor区的比例。例如：

  • -XX:SurvivorRatio=8 表示 Eden : S0 : S1 = 8 : 1 : 1

2.5 新生代与老年代比例（另一种方式）

如果不指定-Xmn，可以通过下面参数控制比例：

-XX:NewRatio=<N>

表示老年代:新生代的比例。例如：

  • -XX:NewRatio=2 表示老年代是新生代的2倍（即新生代占1/3，老年代占2/3）

3. CMS GC相关参数

启用CMS GC：

-XX:+UseConcMarkSweepGC

常用配合参数：

-XX:CMSInitiatingOccupancyFraction=<N>  # 老年代使用率到N%时触发CMS
-XX:+UseCMSInitiatingOccupancyOnly      # 只用上述阈值触发CMS

4. 配置举例

举例1：指定新生代大小

-Xms8g -Xmx8g -Xmn2g -XX:+UseConcMarkSweepGC
  • 堆总大小8G
  • 新生代2G
  • 老年代6G

举例2：通过比例配置

-Xms8g -Xmx8g -XX:NewRatio=3 -XX:+UseConcMarkSweepGC
  • 新生代占1/4（2G），老年代占3/4（6G）

5. 选择建议

  • 大对象多/存活对象多：新生代可以适当调小，老年代调大。
  • 大量短生命周期对象：新生代调大，减少晋升老年代频率。
  • CMS GC适合老年代回收耗时敏感场景。

6. 其他补充

  • CMS GC在JDK9及以后被标记为废弃，推荐使用G1 GC。
  • CMS GC对内存比例配置非常敏感，建议根据实际业务压力和GC日志反复调优。

7. CMS GC内存比例调优思路

7.1 新生代与老年代比例调优原则

  • 新生代较大：适合大量短命对象，减少Minor GC频率，但晋升老年代的对象会多。
  • 老年代较大：适合大量长寿命对象，减少Full GC频率，但Minor GC可能更频繁。

调优目标：

  • Minor GC频率适中，停顿时间短。
  • 老年代不容易被填满，避免频繁Full GC或CMS GC。
  • 晋升失败（Promotion Failed）或Concurrent Mode Failure尽量避免。

7.2 配置参数优先级

  • -Xmn（新生代大小）和 -XX:NewRatio（比例）只用其一，-Xmn优先生效。
  • 推荐直接用-Xmn，便于精确控制。

8. Survivor区比例的调优

  • Eden与Survivor区比例通过-XX:SurvivorRatio控制。
  • 默认是8，即Eden:S0:S1=8:1:1。
  • Survivor区过小可能导致对象过早晋升到老年代，过大则浪费新生代空间。

调优建议：

  • 观察GC日志中“对象在Survivor区存活次数”，适当调整Survivor区大小，减少对象早晋升。

9. CMS相关其他重要参数

  • -XX:CMSInitiatingOccupancyFraction=75
    老年代使用率达到75%时触发CMS GC，默认是68%。

  • -XX:+UseCMSInitiatingOccupancyOnly
    只用上述阈值，不用JVM自适应策略。

  • -XX:MaxTenuringThreshold=15
    新生代对象晋升到老年代的最大存活次数（默认15）。

10. 常见内存配置问题及排查

10.1 新生代过小

表现：

  • Minor GC频繁，吞吐量低。
  • 新生代对象大量晋升到老年代，老年代很快被填满。

解决：

  • 增大-Xmn或调小-XX:NewRatio。

10.2 老年代过小

表现：

  • CMS GC频繁，甚至出现Concurrent Mode Failure（并发模式失败）。
  • 老年代OOM。

解决：

  • 增大堆总量或减少新生代比例。

10.3 Survivor区过小

表现：

  • 新生代对象无法在Survivor区多次存活，过早晋升老年代。

解决：

  • 调小-XX:SurvivorRatio（如从8调到6）。

11. 实际调优流程

  1. 收集GC日志
    打开GC详细日志，分析Minor GC和Full GC频率、耗时、晋升情况。

  2. 分析对象分布
    用jmap -heap、jstat -gc、VisualVM等工具查看堆内存使用和对象年龄分布。

  3. 调整参数

    • Minor GC频繁 → 增大新生代
    • Full GC频繁或CMS失败 → 增大老年代
    • 晋升过快 → 增大Survivor区

  4. 反复验证
    每次调整后观察一段时间，反复迭代。

12. 配置案例对比

案例1：大新生代，适合高并发短生命周期对象

-Xms8g -Xmx8g -Xmn4g -XX:SurvivorRatio=6 -XX:+UseConcMarkSweepGC
  • 新生代4G，老年代4G
  • Survivor区比例6:1:1，便于对象多次存活

案例2：大老年代，适合长生命周期对象

-Xms8g -Xmx8g -Xmn2g -XX:SurvivorRatio=8 -XX:+UseConcMarkSweepGC
  • 新生代2G，老年代6G
  • Survivor区比例8:1:1，适合对象早晋升

13. 线上环境运维建议

  • 定期分析GC日志，关注CMS GC耗时、频率、是否有Concurrent Mode Failure
  • 内存配置要留冗余，避免极限压榨
  • CMS GC已被JDK9+废弃，建议新项目用G1 GC

14. 自动化调优与监控建议

14.1 自动化调优思路

  • 利用A/B测试或灰度发布，观察不同内存比例下GC行为。
  • 结合监控系统（如Prometheus + Grafana、ELK）实时采集GC日志和JVM内存指标。
  • 设定报警阈值（如Full GC次数、CMS失败、堆使用率过高），自动触发运维通知。

14.2 关键监控指标

  • Minor GC/Full GC次数与耗时
  • 老年代使用率变化
  • 晋升失败/Concurrent Mode Failure次数
  • 应用响应时间与吞吐量

15. 典型问题及处理

15.1 CMS Concurrent Mode Failure

原因：

  • CMS并发回收时，老年代被填满，导致JVM不得不STW进行标记和清理。

处理方法：

  • 增大老年代（减小新生代或增大堆总量）
  • 提前触发CMS GC（降低-XX:CMSInitiatingOccupancyFraction）
  • 优化业务代码减少大对象或长生命周期对象

15.2 晋升失败（Promotion Failed）

原因：

  • 新生代GC后，晋升到老年代的对象超过老年代剩余空间。

处理方法：

  • 增大老年代
  • 优化对象生命周期，减少晋升频率
  • 增加Survivor区大小，让对象多存活几次，避免过早晋升

15.3 内存碎片化

CMS GC是标记-清除算法，容易造成老年代内存碎片。

  • 可用-XX:+UseCMSCompactAtFullCollection在每次Full GC后做老年代压缩，但会增加停顿时间。

16. 与其他JVM参数的协同关系

16.1 -XX:MaxTenuringThreshold

  • 控制对象在Survivor区存活几次后晋升老年代。
  • 较大值适合对象生命周期分布广的场景，较小值适合对象寿命短的场景。

16.2 -XX:PretenureSizeThreshold

  • 超过该大小的新对象直接分配到老年代，适合大对象场景。
  • 结合CMS GC可减少新生代GC压力。

16.3 -XX:CMSInitiatingOccupancyFraction 和 -XX:+UseCMSInitiatingOccupancyOnly

  • 控制老年代使用率达到多少时触发CMS GC。
  • 配合业务高峰期提前GC，防止老年代爆满。

17. CMS GC与G1 GC的迁移建议

  • CMS GC在JDK9及以后已废弃，官方推荐使用G1 GC。
  • G1 GC不需要手动区分新生代/老年代，自动分配和回收。
  • 如果你的应用升级JDK，建议切换到G1 GC，简化内存调优。

G1 GC典型配置：

-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:InitiatingHeapOccupancyPercent=45

G1 GC会自动根据Pause目标和堆使用率动态调整内存比例。

18. 生产环境配置建议

  • 预留足够堆空间，不要把物理内存用到极限，留出操作系统和其他进程空间。
  • 分阶段逐步调优，每次调整只改一个参数，观察效果。
  • 定期回顾GC日志，分析GC行为变化，防止参数老化。
  • 准备OOM应急方案，如自动重启、内存转储、报警通知。

总结

CMS GC新生代与老年代的内存比例，主要通过 -Xmn 或 -XX:NewRatio 参数配置。

  • -Xmn 明确指定新生代大小
  • -XX:NewRatio 按比例指定新生代和老年代大小

CMS GC内存比例的核心调优点：

  • 通过-Xmn/-XX:NewRatio控制新生代与老年代比例
  • 通过-XX:SurvivorRatio控制Eden与Survivor比例
  • 结合GC日志、对象分布和业务特性反复调优

CMS GC内存比例配置是性能调优的核心环节，涉及新生代、老年代、Survivor区的合理分配，以及与晋升、回收、碎片等问题的协同调优。
随着JDK版本升级，建议逐步迁移到G1 GC，简化配置和运维压力。

JVM虚拟机：如何调整堆空间的大小？
huanfeng_AI的博客
10-31 438
如上所示，我们通过maxMemory获取到java虚拟机试图使用的最大内存量，默认为物理内存的1/4，比我本机的物理内存是8G，那么最多java虚拟机可以获取到2G。如上所示，从物理角度来说呢，堆内存就是蓝色的区域，从逻辑角度来说,堆内存包含这个红色的部分，调优肯定是条物理的大小了，我们先来看一下物理内存的大小是多少？10M是虚拟机的内存大小，虚拟机分为新生代和老年代，其中新生代占比1/3，而老年代占比2/3，所以这两个的大小就分别为10/3，20/3。一共10M，很容易用完，如果用完会出现什么问题？
动态扩缩容引发的JVM堆内存震荡：从原理到实践的GC调优指南
热门推荐
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
03-09 15万+
本文分析了 JVM 内存弹性机制及其在高负载环境中的挑战，重点探讨了堆内存伸缩、内存扩展与收缩的核心机制。通过对系统发布后 GC 雪崩事件的分析，文章揭示了多代际内存管理中的响应差异，尤其是年轻代、老年代与 Metaspace 的协调问题。为避免这些问题，提出了优化内存配置、调整 GC 策略和合理设置代际大小的解决方案。此外，文章进一步探讨了从被动响应到主动防御的转变，建议结合智能调节与自动化监控机制。
JVM 内存调优：新生代与老年代的比例选择
2501_93878159的博客
11-02 532
在 JVM 内存调优中，新生代（Young Generation）与老年代（Old Generation）的比例设置直接影响垃圾回收效率。$$ \text{Eden 大小} = \text{SurvivorRatio} \times \text{单个 Survivor 大小} $$$$ \text{老年代大小} = \text{NewRatio} \times \text{新生代大小} $$表示老年代与新生代的比例关系，默认值通常为 2（JDK 1.8）。比例调整需在固定堆大小（（新生代:老年代）。
JVM快速调优手册之四 ：堆内存分配的CMS公式解析
weixin_43267534的博客
11-13 642
一.JVM 堆内存组成 Java堆由Perm区和Heap区组成，Heap区由Old区和New区（也叫Young区）组成，New区由Eden区、From区和To区（Survivor）组成。 Eden区用于存放新生成的对象。Eden中的对象生命不会超过一次Minor GC。Survivor Space 有两个，存放每次垃圾回收后存活的对象，即图的S0和S1。Old Generation Old区...
手把手教你设置JVM调优参数
田维常
11-15 1898
关注“Java后端技术全栈”回复“000”获取大量电子书首先，还是一张思维导图，看看本文主要内容：今天来熟悉一下，关于JVM调优常用的一些参数。X或者XX开头的都是非转标准化参数意思就是...
JVM内存比例调节
Java精灵
07-28 2393
我们知道在jdk8之后，堆（heap）分为新生代(Young)，老年代(Old)，和元空间(Metaspace)， 新生代又分为Eden 和Survivor1、Survivor2三个区域（Survivor1对应图中s1,Survivor2对应图中s2） 那么新生代中Eden和s1以及s2的比例是多少呢？怎么调节呢？ 我们可以去Oracle官网去搜索-XX:SurvivorRatio=ratio 可以得知 伊甸园空间大小和幸存者空间大小之间的比例：为8：1：1 确实是如此吗？我们不妨来验证一下 publ
JVM垃圾收集器：原理与调优
我是Java程序员廖志伟，感谢朋友们的支持！不定期贡献一篇高品质、过万文字、图文并茂且附有视频解说、满载代码示例注释的良心之作，坚决杜绝粗制乱造。
09-11 404
在深入探讨Java虚拟机（JVM）的运行机制时，垃圾收集器（Garbage Collector，简称GC）无疑是一个至关重要的组成部分。想象一下，在一个大型企业级应用中，随着业务量的不断增长，系统中的对象数量也在急剧增加。如果这些对象在不再被引用后不能被及时回收，那么内存泄漏将不可避免，最终可能导致系统崩溃。这就引出了垃圾收集器的作用——它负责自动回收不再被使用的对象所占用的内存，从而保证JVM的稳定运行。垃圾收集器的必要性体现在其能够有效避免内存泄漏和减少内存溢出的风险。
触发JVM进行Full GC的情况及应对策略
Java我人生的技术博客
07-01 9万+
Full GC又称作Major GC,属于老年代GC,指发生在老年代的GC，相对这种GC的有新生代GC即Minor GC。出现Full GC的时候经常伴随至少一次的Minor GC,但非绝对的，Major GC的速度一般会比Minor GC慢10倍以上。下边看看有那种情况触发JVM进行Full GC及应对策略。   1、System.gc()方法的调用   此方法的调用是建议JVM进行Fu
单次 CMS Old GC 耗时长问题分析与优化
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
04-10 14万+
本文探讨了 Java 应用中 CMS Old GC 停顿时间过长的问题，分析了可能导致长时间 GC 停顿的原因，如 Full GC、Promotion Failure、内存碎片化等，并提出了相应的优化方案。通过调整 JVM 参数（如增加 Old Generation 内存、减少 Promotion Failure、开启内存压缩等）和提高 GC 并行度，可以有效减少 GC 停顿时间，提高系统性能。
JVM-合理配置堆内存
存在,即合理
08-18 4381
我们增加多少内存比较合适？如果内存过大，那么如果产生FullGC的时候，GC时间会相对比较长，如果内存较小，那么就会频繁的触发GC(吞吐量低)，在这种情况下，我们该如何合理的适配堆内存大小呢？
分析CMS GC退化为单线程串行GC模式的原因与优化
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
03-10 15万+
本文分析了Java CMS（Concurrent Mark-Sweep）垃圾回收器在特定情况下退化为串行GC模式的现象，导致停顿时间显著增加，影响系统性能。文章详细探讨了退化的原因，包括老年代空间不足、并发标记失败、内存碎片化和应用程序中断等，并提出了相应的优化建议，如增加老年代空间、调整GC参数、定期触发Full GC和优化内存分配等。通过合理配置JVM和优化内存管理，可以有效降低CMS退化的风险，提升系统的吞吐量和响应速度，确保Java应用的稳定运行。
CMS GC优化实战：降低请求高峰期GC Remark阶段停顿时间
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
04-23 13万+
本文通过分析CMS GC的Remark阶段在高并发环境中的影响，探讨了如何通过优化CMS GC配置来减少停顿时间。具体包括启用并发预清理机制、强制执行Minor GC等策略，优化后系统的GC停顿时间和吞吐量得到了明显改善，尤其在高峰期，系统的响应能力得到了显著提升。
JVM（五）Parallel GC,CMS GC,G1 GC详解
m0_58466443的博客
08-06 3703
本文详细介绍了JVM中的几种常见GC算法及其实现，包括串行GC、并行GC、CMS垃圾收集器和G1垃圾收集器。串行GC是单线程的，适合小规模应用，而并行GC通过多线程提高吞吐量，但可能导致长时间停顿。CMS GC旨在减少老年代回收时的停顿，通过并发标记和清除阶段减少STW时间，但可能产生内存碎片。G1 GC的目标是实现可预期的停顿时间，通过将堆划分为多个小块并优先回收垃圾最多的区域，G1在并发阶段估算存活对象并执行增量回收，减少停顿时间。G1还引入了Remembered Sets来优化独立回收。
JVM 堆内存如何GC，GC时发生了什么
最新发布
weixin_37926313的博客
12-09 905
JVM 把对象按“寿命”分代管理：短命的在年轻代快速回收，长寿的进老年代集中处理。GC 是内存不足时的“清洁行动”，Young GC 是日常打扫，Full GC 是全城大扫除——我们要做的，就是让大扫除永不发生。
JVM调优实战：解决CMS concurrent-abortable-preclean LongGC的问题
思码堂
03-20 1万+
1. 背景 1.1 多个业务线的应用出现LongGC告警 最近一段时间，经常收到CAT报出来的Long GC告警（配置为大于3秒的为Longgc）。 2. 分析前的一些JVM背景知识回顾 2.1 JVM堆内存划分 新生代（Young Generation） 新生代内被划分为三个区：Eden，from survivor，to survivor。大多数对象在新生代被创建。Minor GC针对的...
JVM 性能调优 -- CMS 垃圾回收器 GC 日志分析【Full GC】
weixin_42118323的博客
11-27 1395
上一篇我们分析了 Minor GC 的发生过程，因为 GC 日志没有按我们预估的思路进行打印，其中打印了 CMS 垃圾回收器的部分日志，本篇我们就来分析一下 CMS 垃圾收集日志。
【深入理解JVM】详解GC日志参数配置及日志分析
程序员云帆哥的博客
07-31 4988
一、首先模拟一个JVM堆内存不足的异常场景。 public class GCTest { public static void main(String[] args) { List<Object> d = new ArrayList<Object>(); while(true){ d.add(new GCTest()); } }...
【JVM】Java虚拟机JVM堆内存调优
No8g攻城狮的博客
01-05 2709
JVM堆内存调优是Java性能优化的重要部分，主要目的是为了确保程序稳定运行并充分利用系统资源。
JVM参数配置推荐
程序员必须坚持写博客，没人看也要写
12-04 1583
JVM GC参数配置
JVM中一次完整的GC回收流程
2301_76166241的博客
01-29 1961
每次执行Minor GC，会将Eden区中存活的对象放到Survivor的From区，而在From区中，仍存活的对象会根据他们的年龄值来决定去向，逃过一次Minor GC年龄。而老年代如果不够了，或者担保失败了，那么就会触发老年代的GC，一般来说，现在用的比较多的老年代的垃圾收集器是CMS或者G1，他们采用的都是三色标记法。还会发生第二件事情就是，在这个过程中，会进行对象的年龄判断，如果他经过一定次数的GC之后，还没有被回收，那么这个对象就会被放到老年代当中去。年老代中存放的都是一些生命周期较长的对象。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

猩火燎猿

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

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

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

打赏作者

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

抵扣说明：

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

余额充值