内存碎片指内存中因分配释放不连续而产生的大量小空闲块，虽总空闲足够却无法满足大对象对连续空间的需求，导致分配失败、频繁GC甚至OOM。
标记-清除算法在回收堆内存时，不移动存活对象，只清除未标记的垃圾，因此容易产生大量不连续的小块空闲内存——这就是内存碎片。它不会直接导致 OOM，但会显著降低大对象分配成功率，引发频繁 GC 甚至 Full GC，最终拖慢应用性能。
内存碎片如何影响对象分配
当 JVM 尝试为一个较大对象（如大数组、缓存块）分配连续内存时，即使堆中总空闲空间充足，也可能因缺乏足够大的连续空闲块而失败。此时 JVM 可能触发一次 Full GC（尤其是 Serial 或 CMS 收集器），试图通过压缩整理来腾出连续空间；若仍失败，则抛出 java.lang.OutOfMemoryError: Java heap space（注意：不是 metaspace 或 direct memory 相关错误）。
常见诱因包括：
- 长期运行中频繁创建/销毁中等大小对象（如 1–100KB 的 byte[]、HashMap）
- 使用 CMS 收集器且未开启
-XX:+UseCMSCompactAtFullCollection或未配置合适的压缩时机 - 堆内存过大（如 >4GB）但 Survivor 区偏小，导致对象过早进入老年代，加剧老年代碎片化
如何判断是否是碎片问题而非真实内存不足
关键看 GC 日志中的空间分布和失败模式：
- 观察 Full GC 前后老年代使用率变化不大（例如 GC 前 75%，GC 后仍 72%），说明回收效果差，可能因碎片导致无法释放有效空间
- 日志中出现 "concurrent mode failure"（CMS）或 "promotion failed"（ParNew + CMS 组合），常伴随后续 Full GC，是典型碎片信号
- 使用
jstat -gc <pid>查看 OU（Old Used）持续高位，但 OC（Old Capacity）未满，且 YGCT/YGCT 频繁上升 - 启用
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，关注每次 GC 后老年代的 碎片率估算值（部分 JVM 版本会在日志中标注 "fragmentation" 或显示最大可用连续块大小）
辅助排查工具与手段
单靠日志有时不够直观，可结合以下方式进一步验证：
- jmap -histo:live <pid> 查看存活对象大小分布，若存在大量中等尺寸（如 64KB–1MB）对象且生命周期长，易形成“夹心碎片”
- jmap -dump:format=b,file=heap.hprof <pid> 生成堆快照，用 Eclipse MAT 或 VisualVM 打开，使用 “Histogram” + “Group by package/class” 定位大对象来源；再用 “Dominator Tree” 查看谁持有大量中小对象引用
- 对 CMS 收集器，启用
-XX:+PrintFLSStatistics=2（JDK 7/8），输出自由列表（Free List）统计，直接显示空闲块数量、平均大小、最大连续块等，是诊断碎片最直接的参数
缓解与调优方向
碎片无法完全避免，但可通过策略降低其危害：
- 升级到 G1 或 ZGC：G1 默认按 Region 管理，天然减少大块碎片；ZGC/CMS 更进一步消除 Stop-The-World 压缩阶段
- 若必须用 CMS：启用
-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=1，让每次 Full GC 都做压缩（代价是更长 STW） - 调整对象晋升策略：增大 Survivor 区（
-XX:SurvivorRatio）、提高晋升阈值（-XX:MaxTenuringThreshold），减少短期对象过早进入老年代 - 应用层优化：复用缓冲区（如
ByteBuffer.allocateDirect()改为池化）、避免一次性申请超大数组、拆分超大缓存为多个小单元
