Survivor空间不足最直接信号是GC日志中出现“to-space overflow”“Survivor space exhausted”或“Evacuation failed”；需结合from/to使用率异常、Promotion Failed、晋升年龄骤降及老年代非正常增长等特征综合判断。
直接看 GC 日志中是否出现明确的“to-space overflow”“Survivor space exhausted”或“Evacuation failed”字样，这是 Survivor 空间不足最直接、最可靠的信号。
识别 Survivor 溢出的关键日志特征
不是所有 Minor GC 日志都体现 Survivor 压力，要重点抓三类典型输出：
-
Young GC 中带 (to-space overflow)：例如
[GC pause (G1 Evacuation Pause) (young) (to-space overflow)]，说明本次复制疏散时，目标 Survivor 区（to-space）容量已满，部分对象被迫绕过 Survivor 直接晋升到老年代 -
ParNew/PSYoungGen 日志里 from/to 空间使用率异常高：比如
from space 104832K, 98% used或to space 104832K, 0% used但紧接着下一次 GC 就报溢出——说明 Survivor 区太小，刚腾空就立刻被填满 -
伴随 Promotion Failed 或 Full GC 触发：日志中出现
[GC (Promotion Failure)]或紧随 Minor GC 后立即发生 Full GC，往往是 Survivor 装不下、老年代又没空间接收晋升对象导致的连锁失败
结合内存变化趋势交叉验证
单看一行日志容易误判，需对照前后多轮 GC 的数值变化：
- 观察年轻代回收后 存活对象大小是否持续接近或超过 Survivor 容量：例如日志显示
ParNew: 8192K->8192K(9216K)，即 GC 后存活对象占满整个年轻代可用空间（Eden + 一个 Survivor），说明 Survivor 实际未起作用，对象几乎全在 Eden 里“原地复活” - 检查 晋升年龄（age）字段是否远低于 MaxTenuringThreshold：如日志中写
new threshold 1 (max 6)且age 1: 55521392 bytes占比极高，说明大量对象在第一次 GC 就晋升，根本没机会在 Survivor 中周转 - 对比多次 Minor GC 后 老年代使用量是否非正常上升：比如连续几次 GC 都显示
[ParOldGen: 5120K->72000K]，增长远超合理晋升速率，大概率是 Survivor 不足导致的过早晋升
辅助工具与命令快速定位
人工翻日志效率低，可用以下方式批量确认：
- 用
grep -i "overflow\|evacuation.*fail\|promotion.*fail" gc.log快速筛选溢出相关事件 - 用
jstat -gc <pid>查看实时 Survivor 容量与使用量：S0C/S1C是每个 Survivor 区容量，S0U/S1U是当前使用量；若长期S0U ≈ S0C或频繁在 S0/S1 之间翻转逼近上限，即存在瓶颈 - 开启
-XX:+PrintAdaptiveSizePolicy，让 JVM 输出其对 Survivor 大小的动态调整决策，可判断是否因硬编码参数（如-XX:SurvivorRatio）锁死了空间伸缩能力
不复杂但容易忽略：Survivor 不足往往不是空间绝对值太小，而是与对象分配节奏、生命周期分布不匹配。盯住日志里的“溢出”字眼+“晋升年龄骤降”+“老年代缓涨”，三者同时出现，基本就能锁定问题。
