Утечка памяти в JVM при использовании коллектора G1?

У кого-нибудь были проблемы с утечкой памяти JVM (Hotspot) при использовании коллектора G1?

Я установил размер кучи равным 60 ГБ (для -ms и -ms установлено значение 60 ГБ), но размер процесса Java (в соответствии со столбцом vsz команды ps) начинается с 64 ГБ, но увеличивается до 84 ГБ. в течение 7 часов.

При использовании параллельного коллектора размер процесса остается стабильным в течение 20 часов работы, около 65 ГБ или около того.

У кого-нибудь еще были подобные проблемы с коллектором G1? Я запускаю очень простой тест и не использую прямую буферную память или другую память вне кучи (о которой я знаю).

Версия Java 1.7.0, обновление 5

(Я поднял ошибку в Oracle по этому поводу, но подумал, что я тоже проверю здесь, если у кого-то есть обходной путь).

1 ответ

У кого-нибудь еще были подобные проблемы с коллектором G1?

В скором времени - да.

Вот ТАК тема о возникновении утечек памяти:

Создание утечки памяти с Java

он содержит информацию о G1

Использование InflaterInputStream, передавая новый java.util.zip.Inflater() в c-tor (например, PNGImageDecoder) и не вызывая end() инфлятора. Что ж, если вы передадите в c-tor w/ just new, нет никаких шансов... и да, вызов close() в потоке не закроет инфлятор, если он был вручную передан как параметр c-tor. Это не настоящая утечка, поскольку она будет выпущена финализатором... когда он сочтет это необходимым. До этого момента он так сильно ест внутреннюю память, что может заставить linux oom_killer безнаказанно убивать процесс. Основная проблема заключается в том, что финализация в Java очень ненадежна, и G1 ухудшил ее до 7.0.2. Мораль этой истории: освободите родные ресурсы как можно быстрее, финализатор слишком беден.

Утечка также упоминается здесь: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7152954

Другие вопросы по тегам