这个参数控制的是老年代使用率达到多少时触发CMS GC，但它的实际生效受JVM版本和GC策略影响很大，不是简单设个数值就立刻起作用。
参数含义与触发条件
XX:CMSInitiatingOccupancyFraction=N 表示当老年代已使用空间占整个老年代容量的比例 ≥ N% 时，尝试启动CMS并发收集。注意是“尝试”，不是“保证”：
- 必须配合 -XX:+UseConcMarkSweepGC 使用（JDK 9+ 已移除）
- JDK 7u4 之后默认启用 JVM 自适应阈值（-XX:+UseCMSInitiatingOccupancyOnly 可禁用该自适应）
- 若未显式设置，JVM 会根据历史GC数据动态计算初始阈值（通常在 60%~90% 之间浮动）
- 即使达到阈值，若 CMS 正在进行中、或内存分配速率过快导致连续失败，也可能跳过本次触发
调优目标与常见取值逻辑
核心目标是：在并发标记完成前，老年代仍有足够空闲空间容纳新晋升对象，避免出现 concurrent mode failure（退化为 Serial Old）。
- 设得太低（如 30%）：CMS 触发过于频繁，CPU 开销大，吞吐下降
- 设得太高（如 95%）：极易触发 concurrent mode failure，造成长时间 STW
- 经验值起步点：65%～75%，再结合 GC 日志中的 “concurrent mode failure” 和 “time for full gc” 频次调整
- 若应用对象生命周期长、晋升稳定，可适当提高（如 80%）；若晋升波动大、突发流量多，建议保守设为 60%～65%
依赖的关键监控指标
单看这个参数没意义，必须结合 GC 日志分析：
立即学习“Java免费学习笔记（深入）”；
- 每次 CMS GC 前老年代使用率（日志中 “concurrent mode failure” 前的 [ParOldGen: X->Y(K)]）
- CMS 并发周期耗时（特别是 concurrent-mark 和 concurrent-sweep 阶段时间）
- 是否频繁出现 “Abortable Preclean” 超时或 “Rescan” 时间过长
- Full GC 是否由 concurrent mode failure 引发（日志含 “concurrent mode failure” 字样）
典型调优操作步骤
不是一次设完就结束，而是观察→分析→微调→再观察的闭环：
- 开启详细 GC 日志：-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
- 先不设该参数，让 JVM 自适应运行 1～2 天，记录平均触发点和是否失败
- 若频繁失败，下调 5～10 个百分点（如从 75% → 65%），并加 -XX:+UseCMSInitiatingOccupancyOnly 锁定阈值
- 若 CMS 频繁但无失败，且应用延迟敏感，可尝试小幅上调（每次 +3%～5%），观察并发周期是否仍能及时完成
- 配合 -XX:CMSMaxAbortablePrecleanTime=XXX 控制预清理时长，避免因 preclean 超时导致提前失败
