Parallel Old 每次 Full GC 后老年代几乎无碎片，碎片率稳定在 1% 以内；但其标记-整理仅在 STW 时全量执行，不提供碎片率等实时监控指标，也无法预警碎片风险。

Parallel收集器本身不提供堆内存碎片的实时预警能力，它既无内置碎片监控指标，也不输出碎片率、空闲块分布或连续空间可用性等诊断信息。所谓“碎片预警”，在 Parallel 场景下其实是通过间接现象识别碎片风险，而非主动告警。

---

为什么 Parallel 不会告诉你“碎片高了”

• Parallel Old 使用标记-整理（Mark-Compact）算法，每次 Full GC 都会压缩老年代，理论上能消除碎片；
• 但它的整理是全堆暂停式、非增量、非并发的——只有触发 Full GC 时才整理，平时不维护；
• JVM 日志中没有“碎片率”“最大连续空闲块”等字段，GC 日志只显示回收前后的已用/剩余空间，无法直接反映碎片程度；
• 所以你看到的“老年代用了 70% 却频繁 Full GC”，大概率不是因为总量不足，而是因碎片导致大对象分配失败（promotion failed 或 concurrent mode failure 的变体），而 Parallel 并不标记这个原因。

---

真实可观察的碎片高发信号（即“隐性预警”）

当出现以下组合现象时，应高度怀疑老年代存在严重外部碎片：

• Full GC 频繁但回收效果差

  • 老年代使用率（used）在 Full GC 后下降极少（例如：GC 前 92%，GC 后仍 85%+）
  • GC 日志中 PSMarkSweep 回收耗时长（>300ms），且 Heap 行显示 after 内存仍高位

• Minor GC 后发生 Promotion Failed

  • 日志出现类似：ParNew (promotion failed) → 紧接着 Full GC
  • 表明 Survivor 放不下存活对象，需晋升到老年代，但老年代虽有空间却找不到连续区域容纳该对象

• 大对象（≥ -XX:PretenureSizeThreshold 或数组长度突增）分配直接失败

  • 报 java.lang.OutOfMemoryError: Java heap space，但 jstat -gc 显示老年代 OU（Old Used）未达 OC（Old Capacity）
  • 典型碎片 OOM：总空闲够，就是拼不出一块连续空间

• 启用 -XX:+PrintGCDetails 后，发现 CMS 或 G1 未启用，却频繁出现 concurrent mode failure 类提示（注意：这是 CMS 日志特征，但 Parallel 下类似逻辑会退化为直接 Full GC，无提示）

---

如何验证碎片是否存在？

1. 解析 GC 日志定位可疑点

   • 关注 Full GC (Allocation Failure) 或 (Ergonomics) 触发的 Full GC
   • 对比 PSMarkSweep 前后 old generation 的 used 和 capacity，计算回收率：

     回收率 = (before - after) / before  
     若 < 10%，且 after > 70% OC → 强烈提示碎片阻塞回收

2. 用 jmap -histo:live + jmap -dump 辅助分析（慎用于生产）

   • jmap -histo:live <pid> 查看存活对象分布，若大量小对象长期驻留老年代（如 HashMap$Node、String、byte[]），易形成“钉子对象”，阻碍整理
   • jmap -dump:format=b,file=heap.hprof <pid> 后用 Eclipse MAT 分析 “Dominator Tree”，观察是否有大量零散小对象占据老年代中间位置

3. 对比不同 GC 下的行为（验证性手段）

   • 临时切换为 G1（-XX:+UseG1GC -XX:MaxGCPauseMillis=100），若同样负载下 Full GC 消失、停顿下降、老年代利用率平稳 → 基本确认原 Parallel 下碎片是主因

---

碎片问题的根本出路不在调参，而在规避

Parallel 的设计不面向碎片敏感场景，强行优化收益有限：

• ❌ 不要调小 -Xmn —— 新生代过小 → 更多对象提前晋升 → 加重老年代碎片
• ❌ 不要设 -XX:MaxGCPauseMillis —— Parallel 会误判为延迟敏感，反向收缩堆、加剧频率
• ✅ 唯一有效缓解：
  • 控制对象生命周期，避免短命对象意外晋升（如关闭 SurvivorRatio 自适应、固定 SurvivorRatio=8）
  • 避免运行时创建大数组（如 new byte[1024*1024]），改用池化或流式处理
  • 升级 JDK + 切换 G1/ZGC（JDK 8u20+/11+），它们自带碎片感知与 Region 整理机制

不复杂但容易忽略：Parallel 的“整理”只在 Full GC 时发生，而高并发下你根本等不到那次整理——流量早把碎片雪球滚大了。