垃圾收集器中的并发复制算法解析

Ja va中不存在真正并发的复制算法，所有复制操作（如Young GC）均需STW，因其核心步骤——遍历、拷贝、更新引用——必须保证原子性与一致性；所谓“并发”仅体现在标记等辅助阶段。

先说一个核心判断：Ja va里并不存在严格意义上的“并发复制算法”作为独立标准实现。主流的HotSpot JVM，其复制算法本质上是暂停式的（STW），靠Eden区加Survivor区的内存隔离以及对象“朝生夕死”的特性来高效运作。所谓的“并发”，主要出现在标记与清理阶段（比如CMS、G1、ZGC），而不是复制动作本身。这一点，值得一开始就讲清楚。

为什么复制过程难以真正并发

复制算法的核心步骤包括：遍历存活对象、读取其引用字段、把对象字节完整拷贝到新内存位置、然后更新所有指向该对象的引用（也就是转发指针或写屏障修正）。这些操作每一步都得保证原子性与一致性——你想想，假如应用线程在复制中途修改了某个对象的字段，或者正在读取一个还没完成复制的对象地址，数据立马就乱套了。所以，现代JVM里所有基于复制的GC阶段（比如Young GC）都得采用STW方式来执行。

即使像G1的Mixed GC，其中涉及部分Region的复制，复制环节仍然是要停顿的；所谓“并发”，仅仅体现在标记（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），让GC自动选择哪些Region去复制；
• 在JDK 11+的生产环境中，可以评估ZGC（-XX:+UseZGC）或Shenandoah（-XX:+UseShenandoahGC）。它们把对象移动从STW中剥离了出来，代价是更高的CPU开销和更复杂的内存管理逻辑。

话说回来，理解复制算法“为什么不能并发”比记住结论更重要——它直接决定了GC调优时哪些参数真正有效。