Java System.gc（）和通过仅使用活动堆转储执行的死对象回收之间的区别？

至少有两种方法可以直接或间接地建议JVM花费精力收集垃圾：

• System.gc（）

• 获取堆转储并仅请求活动对象

在后者中，我可以通过编程方式获得堆转储，例如通过

hotspotMBean = ManagementFactory.newPlatformMXBeanProxy(ManagementFactory.getPlatformMBeanServer(), "com.sun.management:type=HotSpotDiagnostic", HotSpotDiagnosticMXBean.class);
hotspotMBean.dumpHeap(filename, live);

这两个操作在收集非强可达对象时会有什么区别（如果有的话）

我相信我有证据表明，在弱引用、RMI分布式垃圾收集和垃圾回收的组合存在的情况下，堆转储方法比

System.gc（）

更具攻击性。特别是，对于RMI而言，仅在本地弱可访问且已成为

未引用的

的对象似乎仅由堆转储收集。我还没有能够把它提炼成一个小的测试用例，但它是可复制的

（在我被警告不要在prod代码中依赖特定的GC行为之前，我并没有。我在调查潜在内存泄漏时发现了这一点，并注意到结果随我进行堆转储的时间而变化。我只是好奇。）

这是在Windows 7上使用HotSpot 64位服务器VM 1.6.0_22。

System.gc（）的攻击性可能较小，因为它只是指示JVM应该运行gc。然后GC可以自由决定它应该收集（查找并释放内存）所有的死对象，其中一些，等等。它可以决定以前的大收集发生得太晚，现在不是再次收集所有对象的时候

我相信转储heap并显式地只询问活动对象将导致GC精确地计算每个对象（如果它仍然是活动的）。这部分收集工作正在完成，释放死物使用的内存也不会花费太多

---

唉，我没有强有力的证据证明这种行为，这与其说是一种真正的解释，不如说是一种胡乱猜测。

是的，这也是我猜测的范围！我想知道当

System.GC（）

建议实际存在一个完整的GC时，行为是否会有所不同。我想很难演示。你可以使用像VisualVM VisualGC插件这样的软件来查看完整GC的效果。