标记清除算法回收老年代对象时，会因对象分布不均而产生内存碎片。该算法先标记存活对象，再清除未标记对象，导致内存中出现大量不连续的空闲区域。这些碎片无法被有效利用，降低了内存利用率，可能引发频繁的Full GC。为减少碎片，可采用标记整理算法，将存活对象向一端移动，保持内存连续性。

标记清除算法在老年代垃圾回收中虽能高效识别并清理死亡对象，却因不移动存活对象而导致内存空间日益离散、碎片化严重——看似总空闲内存充足，实则因缺乏连续地址块而频繁触发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 为找一块足够大的空闲空间，得遍历空闲链表或位图，时间开销随碎片增多而上升。

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

以上就是《标记清除算法回收老年代对象时，会因对象分布不均而产生内存碎片。该算法先标记存活对象，再清除未标记对象，导致内存中出现大量不连续的空闲区域。这些碎片无法被有效利用，降低了内存利用率，可能引发频繁的Full GC。为减少碎片，可采用标记整理算法，将存活对象向一端移动，保持内存连续性。》的详细内容，更多关于的资料请关注golang学习网公众号！