标记-清除算法在高频分配下加剧内存碎片，因其只回收死亡对象、不移动存活对象，导致空闲块大小不一、位置随机；高频短生命周期对象反复分配释放，使空闲链表中大量小碎片累积，无法拼凑出大块连续空间，进而触发频繁GC。
在高频分配变量的场景下，标记-清除算法容易快速积累内存碎片，核心原因在于它只回收死亡对象、不移动存活对象，且分配策略依赖离散空闲块的拼凑。
为什么高频分配会加剧碎片？
每次 new 对象或创建局部引用时，JVM 都需从空闲链表中找一块足够大的连续空间。标记-清除本身不整理内存，清除后留下的空闲块大小不一、位置随机。当分配频率高、对象生命周期短（如循环内临时对象）、尺寸波动大（比如 String、ArrayList 容量动态变化）时，空闲块被反复切分、复用，小碎片越积越多——就像不断撕碎一张纸再随机扔进盒子里，最后盒子里全是边角料，却拼不出一张完整信纸。
空闲链表管理方式放大碎片影响标记-清除通常配合动态分区分配策略（如首次适应、最佳适应）维护空闲列表。在高频分配下：首次适应：总从低地址找，导致高地址大块长期闲置，低地址碎成“蜂窝”；
最佳适应：虽选最接近需求的块，但常留下极小残片，后续几乎无法复用；
无论哪种策略，只要不合并相邻空闲块，两个紧挨着的 64KB 空闲区仍被视为两个独立 64KB 块，无法满足一个 128KB 对象的分配请求。
碎片如何触发恶性循环？
一旦出现较大对象（如 byte[1MB] 缓冲区、大 JSON 解析树）需要分配，而空闲链表中没有足够大的连续块，JVM 就不得不提前触发下一次 GC——哪怕堆中总空闲量充足。这不仅增加 STW 时间，还会让本可自然消亡的短期对象被“误保”进下一轮，进一步挤占连续空间。CMS 收集器就因回避压缩而特别怕这种场景，ZGC/Shenandoah 则绕过该问题，靠读屏障+着色指针实现并发整理。
关键不在“清除”，而在“不整理”
标记-清除的清除动作本身只是把死亡对象地址加入空闲列表，并不重排内存。真正导致碎片不可逆的是：存活对象原地不动，地址固化，彼此之间的间隙永远保留。即便之后部分间隙被小对象填满，其周边又会产生新间隙。高频分配相当于持续往这个“固定骨架”里插拔不同尺寸的积木，结构稳定性迅速下降。