serial收集器不适合堆内存较大的系统，因其单线程stop-the-world机制导致停顿时间随堆增大而线性增长，无法利用多核资源，且缺乏大堆优化策略如并发标记、增量回收等。
Serial收集器不适合堆内存较大的系统，核心原因在于它的单线程 Stop-The-World（STW）机制会随堆规模扩大而显著恶化停顿时间，且无法通过增加硬件资源缓解。
单线程回收导致STW时间线性增长
Serial全程只用一个线程扫描、标记、复制或整理对象。当堆变大（比如从100MB升至2GB），存活对象数量和需处理的内存区域成倍增加，GC耗时几乎线性上升。例如：
- 几十MB堆时，Young GC可能仅10–30ms；
- 512MB堆下Full GC在Serial Old上常超300ms；
- 2GB堆+大量老年代对象时，一次Full GC可能卡住秒级——这对任何交互式或服务类应用都是不可接受的。
无法利用多核资源，失去伸缩能力
现代服务器普遍是4核起步，Serial却始终只用1个CPU核心工作。它不支持并行标记、并发扫描或增量整理。即使你加内存、加CPU，Serial的吞吐和延迟都不会改善，反而因堆增大更慢。相比之下，Parallel能用N个线程分摊工作，G1可并发标记+分区回收，天然适配大堆。
小堆优势在大堆中反转为劣势
Serial的轻量、低元数据开销，在小堆下是优点；但堆一大，这些节省的内存就微不足道，而单线程瓶颈立刻成为主要矛盾。它没有写屏障、不维护卡表、不区分记忆集——这些“省下来”的设计，在大堆场景下换不来性能，只换来更长、更不可控的停顿。
缺乏应对大堆的配套策略
Serial Old采用标记-整理算法，虽能避免碎片，但必须移动所有存活对象。大堆中移动GB级对象不仅耗时，还会加剧缓存失效和内存带宽压力。它也不支持增量回收、软引用优先处理、或根据GC日志动态调优——这些在G1、ZGC中已是标配，却是Serial完全不具备的能力。
