S0和S1必须成对存在以支持复制算法实现无碎片、安全的对象转移。二者大小相等、角色动态翻转，仅通过指针重定向切换“空闲接收区”，不移动数据；单独禁用或配置不均会导致GC异常或过早晋升。
Survivor区S0和S1为什么必须成对存在
因为JVM新生代的复制算法要求「每次GC只保留一个存活对象副本」，而S0和S1就是为避免内存碎片、实现无停顿对象转移设计的双缓冲结构。没有这对区域，Minor GC就无法安全地把存活对象从Eden区搬走——搬过去没地方放，或者搬过去覆盖自己。
常见错误现象：OutOfMemoryError: GC overhead limit exceeded 有时就源于Survivor区过小，导致对象频繁被提前晋升到老年代，加剧老年代压力。
- S0和S1大小必须严格相等，由
-XX:SurvivorRatio控制（如-XX:SurvivorRatio=8表示Eden:S0:S1 = 8:1:1） - 不能通过配置单独禁用某一个Survivor区；JVM启动时就固定了S0/S1角色，但具体哪边是“空闲接收区”由GC时动态决定
- 如果
SurvivorRatio设得过大（比如32），S0/S1太小，小对象也容易因空间不足直接进入老年代
每次Minor GC后S0和S1是怎么交换的
不是靠“名字切换”，而是GC过程里JVM内部指针重定向：把当前“空”的Survivor区（比如S1）标记为本次GC的目标复制区，所有Eden + 当前使用中的Survivor（S0）里的存活对象，全部复制到S1；复制完成后，S1变成新的“已用区”，S0清空并转为下一轮的“目标复制区”。这个翻转动作在CopyTask执行末尾完成，不涉及数据移动，只是元信息更新。
典型误解：以为S0永远叫S0、S1永远叫S1。实际上日志里看到的S0 used或S1 used数值跳变，正是翻转发生的证据。
- 可通过
-XX:+PrintGCDetails观察GC日志中PSYoungGen段的before/after里S0/S1占用变化 - 翻转不耗时，但若某次GC后发现S0和S1占用都接近100%，说明有大量对象熬过一次GC却无法晋升（可能因为
MaxTenuringThreshold设得太高或对象太大） - 使用G1或ZGC时这套机制不存在——它们不用复制算法管理新生代
对象在S0/S1之间“来来回回”是不是有问题
不是问题，是预期行为。只要对象年龄age没达到MaxTenuringThreshold，它就会在S0↔S1之间随每次Minor GC翻转一次。每次复制，JVM都会给对象头里的age字段+1。只有age ≥ MaxTenuringThreshold，才会被移到老年代。
容易踩的坑：把MaxTenuringThreshold设成0，等于禁止在Survivor区停留，所有存活对象下一次GC就进老年代——这会快速撑爆老年代，尤其在短生命周期对象多的场景（如Web请求临时对象）。
-
MaxTenuringThreshold默认值是15（CMS是6），但实际有效上限受对象大小和Survivor容量限制 - 对象大小超过Survivor区一半时，JVM可能直接将其分配到老年代（
HandlePromotionFailure逻辑），哪怕age还很小 - 用
jstat -gc可查看当前S0C、S1C、EC及各区内存使用，辅助判断是否该调SurvivorRatio
复制算法下Survivor区调优的关键信号
真正需要干预Survivor配置，往往不是因为“看不懂轮转”，而是日志或监控暴露了异常模式：比如S0/S1长期一边高一边低、GC后Survivor占用率不降反升、或tenuring distribution显示大量对象卡在age=1~2不动。
这时候重点不是改名字或方向，而是检查三件事：对象平均生命周期是否真长、是否有大数组/缓存类对象意外滞留、以及GC触发频率是否过高导致来不及晋升。
- 开启
-XX:+PrintTenuringDistribution，看每次GC后各age档位的对象大小分布 - 若发现age=1对象占比持续超70%，且Survivor总空间利用率>80%，大概率该调大
-Xmn或调小-XX:SurvivorRatio - 注意：OpenJDK 15+默认使用G1，
SurvivorRatio对G1无效；只有Parallel GC和Serial GC才真正依赖这套S0/S1轮转
Survivor区轮转本身很稳定，出问题的几乎从来不是轮转逻辑，而是对象行为和参数没对齐——比如给短活对象配了过高的晋升阈值，或者让本该进老年代的大对象反复挤占Survivor空间。
