parallel收集器采用jvm自主管理的固定线程池，在stw期间并行执行gc子任务，通过任务划分、窃取机制和内存屏障实现高效负载均衡与强一致性，吞吐量优先但无并发阶段。
Parallel收集器在多线程环境下不依赖操作系统级线程调度，而是由JVM内部的GC任务调度器统一管理——它把一次GC任务拆解为多个可并行执行的子任务（如扫描某段Eden、处理某组Root引用、复制某块存活对象），再分发给固定数量的GC工作线程协作完成。
GC线程池由JVM自主控制
Parallel GC启动时会创建一个固定大小的GC线程池（默认线程数 = CPU核心数），这些线程在GC触发前处于等待状态，不参与应用逻辑执行；一旦进入STW阶段，JVM直接唤醒全部GC线程并发执行预分配的任务，无需竞争锁或等待OS调度。这种“即用即启、用完即停”的模式避免了频繁线程创建/销毁开销，也绕开了用户态线程调度的不确定性。
- 线程数可通过-XX:ParallelGCThreads=N显式设置，设为0时自动按CPU核心数推算
- 线程数超过物理核心数反而可能因上下文切换增多而降低效率
- GC线程始终以最高优先级运行，确保尽快结束STW
任务划分与负载均衡机制
新生代回收（Parallel Scavenge）将Eden和From Survivor空间划分为多个内存块（stripes），每个GC线程负责扫描和复制其中一部分；老年代回收（Parallel Old）则将堆内存按页或区域切分，各线程独立标记、独立压缩不同段。JVM通过GCTaskQueue分发任务，并内置Steal Task机制——当某线程提前完成自己分配的任务，会主动从其他线程的任务队列中“窃取”剩余任务，防止个别线程空转。
- 任务粒度适中：太细增加调度开销，太粗导致负载不均
- 跨代引用（Old→Young）单独建模为OldToYoungRootsTask，由专用线程并行扫描
- GC Root枚举（如JNI句柄、系统字典）也被拆成多个子任务并发处理
协同过程严格遵循STW节奏
所有GC线程的协作完全发生在Stop-The-World窗口内：初始标记和重新标记阶段虽短，但必须全体同步；并行标记与并行清理阶段允许多线程同时推进，但任何线程都不能脱离全局一致的内存视图——JVM通过写屏障（Write Barrier）或内存屏障（Memory Barrier）保证对象引用更新对所有GC线程实时可见，避免漏标或重复处理。
- 没有“后台GC线程”概念：Parallel GC不存在并发标记阶段，所有工作都在STW中完成
- 线程间不共享对象复制目标地址，To Survivor区或老年代压缩目标位置由各线程本地计算，避免写冲突
- 晋升失败（promotion failure）等异常情况由主GC线程统一判定并触发Full GC降级流程
与应用线程的隔离与配合
GC线程与Java应用线程物理隔离：GC期间所有Java线程被挂起，其栈帧、寄存器状态冻结；GC线程只读取堆中对象数据，不修改应用线程的局部变量或调用栈。这种强隔离简化了并发控制逻辑，但也意味着Parallel GC无法像CMS或G1那样实现部分并发——它的吞吐量优势正来自这种“全停全干”的确定性协作模式。
- 应用线程恢复前，GC线程必须完成所有对象移动、指针更新和空间清零
- 年轻代回收后自动交换From/To Survivor区，该操作由单一线程原子完成，其余线程等待同步
- 老年代压缩后的内存布局由GC线程统一维护，确保后续对象分配能快速定位空闲区域
