Существует как минимум два способа, прямо или косвенно, предположить, что JVM затрачивает усилия на сбор мусора:
System.gc()
- берет дамп кучи и запрашивает только живые объекты
В последнем я могу получить программный дамп кучи, например, через
hotspotMBean = ManagementFactory.newPlatformMXBeanProxy(ManagementFactory.getPlatformMBeanServer(), "com.sun.management:type=HotSpotDiagnostic", HotSpotDiagnosticMXBean.class);
hotspotMBean.dumpHeap(filename, live);
Какая разница, если таковые имеются, между тем, что эти две операции будут делать для сбора объектов, не достижимых для достижения цели?
Я полагаю, что у меня есть доказательства того, что подход с использованием динамической памяти более агрессивен, чем System.gc()
, при наличии некоторой комбинации слабых ссылок, распределенной сборки мусора RMI и невидимых объектов, сильно доступных из стека . В частности, объекты, которые только слабо достижимы локально и стали Unreferenced
относительно RMI, по-видимому, собираются только дампом кучи. Я еще не смог преобразовать это в небольшой тестовый пример, но он воспроизводим.
(До того, как меня предупредили о том, что я не полагаюсь на определенное поведение GC в программном коде, я этого не сделал. Я обнаружил это при исследовании потенциальной утечки памяти и заметил, что результат варьируется в зависимости от того, когда я сделал дамп кучи. I Мне просто любопытно.)
Используется 64-битный сервер HotSpot VM 1.6.0_22 в Windows 7.