分代收集模型的核心是控制对象流向而非减少gc次数。需合理配置年轻代、防止早晋老年代、监控老年代增长趋势，并以压测基线数据指导调优。
分代收集模型的核心不是追求某一种GC“越少越好”，而是让对象在合适的代里待够时间，再自然流转——Minor GC该频繁就频繁，Full GC该稀少就稀少。关键在于避免错配：不该进老年代的进了，不该晋升的提前晋升，或者老年代被无效对象占满。平衡点不在“压低次数”，而在“控制流向”。
看住年轻代配置，别让Minor GC失序
Minor GC本身不可怕，怕的是它失控。如果每秒触发多次，说明Eden区太小或对象分配太快。此时不是盲目调大堆内存，而是先确认：
- Eden与Survivor比例是否合理（默认8:1:1，但业务若产生大量中生命周期对象，可尝试调为6:2:2）
- Survivor区是否长期高水位（GC日志中看Survivor after-used是否持续＞90%）——过高意味着对象“卡”在年轻代出不去，要么是年龄阈值设太高，要么是动态晋升规则被频繁触发
- 是否存在循环内新建大对象、字符串拼接未用StringBuilder等导致Eden快速填满的代码模式
管好对象去向，从源头减少Full GC诱因
90%以上的非预期Full GC，源于对象不该进老年代却进了。重点关注三类“早晋”场景：
- 大对象直入老年代：数组、长字符串等超过-XX:PretenureSizeThreshold（如4MB）会跳过年轻代。若业务确实需要大缓存，可接受；若只是临时日志或中间结果，应拆解或复用
- Survivor空间不足被迫晋升：一次Minor GC后，存活对象总大小＞Survivor容量，JVM只能把它们全推给老年代。这时哪怕老年代还空，也会埋下隐患
- 动态年龄晋升：Survivor中某年龄段对象总和＞50%，同龄及更老的对象直接进老年代。这本是自适应机制，但如果某次批量任务集中创建一批“同龄”中生命周期对象，就会批量涌入老年代
老年代不是垃圾桶，得有“准入门槛”和“清理节奏”
Full GC频率高，本质是老年代成了“慢速垃圾场”。要让它保持健康：
- 监控老年代占用趋势：不是看瞬时使用率，而是看每小时增长量。若稳定上涨且无回落，大概率存在内存泄漏或缓存未设上限
- 避免显式触发：禁用System.gc()，加-XX:+DisableExplicitGC参数；RMI默认会调gc，也需关闭
- 元空间（Metaspace）别忽略：类加载过多（如热部署、动态代理泛滥）会导致Metaspace满而触发Full GC，可通过-XX:MaxMetaspaceSize限制并观察告警
- 担保失败（Handle Promotion Failure）要留余地：确保-XX:+HandlePromotionFailure开启，并预留老年代空间 ≥ 历次晋升平均大小 × 1.5，防止Minor GC中途退化为Full GC
用数据定策略，而不是凭经验猜
没有统一“正常值”，只有你系统的基线。上线前跑压测，记录以下指标：
- 单次Minor GC耗时（目标＜50ms）、频率（如QPS 2000服务，通常20~60秒一次较稳）
- Minor GC后老年代增量（理想情况每次＜1MB；若达几十MB，说明晋升失控）
- Full GC间隔（健康服务应≥24小时；若＜2小时，必须介入）
- GC总停顿占比（建议＜3%，超5%已影响吞吐）
这些数字才是调优的锚点。改一个参数，至少观察一小时真实流量下的GC行为变化，再决定下一步。
