垃圾收集器无法同时优化GC时间和内存占用，需依应用需求取舍：缩短停顿需更多内存与CPU开销（如G1/ZGC的元数据），小堆则易致GC频繁、停顿难控，平衡依赖运行态监控与反馈。
垃圾收集器无法同时把 GC 时间和内存占用都压到最低，必须根据应用实际需求做取舍。这两个目标天然存在张力：想缩短停顿时间，就得增加并发开销、预留更多内存；想节省内存，往往就得接受更频繁或更长的 GC 暂停。
停顿时间短通常意味着内存开销上升
以 G1 和 ZGC 为例，它们通过并发标记、并发整理等机制把单次 STW 控制在毫秒级。但这些操作本身要占用额外 CPU 和堆内存：G1 需维护记忆集（Remembered Set）记录跨 Region 引用，ZGC 要为每个对象保留着色指针和重映射缓冲区。堆越大，这些元数据占用越多；Region 划分越细（如 -XX:G1HeapRegionSize=1M），碎片减少但管理成本上升。
- G1 默认最大停顿目标是 200ms，设为 50ms 后，它会主动缩小每次回收范围，导致 GC 更频繁，总体内存利用率下降
- ZGC 要求堆大小按 2MB 对齐，且软堆上限（-XX:SoftMaxHeapSize）不设时，JVM 可能预留远超实际需要的空间
- 频繁触发小规模回收虽降低单次停顿，却抬高 GC 总耗时占比，间接推高内存“有效利用率”
内存受限时 GC 时间往往难以控制
当堆被硬限制在较小范围（如 -Xmx512m），Minor GC 间隔大幅缩短。Eden 区很快填满，Survivor 空间不足以容纳存活对象，大量对象提前晋升至老年代——这不仅增加 Full GC 风险，也让每次 Minor GC 的扫描和复制动作更密集，整体 GC 时间占比升高。
- 小堆下 Parallel GC 有时比 G1 更稳，因后者 Region 管理开销在总内存中占比过高
- 新生代比例调高（如 -XX:NewRatio=1）可加快短命对象清理，但 Survivor 区容易溢出，直接触发担保失败和 Full GC
- 大对象（如 >512KB 的 byte[]）绕过年轻代直入老年代，一次分配就可能触发 Mixed GC，打断正常执行节奏
元空间和类加载也影响内存与 GC 平衡
元空间使用本地内存，但未设上限（-XX:MaxMetaspaceSize）时，动态生成类（如 Spring CGLIB、Groovy 脚本）会悄悄吃掉数百 MB，挤占堆可用空间，间接拉长 GC 周期。而频繁类卸载又可能触发额外的 Full GC。
- 建议显式设置 -XX:MaxMetaspaceSize，并监控 Metaspace 使用曲线
- 避免运行时大量生成匿名类或代理类，尤其在长生命周期容器中
- 元空间不足引发的 Full GC 不是堆内存问题，但会带来同等程度的 STW，容易被误判
真正有效的平衡靠运行态反馈，不是静态参数
GC 行为高度依赖实际对象生命周期分布、分配速率和引用图结构。同一套参数在压测环境表现良好，上线后可能因真实流量模式变化而失衡。关键不是“设对某个值”，而是建立可观测闭环：开启 -Xlog:gc*:file=gc.log，用 GCViewer 或 Prometheus + Grafana 跟踪 Pause Time、Throughput、Heap Usage 三者趋势，再反向调整。
- 关注 GC 日志里的 “Total time for which application threads were stopped” 和 “Application time” 比值
- 观察老年代增长斜率是否平缓，突增往往预示内存泄漏或缓存失控
- Minor GC 后 Eden 清空率长期低于 90%，说明 Survivor 配置或对象年龄阈值不合理
