Зачем так долго ждать JVM для GC моего недостижимого объекта?

Question

Я работал над утечкой загрузчика в нашем приложении и, наконец, дошел до того, что все ссылки на CL исчезли. В моем инструменте профилирования памяти (с использованием MyKit и jmap/jhat) я могу заставить GC, который иногда сразу же избавится от моего загрузчика классов, но затем в другое время (зависит от использования приложения, но это так же специфично, как я могу получить), когда я вынуждаю GC, экземпляр CL не исчезает. Я фиксирую снимок памяти и просматриваю результаты, и он говорит, что этот объект существует, но недоступен.

Вот сумасшедшая часть ... и я обнаружил это случайно.

Я могу заставить все GC полностью хотеть, но экземпляр просто не исчезает. ОДНАКО, через 10-20 минут, если я сделаю еще один полный GC, это будет .

(В течение этого периода времени приложение является в основном неактивным (не полностью). Мой «расширенной» кофе-брейк был несчастный случай, который привел к этому открытию.)

Так мое беспокойство по поводу утечки здесь больше нет (надеюсь), но теперь вопрос заключается в попытке объяснить это поведение.

Кто-нибудь знает, что может заставить ВС JVM решить не собирать недостижимый загрузчик классов в течение 20 минут?

ВС JVM версия деталь:

java version "1.6.0_23" 
Java(TM) SE Runtime Environment (build 1.6.0_23-b05) 
Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode) 

Answer 1

Скорее всего потому, что виртуальная машина использует generational сбора мусора, но в конечном итоге будет делать полный отметь и подметать

Answer 2

только предположение: загрузчик классов (и классы он загружен) не расположены в обычной куче, а в постоянном поколении («ПерминГен»). Эта часть памяти будет проходить гораздо реже, чем все остальное, поскольку в обычных условиях загрузчики классов не выходят за рамки.

(Возможно, может быть какая-то конфигурация конфигурации GC, чтобы влиять на эту частоту.) Я полагаю, что заполнение PermGen также вызовет сборку, но вы, как правило, не хотите этого делать.

Зачем вам нужен ваш загрузчик классов?

Answer 3

Я думаю, что Джереми Хейлер находится на правильном пути, и это вопрос финализации. В принципе, даже если GC знает, что объект недоступен, он может быть неопределенным временем до фактического сбора объекта, так как он может быть выставлен в очередь для финализации. Поток финализатора должен будет дойти до завершения объекта (что может занять некоторое время, в зависимости от того, сколько других объектов нужно доработать и как выглядят их финализаторы), а затем, после того, как объект будет завершен, вам понадобится еще GC, чтобы вновь обнаружить, что объект недоступен, прежде чем он будет собран.

Плюс, в случае ClassLoader на Sun JVM он скорее всего будет передан непосредственно в PermGen. Таким образом, вам не понадобится один, но две полные прокрутки PermGen (один для того, чтобы объект попал в очередь финализации, а затем второй, чтобы фактически собрать его). Поскольку прокладки PermGen дороги, я считаю, что Sun JVM не делает их вообще с настройками по умолчанию и даже с различными настройками GC, все еще довольно неохотно подметает PermGen (особенно, если нет большого количества другого давления памяти).

Если вместо того, чтобы заставлять (гм, я имею в виду, поощрение) ГХ с использованием System.gc(), что, если вы делаете что-то вроде:

System.gc(); 
System.runFinalization(); 
System.gc(); 

Конечно, даже это не гарантирует работу, но он, по крайней мере, выполняет минимально необходимую работу по очистке большого объекта, требующего окончательной доработки.

Answer 4

Возможная причина в том, что загрузчик классов был сохранен путем мягких ссылок. Попробуйте запустить с

-XX:SoftRefLRUPolicyMSPerMB=1 

и посмотрите, если это имеет значение. Вот что произошло в my case.