Java中不存在真正并发的复制算法，所有复制操作（如Young GC）均需STW，因其核心步骤——遍历、拷贝、更新引用——必须保证原子性与一致性；所谓“并发”仅体现在标记等辅助阶段。
Java中并不存在严格意义上的“并发复制算法”作为独立的GC算法标准实现。主流JVM（如HotSpot）的复制算法本身是暂停式（STW）的，它依赖内存区域隔离（如Eden + Survivor）和对象朝生夕死的特性来高效工作；而“并发”行为主要出现在标记与清理阶段（如CMS、G1、ZGC），并非在复制动作本身。
为什么复制过程难以真正并发
复制算法的核心步骤包括：遍历存活对象、读取其引用字段、将对象字节完整拷贝到新内存位置、更新所有指向该对象的引用（即“转发指针”或“写屏障修正”）。这些操作必须保证原子性与一致性——若应用线程在复制中途修改了某对象的字段，或正在读取一个尚未完成复制的对象地址，就可能引发数据错乱或崩溃。因此，现代JVM中所有基于复制的GC阶段（如Young GC）都采用STW方式执行。
即使像G1的Mixed GC中涉及部分Region的复制，其复制环节仍是STW的；所谓“并发”，仅体现在标记（Concurrent Marking）和部分记忆集（Remembered Set）维护等辅助工作上。
常见误解：“ParNew + CMS”不是并发复制
有人误以为ParNew（新生代并行收集器）配合CMS（老年代并发收集器）构成了“并发复制”，其实：
- ParNew是并行（Parallel）而非并发（Concurrent）：多个GC线程协同完成一次Minor GC，但全程暂停应用线程；
- CMS的老年代回收用的是标记-清除，不复制对象，只清理未标记空间；
- CMS不处理新生代，它默认依赖ParNew或Serial进行年轻代回收——这部分仍是STW复制。
真正接近“并发复制”的探索方向
一些前沿GC设计尝试弱化复制的停顿影响，但仍未脱离STW本质：
- G1的增量式混合回收：每次只选收益高的若干Region进行复制（如Eden + 部分Old），缩短单次STW时间，但复制动作本身仍需暂停；
- ZGC / Shenandoah：通过读屏障（Load Barrier）和染色指针（Colored Pointers）或Brooks Pointer实现对象移动的“几乎并发”，允许应用线程在对象被迁移过程中继续访问旧地址，并自动重定向。但这属于并发移动（concurrent relocation），技术复杂度极高，且不等同于传统复制算法的语义；
- 分代+快照隔离思路：如某些实验性运行时用COW（Copy-on-Write）页机制延迟复制，但JVM规范与HotSpot未采用。
实际选型建议
如果你关注低延迟场景下的复制效率，应聚焦以下可调点：
- 调整年轻代大小与Survivor比例（如-XX:SurvivorRatio=8），提升复制局部性与缓存友好性；
- 启用G1并设置合理目标停顿（-XX:MaxGCPauseMillis=20），让它自动选择复制哪些Region；
- 在JDK 11+生产环境，可评估ZGC（-XX:+UseZGC）或Shenandoah（-XX:+UseShenandoahGC），它们把对象移动从STW中剥离，但代价是更高CPU开销与更复杂的内存管理逻辑。
