17370845950

本文详解为何 `managementfactory.getgarbagecollectormxbeans()` 在 cms 垃圾收集器下会将一次 `jmap -histo:live` 触发的 full gc 误报为多次，揭示 cms 的 foreground 模式中 initial mark、remark 和 sweep 阶段均独立增加 `collectioncount` 的机制，并提供健壮、跨 gc 算法的监控方案。

在使用 ManagementFactory.getGarbageCollectorMXBeans() 监控 Full GC 次数时，你观察到：执行一次 jmap -histo:live（触发 Heap Inspection Initiated GC）后，日志显示仅发生一次 CMS Full GC，但程序却报告 add FullGC count:2 —— 这并非代码逻辑错误，而是 CMS 垃圾收集器在 foreground 模式下的固有行为。

? 根本原因：CMS 的 “伪 Full GC” 阶段拆分

当 jmap -histo:live 触发 GC 时，JVM 会强制进入 CMS 的 foreground 模式（即暂停所有应用线程的同步回收），该模式并非单次原子操作，而是由多个可独立计数的子阶段组成：

• Initial Mark（初始标记）→ collectionCount++
• Remark（重新标记）→ collectionCount++
• Sweep（清除）→ collectionCount++

查看你的 GC 日志可验证这一点：

# 第一次 jmap：包含 Remark + Sweep（共 2 次计数增量）
[Full GC (Heap Inspection Initiated GC) ... [CMS: ...] ... [weak refs processing] ... [class unloading] ... [scrub symbol/string table] ... ]
→ 实际触发了 Remark（含 class unloading/scrub）和 Sweep 两个独立阶段

# 第二次 jmap：仅 Sweep（1 次增量）
[Full GC (Heap Inspection Initiated GC) ... [CMS: 83931K->85173K(...) ...]

因此，bean.getCollectionCount() 返回的是 CMS 子阶段总执行次数，而非用户语义上的“一次完整的 Full GC”。这就是你看到 sum of fullgc:1, add FullGC count:2 的真实原因。

✅ 正确做法：区分 GC 类型 + 聚合统计

不应依赖单一 GarbageCollectorMXBean 的 getCollectionCount() 判断 Full GC，而应：

1. 识别真正的 Full GC 收集器：CMS 的 ConcurrentMarkSweep 是并发收集器，其 getCollectionCount() 包含并发与 foreground 混合计数；真正执行 Full GC 的是 ParNew（年轻代）+ CMS（老年代）组合，但更可靠的方式是监听 GarbageCollectionNotification。

2. 使用 JMX 通知机制（推荐）：
   它能精确捕获每次 GC 的类型（endOfMajorGC / endOfMinorGC）、持续时间与内存变化，且不受 GC 算法内部阶段拆分影响：

import com.sun.management.GarbageCollectionNotificationInfo;
import javax.management.Notification;
import javax.management.NotificationListener;
import javax.management.ObjectName;
import java.lang.management.ManagementFactory;
import java.util.List;

public class GCMonitor {
    private static long fullGCCount = 0;

    public static void startMonitoring() throws Exception {
        List beans = ManagementFactory.getGarbageCollectorMXBeans();
        for (GarbageCollectorMXBean bean : beans) {
            ObjectName objName = ManagementFactory.newPlatformMXBeanObjectName(
                ManagementFactory.GARBAGE_COLLECTOR_MXBEAN_DOMAIN_TYPE + "," +
                "name=" + ObjectName.quote(bean.getName())
            );
            ManagementFactory.getPlatformMBeanServer().addNotificationListener(
                objName,
                (notification, handback) -> {
                    if (notification.getType().equals(GarbageCollectionNotificationInfo.GARBAGE_COLLECTION_NOTIFICATION)) {
                        GarbageCollectionNotificationInfo info =
                            GarbageCollectionNotificationInfo.from((CompositeData) notification.getUserData());
                        // 关键判断：Major GC（即 Full GC）通常作用于老年代（如 CMS Old Gen、G1 Old Generation）
                        if (info.getGcCause().contains("System.gc") ||
                            info.getGcCause().contains("Heap Inspection") ||
                            info.getGcName().toLowerCase().contains("old")) {
                            fullGCCount++;
                            System.out.printf("✅ Detected Full GC #%d: %s (%s) → %dms%n",
                                fullGCCount, info.getGcName(), info.getGcCause(), info.getGcInfo().getDuration());
                        }
                    }
                },
                null, null
            );
        }
    }
}

3. 兼容性提醒（重要！）
   • CMS 已在 JDK 9 中被标记为 deprecated，JDK 14 起彻底移除。现代应用应迁移到 G1 或 ZGC。
   • G1/ZGC 的 getCollectionCount() 行为更符合直觉：一次 jmap -histo:live 仅触发 1 次 collectionCount 增量（对应一次 Mixed GC 或 Full GC）。
   • 若必须支持旧版 CMS，请始终以 GarbageCollectionNotification 为准，放弃轮询 getCollectionCount()。

? 总结

• ❌ 错误认知：getCollectionCount() = Full GC 次数（尤其在 CMS foreground 模式下不成立）
• ✅ 正确认知：它是 GC 子阶段执行总次数，CMS 下一次 jmap 可能触发多次计数
• ✅ 最佳实践：使用 GarbageCollectionNotification 监听，结合 gcCause（如 "Heap Inspection"）和 gcName（如 "CMS Old Gen"）精准识别 Full GC
• ⚠️ 长期建议：升级至 G1/ZGC，简化监控逻辑并获得更好性能与可观测性

通过以上改进，你的 Full GC 监控将真正反映 JVM 行为本质，而非 GC 算法的实现细节陷阱。