内存碎片源于垃圾回收后存活对象分散布局，而非对象分配本身；外部碎片表现为大量小空闲块夹在存活对象间，Compaction通过移动存活对象实现内存连续化。
对象分配本身不直接“制造”碎片，但它是碎片产生的起点；真正导致外部碎片的，是垃圾回收后存活对象的分散布局——而 Compaction 的核心作用，就是把这种分散状态重新拉回连续。
内存碎片怎么来的？不是分配，而是回收留下的“空地”
每次 new 对象，JVM 都会从堆中划出一块空间。问题不在“划”，而在“划完之后怎么收”。标记-清除类 GC（如 CMS、早期 Serial Old）只清理死亡对象，不移动存活对象。久而久之，堆里就出现大量小块空闲区，夹在存活对象之间——就像城市里被老楼隔开的零碎空地，总和够建商场，却连一个小商铺都塞不下。
- 典型表现：老年代剩余内存充足，但分配一个 2MB 对象失败，报
OutOfMemoryError: Java heap space - 根本原因：空闲块最大只有 300KB，而最小需求是 2MB，外部碎片已严重
- 年轻代不明显：复制算法天然清空+重排，每次 Minor GC 后 Eden 和 Survivor 都是紧凑的
Compaction 不是“清理”，是“搬家+归位”
它不删对象，而是把所有存活对象统一挪到内存一端，腾出另一端的大片连续空闲区。这个过程类似整理书架：把散落各处的书全收到左边，右边立刻空出整层架子。
- 必须 STW：所有线程暂停，确保对象移动时引用不会被并发修改
- 要更新所有引用：每个指向旧地址的指针，都得改成新地址（比如栈帧里的局部变量、其他对象的字段）
- 耗时与存活对象数成正比：老年代越大、越“老”，压缩越慢
哪些场景会触发 Compaction？
不是每次 GC 都压缩——代价高，只在必要时出手：
- Full GC 选用支持压缩的收集器时：Serial Old、Parallel Old、ZGC（部分阶段）、G1（Mixed GC 中对选定 Region 做局部压缩）
- 晋升失败（Promotion Failure）：Minor GC 后要往老年代升对象，却发现最大连续空闲块
- G1 的 Mixed GC：不整堆压缩，而是挑几个回收价值高的老年代 Region，内部做紧凑整理，属于增量式控制碎片
指针碰撞 vs 空闲列表：碎片直接影响分配效率
堆是否规整，决定了 JVM 用哪种方式快速分内存：
- 指针碰撞（Bump the Pointer）：适用于 Serial/Parallel 等收集器——因为它们每次 GC 后都做压缩，堆始终规整，分配只需挪动一个指针，快如闪电
- 空闲列表（Free List）：CMS/G1 默认不用压缩，堆碎片多，JVM 得维护一张“空地地图”，每次分配都要遍历找合适块，慢且易受碎片拖累
换句话说：Compaction 不只是为防 OOM，它还让后续对象分配重回“指针碰撞”级别的速度。
