VisualVM堆转储Summary显示GC Roots远多于Objects视图，原因何在？

核心矛盾解释 #

你遇到的是堆转储不同视图统计口径不一致的问题：

• Summary中的GC Roots计数是所有被GC Roots直接或间接引用的存活对象总数，而非根对象本身的数量；
• Objects视图的GC Roots分类统计的是顶层根实体的数量（比如JNI全局引用实例、线程栈帧实例等），不包含它们引用的下游对象。

具体原因拆解 #

• JNI全局引用的连锁引用：7857个JNI global引用如果每个都持有大集合（比如List、Map）或长生命周期对象，这些集合里的所有元素都会被Summary统计到GC Roots相关计数中，而Objects视图只统计JNI global本身的数量。
• 工具统计逻辑差异：堆分析工具的Summary模块会把所有存活对象中属于根可达链的节点全部计入GC Roots相关统计，而Objects视图的GC Roots预设仅展示最顶层的根类型实例，两者统计维度完全不同。
• JNI局部引用的隐性累积：虽然当前Objects视图显示JNI local只有5个，但如果JNI代码存在高频调用且未及时调用DeleteLocalRef清理局部引用，在采样堆转储的瞬间之前，这些临时引用可能已经累积并关联了大量对象，Summary会把这些对象计入计数，而Objects视图只保留了采样时仍存活的局部引用。
• 线程栈帧的深层引用：983个Java frame每个都可能持有多个局部变量引用的对象，这些对象都会被Summary统计到GC Roots计数中，而Objects视图仅统计栈帧本身的数量。

排查建议 #

• 随机选取Summary中计数的对象，使用工具的路径到GC Roots功能，追踪其引用链，确认最终的根类型，定位大量对象的持有来源；
• 排查JNI代码中NewGlobalRef的调用逻辑，确认是否存在未释放的全局引用，以及这些引用是否关联了大体积或长生命周期的对象；
• 检查JNI局部引用的使用，确保在循环、高频调用的JNI方法中及时调用DeleteLocalRef清理引用，避免临时对象累积。

内容的提问来源于stack exchange，提问作者swpalmer