jvm内存碎片分为外部碎片（空闲内存不连续，导致大对象分配失败）和内部碎片（固定大小分配单元未充分利用），不同gc算法应对策略各异：标记-清除易产生外部碎片，复制类天然消除外部碎片但需额外空间，标记-整理类通过移动压缩降低碎片；可通过gc日志中ou变化小、promotion failed等信号判断碎片问题。
JVM 内存碎片问题主要源于对象动态分配与回收过程中，空闲内存被切割成大量不连续的小块，导致虽总空闲足够，却无法满足大对象对连续空间的需求。它不直接耗尽内存，但会显著降低分配成功率，诱发频繁 GC、晋升失败、concurrent mode failure，甚至触发 Full GC 后仍 OOM。
碎片的两种类型：外部 vs 内部
外部碎片是 JVM 堆中最常见、影响最直接的问题：存活对象散落在堆中，释放后留下零散空闲区域（如多个 64KB、128KB 的“空洞”），彼此不相邻。当申请一个 512KB 的 byte[] 时，即使老年代还有 1GB 空闲，也可能因无连续 512KB 区域而失败。
内部碎片则多见于固定大小分配单元的设计中：例如 Eden 区按 Region 或 Page 划分，或某些内存池预设块大小为 16KB，而实际只用 12KB，剩余 4KB 无法被其他请求复用。这类碎片不破坏连续性，但拉低整体内存利用率。
不同 GC 算法如何应对碎片
垃圾收集器底层策略决定了其处理碎片的能力：
- 标记-清除类（如 CMS）：仅标记并清理死亡对象，不移动存活对象。结果是老年代快速积累外部碎片，尤其在长期运行、中等对象频繁升降代的场景下。CMS 已在 JDK 9 中被弃用，主因之一就是碎片失控风险高。
- 复制类（如 Serial/Parallel 年轻代、G1 年轻代）：将存活对象整体复制到新区域，原区域整块清空。天然消除外部碎片，但需预留备用空间（如 Survivor 区需双倍容量），且对象存活率高时复制开销陡增。
- 标记-整理类（如 G1 混合回收、Parallel Old、ZGC、Shenandoah）：在回收同时移动对象、压缩空间。G1 选择部分 Region 进行复制整理；Parallel Old 将老年代存活对象向起始端滑动；ZGC 和 Shenandoah 更进一步，在应用线程运行中并发重定位对象并更新引用，实现低停顿+低碎片双重目标。
判断是否真由碎片引发问题
不能仅看“OOM”就断定是内存不足——关键看 GC 日志和内存分布特征：
- Full GC 前后老年代已用空间（OU）变化极小（如 78% → 76%），说明回收效果差，大概率是碎片阻碍了有效释放；
- 日志中出现 promotion failed（ParNew + CMS）、concurrent mode failure（CMS）或 to-space overflow（G1），都是碎片导致晋升或转移失败的典型信号；
- 用
jstat -gc <pid></pid>观察 OU 持续高位、OC 未满，同时 YGCT 频繁上升，提示年轻代压力传导至老年代并受碎片阻塞； - CMS 可启用
-XX:+PrintFLSStatistics=2，直接输出自由列表统计：空闲块数量、平均大小、最大连续块（largest free chunk）——若该值持续低于常用大对象尺寸（如
主动治理与优化建议
碎片不是“等它发生再救”，而是可通过配置与设计提前缓解：
- 避免使用 CMS；新项目优先选 ZGC 或 Shenandoah（JDK 11+），它们在大堆（≥16GB）下仍能维持碎片率
- 若用 G1，合理设置
-XX:G1HeapRegionSize（避免过小导致元数据开销大，过大加剧碎片粒度），并通过-XX:G1MixedGCCountTarget控制混合回收频率，让整理更及时； - 调大 Survivor 区比例（
-XX:SurvivorRatio调小）或启用-XX:+AlwaysTenure（慎用），减少对象过早进入老年代，从源头降低老年代碎片生成速度； - 业务层控制大对象生命周期：避免长期持有大 byte[]、HashMap 或缓存块；可考虑拆分存储、改用 off-heap（如 DirectByteBuffer）或流式处理，绕过堆内连续分配约束。
