jvm垃圾回收器的多线程策略聚焦于gc线程协作与用户线程交互，而非业务同步；并行回收器依赖stw+任务划分/cas/无锁栈实现高效协同，并发回收器则依托安全点、写屏障和三色标记保障一致性。
JVM 垃圾回收器本身不负责“多线程同步”——它不协调应用线程之间的共享数据访问，而是通过 Stop-The-World（STW）机制 来规避并发冲突。所谓“多线程同步策略”，实质是回收器如何在多线程环境下安全、高效地执行垃圾回收任务，核心在于 线程协作方式 和 与用户线程的交互模型，而非 Java 中 synchronized 或 Lock 那类同步原语。
并行回收器依赖 STW 实现线程间协同
Parallel Scavenge、Parallel Old 等并行回收器使用多个 GC 线程并行工作，但前提是所有用户线程必须暂停。此时 GC 线程之间通过以下方式协作：
- 任务划分：将堆内存按区域（如卡表 Card Table、对象区间）静态或动态切分，各 GC 线程独立处理分配给自己的子任务
- 共享元数据同步：使用原子操作（如 CAS）更新全局统计信息（如晋升对象数量、已扫描对象数），避免锁竞争
- 无锁工作栈：每个 GC 线程维护本地待处理对象队列（如标记阶段的灰色对象栈），仅在队列空时才从全局队列窃取任务，减少同步开销
并发回收器靠安全点与增量更新保障一致性
CMS 和 G1 在部分阶段允许用户线程与 GC 线程并发运行，此时必须保证对象图状态的一致性：
- 安全点（Safepoint）：用户线程只能在预设的安全点位置被暂停，确保寄存器和栈中引用状态稳定，GC 线程可准确枚举 GC Roots
- 写屏障（Write Barrier）：在用户线程修改对象引用字段时插入轻量级钩子，用于记录跨代引用（如新生代→老年代）、维护记忆集（Remembered Set）或触发增量更新（Incremental Update）
- 三色标记法 + 增量更新：G1/CMS 使用黑白灰三色标记存活对象；为防止用户线程在并发标记中“漏标”，写屏障会把被修改引用的对象重新标记为灰色，加入扫描队列
不同回收器对线程模型的取舍逻辑
选择哪种线程协作方式，取决于设计目标的优先级：
- 追求吞吐量（如 Parallel）：接受较长时间 STW，用多线程加速单次回收，减少总 GC 时间占比
- 追求低延迟（如 G1、ZGC）：尽量缩短或消除 STW，用写屏障、并发标记、读屏障等机制承担额外 CPU 开销，换取更可控的停顿
- 资源受限场景（如 Serial）：放弃多线程收益，用单线程避免上下文切换与同步成本，在小内存或单核设备上反而更稳
本质上，JVM 垃圾回收器的“多线程策略”不是为了同步业务逻辑，而是围绕内存一致性和回收效率，构建一套受控的并发执行框架——它用 STW 划清边界，用写屏障捕捉变化，用安全点锚定状态，最终让多线程 GC 成为可能且可靠。
