Охота утечки памяти, VisualVM: «Корень GC не найден». Что дальше?
У меня есть дамп памяти, который я сделал из умирающего приложения. Он израсходовал всю доступную кучу (-Xmx1024m). Он использует com.gargoylesoftware.htmlunit.WebClient для сканирования веб-страниц. Делает несколько http-запросов в минуту, умирает через несколько дней. Как я вижу из дампа, он содержит ~ 1750 экземпляров класса HtmlPage , каждый из которых содержит несколько связанных объектов, включая полное содержимое просканированной страницы.
Я не могу понять, почему HtmlPage не собираются сборщиком мусора.Я исследовал ссылки на экземпляры, и я не вижу в моем коде ссылки на него, а VisualVM сообщает, что «Корень сборщика мусора не найден». Насколько я понимаю, это должно означать, что объект имеет право на gc, но это не работает.
Приложение работает как простой автономный процесс, оно не использует никаких веб-контейнеров или серверов приложений.
Есть подсказки? Что еще мне следует изучить?
Спецификации:
- htmlunit v2.7
- версия java "1.6.0_13" Среда выполнения Java (TM) SE (сборка 1.6.0_13-b03) Серверная виртуальная машина Java HotSpot ™ (сборка 11.3-b02, смешанный режим)
- Linux my.lan 2.6.18-128.el5 # 1 SMP среда, 17 декабря, 11:42:39 EST 2008 i686 i686 i386 GNU / Linux
Update1
Я попытался проанализировать дамп с помощью YourKit Java Profiler. Он показывает мне множество объектов java.lang.ref.Finalizer с сохраненным размером 310 МБ. Они создаются для финализатора net.sourceforge.htmlunit.corejs.javascript.NativeGenerator # finalize () , а NativeGenerator относится к Window , затем к HtmlPage и все остальное.
Кто-нибудь знает, почему они остаются в памяти?
Примечание : Любопытно, но VisualVM показывал «ожидающие завершения» как ноль.