复制算法作为jvm新生代gc核心策略未发生语义变更，始终基于eden与两个survivor区的半区复制模型；其演进集中于实现细节、参数调优（如maxtenuringthreshold默认值下调、自适应策略启用）及与g1/zgc等新型收集器的协同优化。
复制算法本身作为JVM内存管理的基础机制，并未在不同JDK版本中发生语义或逻辑层面的变更——它始终是新生代（Young Generation）垃圾回收的核心策略，依赖Eden区与两个Survivor区（S0/S1）构成的半区复制模型。真正演进的是其实现细节、触发条件、参数调优空间以及与新型GC器的协同方式。
新生代结构与复制流程保持稳定
从JDK 5至今，复制算法的基本工作单元仍是“Eden + Survivor”三区结构。Minor GC发生时：
- 存活对象从Eden和其中一个Survivor（如S0）复制到另一个Survivor（S1）
- 年龄计数器+1，达到阈值（默认15）则晋升至老年代
- 原Survivor区（S0）被清空，角色互换
这一流程在G1、ZGC、Shenandoah等现代收集器中依然被沿用——只是G1将“复制”粒度细化为Region级别，而ZGC/Shenandoah在并发标记阶段仍依赖类似复制的重定位（Relocation）逻辑，但已不属传统分代复制范畴。
JDK 8–17：参数精细化与自适应优化
Oracle逐步弱化人工调参依赖，增强JVM对复制行为的自动调节能力：
- -XX:MaxTenuringThreshold 默认值从15降至6（JDK 17起），鼓励更早晋升，缓解Survivor区压力
- -XX:+UseAdaptiveSizePolicy 默认开启（JDK 7u4起），JVM动态调整Eden/Survivor比例，避免因固定比例导致复制失败（如“to-space overflow”）
- Survivor区容量不再硬编码，而是由JVM根据实际晋升率实时估算并收缩/扩张
JDK 21+：虚拟线程场景下的复制轻量化
随着虚拟线程（Virtual Threads）成为正式特性，大量短生命周期对象集中创建，对复制算法提出新要求：
- Eden区分配采用TLAB（Thread Local Allocation Buffer）+ PLAB（Per-Thread Local Allocation Buffer）双层缓存，降低多虚拟线程竞争
- G1在JDK 21中优化了跨Region复制路径，减少卡表（Remembered Set）更新开销
- ZGC虽不使用传统复制，但其“染色指针+读屏障”机制在重定位阶段复现了“原子移动+地址映射”的效果，逻辑上延续了复制算法“避免碎片+连续布局”的设计哲学
不变的核心，变化的支撑
复制算法没有被替代，而是被“封装得更深、调度得更智能、适配得更广”。开发者无需重写代码来适配不同JDK的复制行为，但需关注：
- 升级后观察GC日志中
Desired survivor size与Age threshold是否异常波动 - 启用
-Xlog:gc+age=debug（JDK 10+）可追踪对象年龄分布，验证晋升策略是否合理 - 在高吞吐微服务中，可配合
-XX:+AlwaysPreTouch预触内存页，减少复制过程中的缺页中断
