要避免高频率Minor GC，核心是让新生代撑得更久：增大新生代至堆的3/8–1/2，调大SurvivorRatio至6以提升Survivor占比，设置PretenureSizeThreshold避免大对象直入老年代，并通过GC日志与jstat监控验证效果。
要避免高频率 Minor GC，核心是让新生代能“撑得更久”——既不让 Eden 区太快填满，也不让对象过早晋升到老年代。关键不在堆总大小，而在新生代内部空间分配与对象生命周期管理是否合理。
增大新生代空间，缓解 Eden 压力
新生代太小是最常见诱因。默认情况下（如 -XX:NewRatio=2），新生代只占堆内存约 1/3，高并发场景下几秒就满。
- 优先用
-Xmn直接指定新生代大小，比如-Xmn2g；比靠比例更可控。 - 推荐设为堆内存的 3/8 到 1/2（例如总堆 6G，新生代设 2.5–3G）。
- 配合监控看
jstat -gcutil <pid> 1000中 E 列（Eden 使用率）：若经常在 1–2 秒内从 0% 跳到 95%+，说明 Eden 确实太小。
调优 Survivor 区，防止对象“早退休”
Survivor 区太小会导致存活对象无法容纳，触发“动态年龄判定”，哪怕只经历 2 次 GC 就被推去老年代，加剧老年代压力并间接抬高 Minor GC 频率。
- 用
-XX:SurvivorRatio=6（Eden:S0:S1 = 6:2:2），把 Survivor 总占比从默认 20% 提升到 ~33%。 - 观察
jstat输出中 S0/S1 的使用率：若长期 >70%，说明 Survivor 不够用；若长期 - 必要时配合
-XX:MaxTenuringThreshold固定晋升年龄（如设为 6 或 8），避免 JVM 动态下调阈值。
控制对象创建节奏，从代码源头减压
再大的新生代也扛不住每毫秒都在 new 对象。高频 Minor GC 往往暴露的是代码问题。
- 避免循环内创建对象：如
new ArrayList()、new SimpleDateFormat()、反复拼接字符串（改用StringBuilder复用）。 - 复用可变对象：工具类方法尽量接收缓冲区参数（如
byte[]、char[]），而非每次都 new。 - 谨慎使用大对象：单次分配 >1MB 的对象（如大数组、大 JSON 解析结果）会绕过 Eden，直接进老年代；若不可避免，用
-XX:PretenureSizeThreshold=1048576显式控制。
必须开启 GC 日志，用数据验证调优效果
所有参数调整都需以日志为依据，不能凭经验猜测。
- 启动时加参数：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log。 - 用 GCeasy 或
GCViewer分析日志，重点关注：
— Minor GC 间隔是否拉长
— 每次 GC 后 Eden 是否真正清空
— 晋升到老年代的字节数是否明显下降 - 调优后对比 YGC 次数和平均耗时：理想状态是次数减少 30%+，单次耗时基本稳定或略降。
