jvm堆内存碎片化核心是空闲内存总量足够但不连续，导致大对象无法分配，引发频繁gc、promotion failed、to-space exhausted甚至oom；解决关键在于让存活对象紧凑、空闲空间连贯，而非简单扩容。
JVM 堆内存碎片化问题的核心是“空闲内存总量够，但不连续”，导致大对象（如 byte[]、长字符串、缓存结构）无法分配，进而触发频繁 GC、promotion failed、to-space exhausted，甚至 OOM。解决不是靠扩容，而是让存活对象更紧凑、空闲空间更连贯。
识别是否真由外部碎片引起
别一看到 OOM 就加堆内存——先看关键信号：
- Full GC 后老年代已用空间（OU）几乎不变（比如 79% → 77%），说明回收效果差，大概率是碎片阻碍了有效压缩；
- GC 日志中反复出现 promotion failed（ParNew+CMS）、concurrent mode failure（CMS）、to-space exhausted（G1）或 Humongous allocation failed；
- 用
jstat -gc <pid></pid>观察 MGCC（Mixed GC 次数）远高于 CCSC（Concurrent Cycle 次数），说明 G1 在被动应对碎片； - VisualVM 或 JMC 堆直方图显示大量中等尺寸（几 MB）的“空洞”，而非均匀分布的空闲区。
选对垃圾收集器是根本解法
不同 GC 对碎片的处理逻辑差异极大，升级收集器常比调参更见效：
- ZGC 或 Shenandoah：并发标记 + 并发移动，应用线程运行时就完成对象重定位和引用更新，每次回收都整理堆，天然抑制碎片。适合堆 ≥ 32GB、延迟敏感场景（如风控、实时推荐）；
- G1：Region 化设计 + 混合回收，能主动挑选碎片多的老年代 Region 进行复制整理，腾出整块干净空间。适合堆 4–64GB、需可控停顿（目标 200ms 内）的中大型服务；
- Parallel Old：标记-整理算法，在 Full GC 时将老年代存活对象向一端滑动压缩，彻底合并空闲区。适合吞吐优先、可接受秒级停顿的批处理任务；
- 避免 CMS 和 Parallel Scavenge + Parallel Old 组合：CMS 不移动对象，碎片随时间恶化，JDK 9 起已弃用；Parallel GC 只在 Full GC 时压缩，且全程 STW，易引发毛刺。
参数调优缓解碎片压力
即使暂不能换 GC，合理调参也能显著改善：
- 对 G1：-XX:G1HeapRegionSize=2M 或 4M（避免默认 1M 导致巨型对象跨多个 Region）；
- 启用 -XX:+AlwaysPreTouch：JVM 启动时即锁定并清零全部堆内存，防止运行时缺页中断加剧内存布局离散；
- 适当提高 -XX:MaxGCPauseMillis=200，让 G1 有更多时间选择收益更高的 Region 回收集；
- 设置 -Xms 与 -Xmx 相等，避免堆动态扩容引入不连续内存映射。
从代码源头减少碎片生成
再强的 GC 也难扛高频小对象震荡和无序大对象冲击：
- 对已知尺寸的大对象（如图像缓冲、消息体），改用 对象池复用，而非每次 new；
- 批量操作替代逐条处理：用 ArrayList 一次性加载千条记录，减少小对象分配频次；
- 控制大对象分配路径：G1 下关注 Region 大小匹配；Serial/ParNew 下可设 -XX:PretenureSizeThreshold=1m，使超阈值对象直接进老年代，跳过年轻代搬运；
- 避免长期持有短生命周期对象的引用（如静态 Map 缓存未清理），防止它们“钉住”内存区域，阻碍整理。
