标记-清除算法不自动合并内存，需依赖后续策略解决碎片问题；常见合并时机包括即时合并、延迟合并和后台整理式合并；实际操作是更新空闲块元信息而非移动数据；优化方向为采用multi-size空闲链表分级管理。
标记-清除算法本身不自动合并内存，回收后产生的空闲块天然离散。是否合并、何时合并、怎么合并，取决于后续的内存管理策略，而非标记-清除阶段的固有行为。
为什么需要合并（解决碎片问题）
标记-清除只做两件事：标记存活对象、清除未标记对象。清除后，堆中会留下许多大小不一、位置分散的空闲块。这些碎片虽总和足够，但无法满足大对象的连续分配需求，容易触发频繁GC。合并的目的就是把相邻的空闲块拼成更大的连续区域，提升后续分配效率。
常见的空闲内存合并时机
- 即时合并：在清除阶段扫描内存时，一旦发现两个相邻空闲块，立即合并为一个。实现简单，但每次清除都增加判断开销。
- 延迟合并：不清除时立刻合并，而是把空闲块登记进空闲链表，等到分配新对象失败、触发“找不到足够连续空间”时，再遍历链表尝试合并相邻块。
- 后台整理式合并：不依赖分配失败，由独立线程周期性扫描空闲链表，按地址排序后合并所有物理相邻的空闲块。适合对停顿敏感的系统。
合并的实际操作方式
合并不是移动数据，而是更新空闲块元信息：
- 每个空闲块头部记录起始地址和长度；
- 若块A末地址等于块B起始地址，说明二者物理相邻；
- 合并时将块A长度更新为A.length + B.length，并从空闲链表中移除块B；
- 需维护空闲链表的有序性（通常按地址升序），否则无法高效识别相邻关系。
优化方向：multi-size空闲链表
单纯一条链表查找合并效率低。实际系统常按空闲块大小分级维护多个链表（如：16B/64B/256B/1KB+），分配时直接查对应尺寸链表；合并后也按新尺寸归入对应链表。这样既加快分配，也使同尺寸块更集中，间接降低碎片感知度。
