标记清除算法导致老年代内存碎片的核心原因是只回收垃圾对象而不移动存活对象，使空闲空间离散分布；老年代对象长期存活、数量多且体积大，无法采用复制算法，只能就地标记清除，最终因缺乏连续空间而频繁触发Full GC甚至OOM。

标记清除算法在老年代回收时产生内存碎片，核心原因在于它只释放垃圾对象占用的空间，却不移动存活对象。

为什么老年代特别容易出碎片

老年代存放的是长期存活的对象，每次GC后大量对象仍保留。标记清除只是把“该删的删掉”，剩下的对象原地不动，空出来的内存块就散落在各处。

• 比如堆里原本有 A、B、C、D 四个对象依次排列，B 和 D 被判定为垃圾；清除后只剩 A 和 C，中间留下两段孤立空闲空间
• 后续若要分配一个比任一空闲块都大的对象（如 2MB），即使总空闲内存有 5MB，也会因找不到连续 2MB 空间而失败
• 这就像书架上抽走几本书后，剩下空位东一块西一块，新来的大部头书放不进去

碎片不是“没内存”，而是“用不上”

内存总量充足，但无法满足连续分配需求。JVM申请堆内存必须是连续地址空间，碎片导致可用内存“形同虚设”。

• CMS 垃圾回收器就采用标记清除，因此常出现 full gc 频繁但老年代使用率不高——空闲内存很多，就是拼不出大块
• 典型现象：日志显示老年代已使用 60%，却频繁触发 Full GC，甚至抛出 java.lang.OutOfMemoryError: GC overhead limit exceeded

和新生代对比更明显

新生代用复制算法，每次 GC 都把存活对象搬到新区域，旧区域整块清空，天然无碎片；老年代没这个条件——对象多、体积大、没备用空间，只能就地标记+清除。

• 复制算法需要预留一半空间作搬运中转，老年代承受不了这种浪费
• 所以标记整理（压缩）成为替代方案：把所有存活对象往一端挤，腾出连续大块空闲区

实际影响不止分配失败

碎片还会拖慢分配速度、增加 GC 成本。JVM 为找一块足够大的空闲空间，得遍历空闲链表或位图，时间开销随碎片增多而上升。

• 某些场景下，哪怕只差几个字节对齐，也会让本可复用的空闲块被跳过
• 长期运行的服务，若老年代持续用标记清除，碎片会像雪球一样越滚越大