From/To划分是复制算法高效运行的必要设计，确保每次GC有干净目标空间、避免碎片、支持年龄追踪并提升内存利用率。
复制算法本身要求“一边清空、一边复制”，Survivor区划分为From和To，不是为了多设一个区域，而是让这个算法能真正跑起来——没有明确的From和To，复制就无从下手。
保证每次GC都有干净的目标空间
复制算法的核心前提是：必须有一块完全空闲的内存区域，用来接收存活对象。如果只有一个Survivor区，GC时既要清理死亡对象，又要腾出空间放新复制来的对象，就会面临两个问题：
- 清理过程需就地压缩或标记-清除，破坏了复制算法“整块搬移+直接清零”的高效性；
- 存活对象和待清理垃圾混在同一空间，无法做到“复制完就整体清空”，反而引入碎片或额外遍历开销。
而From/To设计确保To区始终为空——GC启动前，它不存任何有效数据，只等接收Eden和From中筛选出的存活对象。
避免内存碎片，维持连续分配能力
新生代对象生命周期短、创建频繁，Eden区需要持续快速分配。若Survivor区只有一块，多次GC后，对象反复在原地挪动、清理，极易形成不规则空洞。这些碎片会让后续分配失败（即使总空闲空间足够），触发不必要的GC或晋升。
From→To的单向复制天然规避这个问题：每次GC后，To区中的对象是紧凑排列的；Eden和From则被整体归零，下次分配仍从头开始，全程保持内存线性、连续。
支持对象年龄追踪与渐进晋升
对象每经历一次Minor GC且存活，年龄+1。JVM靠From/To交换隐式记录这一过程：
- 对象在From区时年龄为N；
- 复制到To区后，年龄变为N+1；
- 下一轮GC时，原To区变成新的From区，继续参与年龄累加。
这种机制不需要额外维护年龄数组或位图，仅靠空间角色切换就自然承载了生命周期管理。若只有一块Survivor区，年龄更新就容易错乱或依赖更复杂的元数据结构。
让新生代可用空间接近理论上限
单纯按半分内存（如传统半区复制）会浪费50%空间。JVM通过Eden:Survivor = 8:1:1的比例，在保留复制算法优势的同时，把新生代有效利用率拉高到90%：
- 平时使用Eden + 当前From区（共90%）；
- To区作为临时接收区（10%），但它是“借来用的”，不长期占用；
- GC完成后，角色互换，To变From，又可参与下一轮90%的分配。
没有From/To的明确区分，这套动态复用就无法闭环——你没法知道哪块该清空、哪块该写入，更没法协调Eden与Survivor之间的协同节奏。
