垃圾收集器通过堆内存实际使用状态被动响应压力：eden区满触发minor gc，老年代水位超阈值启动并发标记或full gc，结合gc事件反馈、分配速率、晋升行为及容器约束动态调优。
垃圾收集器感知 JVM 内存压力，不是靠“猜测”或“轮询”，而是通过堆内存的实际使用状态和 GC 事件的触发条件被动响应。它不主动监测系统负载或 CPU 使用率，而是紧盯堆中各代（年轻代、老年代）的占用水位、对象分配速率、晋升行为等核心指标——这些才是真实、可量化的内存压力信号。
堆空间水位触发型回收
当 Eden 区填满时，必然触发 Minor GC；当老年代使用率超过阈值（如 G1 的 -XX:InitiatingOccupancyPercent 默认45%，CMS 的 -XX:CMSInitiatingOccupancyFraction 默认92%），就会启动并发标记或 Full GC。这个“水位”是 GC 最直接的压力感知方式——不是内存够不够用，而是“快撑不住了”。
- Eden 满 = 年轻代压力显性爆发，触发复制式回收
- 老年代使用率持续攀升 = 长期对象堆积，预示晋升失败或内存泄漏风险
- 元空间（Metaspace）达到 -XX:MaxMetaspaceSize 限制 = 类加载过载，可能引发 Metaspace OOM
GC 事件反馈驱动的自适应调整
现代收集器（如 G1、ZGC、Shenandoah）会记录每次 GC 的实际效果：停顿时间、回收量、晋升数量、失败次数。如果连续几次 Minor GC 后，大量对象快速晋升到老年代，或老年代在 GC 后仍剩余过高比例，收集器会动态调高回收频率或提前启动并发周期——这是基于历史行为的“压力学习”。
- G1 通过 -XX:MaxGCPauseMillis 设定目标停顿，若实际超时，会自动缩小 GC 工作范围或增加并发线程数
- ZGC 每次 GC 后评估堆使用增长速率，若发现分配速度远超回收速度，会加快 GC 周期节奏
- 频繁发生 Promotion Failure（晋升失败）或 Evacuation Failure（转移失败），说明年轻代太小或老年代碎片化严重，属于高危压力信号
分配速率与晋升行为暴露隐性压力
即使还没触发 GC，JVM 也在持续观察对象分配节奏。比如：Eden 区在几毫秒内就被填满，或 Survivor 区存活对象激增、年龄快速达标，都意味着应用正在高频创建短生命周期对象——这虽不立即导致 OOM，但已构成隐性内存压力，会影响 GC 策略选择（如是否启用自适应大小策略 -XX:+UseAdaptiveSizePolicy）。
- 高分配速率 → 更频繁 Minor GC → 增加 CPU 开销和 STW 次数
- 大对象直接进入老年代（绕过年轻代）→ 老年代碎片风险上升 → 可能诱发 Concurrent Mode Failure
- 动态年龄判定被频繁触发（Survivor 区半区满即晋升）→ 表明对象存活率异常升高，需检查业务逻辑或缓存设计
外部监控与人工干预作为补充信号
GC 自身不读取操作系统内存或容器限制，但可通过 JVM 参数间接感知环境约束。例如设置 -XX:+UseContainerSupport（JDK10+）后，JVM 会从 cgroup 中读取容器内存上限，并据此自动调整堆大小（配合 -XX:InitialRAMPercentage 等参数）。此时，容器内存压力就转化为 JVM 堆配置压力，进而影响 GC 行为。
- 未开启容器支持时，JVM 只认 -Xmx，超出即 OOM，无预警
- 开启后，若容器内存被其他进程挤占，JVM 可能因无法申请新页而触发更激进的 GC 或直接抛出 Native OOM
- Arthas、JFR、Prometheus + JVM Exporter 等工具采集的
MemoryPoolUsage、GcPauseTime、GcCount指标，是运维侧识别压力的关键依据
