空闲列表分配效率偏低的核心问题是遍历开销大且不合并相邻块，导致高频分配时链表节点激增、查找为o(n)、小碎片累积无法满足大对象需求，进而触发频繁gc。
标记-清除算法中，空闲列表分配效率偏低，核心问题不在“找不找得到”，而在“每次都要从头翻、越用越慢”。它不整理内存，只靠链表记录零散空闲块，高频分配时性能会明显下滑。
为什么空闲列表查找慢
新对象分配需遍历空闲链表，匹配合适大小的块。三种常用策略各有短板：
- 首次适应（First-fit）：从链表头开始找，第一个够大的就用。快但易造成低地址区碎成蜂窝，高地址大块长期闲置；
- 最佳适应（Best-fit）：扫完整个链表，挑最接近需求的块。内存利用率高，但常留下极小残片，后续基本无法复用；
- 最差适应（Worst-fit）：总选最大块切分。看似合理，实则高频切分后生成大量小碎片，加速链表膨胀。
链表本身也在拖慢分配
空闲块不合并、不排序，链表节点随机分布。随着分配释放次数增加：
- 节点数量持续上升，遍历耗时线性增长；
- 相邻空闲块哪怕紧挨着，只要没显式合并，就仍是两个独立节点——128KB需求无法由两个64KB块满足；
- 没有元数据索引，每次分配都是O(n)操作，最坏情况要走到链表末尾。
高频场景下效率恶化更快
短生命周期对象（如循环内临时String、ArrayList）反复申请释放，导致：
- 同一区域被频繁切分与填入，空闲块尺寸越来越小、数量越来越多；
- 小碎片堆积后，大对象（如byte[1MB]）即使堆中总空闲充足，也因找不到连续空间而触发额外GC；
- GC频次上升→停顿增多→应用吞吐下降，形成负向循环。
常见优化方向
单纯依赖空闲列表难解根本，工业级实现通常叠加以下手段：
- 多级空闲链表：按块大小分组（如64B、128B、512B、2KB…），分配时直奔对应链表，跳过无效扫描；
- 隐式合并：清除阶段检测前后是否为空闲块，自动拼接，减少碎片数量；
- 延迟清除：不清除，只标记；等下次分配发现碎片严重时，再集中整理或触发压缩；
- 结合分代设计：在年轻代用复制算法规避碎片，在老年代才启用标记-清除，并限制大对象直接进老年代。
