Утечки памяти объектов сборщика мусора

Question

У меня значительная утечка памяти в моем приложении. Я запустил jmap, и он говорит, что в настоящее время существуют следующие объекты, которых не должно быть (и которые являются основным источником утечки):

java.lang.management.MemoryUsage - 3938500 instances, 189048000 bytes
[Ljava.lang.management.MemoryUsage - 787700 instances, 31508000 bytes
com.sun.management.GCInfo - 293850 instances, 22055600 bytes
sun.management.GCInfoCompositeData - 393850 instances, 12603200 bytes

Я не использую эти объекты напрямую. Однако они используются сборщиком мусора. Я использую:

Java version: 1.7.0-b147
VM version: Java Hotspot(TM) 64-bit Server VM (build 21.0-b17, mixed mode)
The application is run in Jetty version 7.3.1

В настоящее время я использую параллельный сборщик мусора с низкой паузой. Однако у меня была такая же проблема даже при запуске сборщика пропускной способности.

У вас есть идея, почему эти объекты остаются в памяти? Что бы вы предложили сделать?

ОБНОВЛЕНИЕ: утечка памяти все еще происходит при обновлении 1 Java 1.7 (1.7.0_01-b08, 64-разрядная серверная виртуальная машина Java Hotspot (TM) (сборка 21.1-b02, смешанный режим))

ОБНОВЛЕНИЕ 2: утечка памяти вызвана JConsole. До запуска JConosole не было ни одного экземпляра классов, упомянутых выше. Как только я подключаюсь к приложению с помощью JConsole, объекты начинают появляться в памяти и остаются там навсегда. После завершения работы JConsole объекты все еще находятся в памяти, и их количество увеличивается до тех пор, пока приложение не будет закрыто.

Answer 1

Я на самом деле не использовал jmap, но я обработал утечки памяти в нашем приложении.

У вашего приложения недостаточно памяти?Я бы предложил сделать дамп до закрытия приложения, добавив следующее в ваши vm args

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp

Когда ваше приложение станет oom, оно создаст файл hprof под tmp, который вы можете использовать дляотладить проблему.

Если не идет OOM, попробуйте выделить меньшую память, чтобы вы могли принудительно установить OOM.

Я использовал eclipse MAT для анализафайлы.Это довольно хорошо, потому что сразу сообщит вам о подозрении на утечку.

Answer 2

Я думаю, вам нужно предоставить более подробную информацию о том, для чего предназначено приложение и что оно делает. Вы просто используете jConsole для отслеживания этой проблемы?

Я использую Visual VM для отслеживания этих типов проблем. См. ссылку о том, как использовать ее для утечки памяти, и эту ссылку для главной страницы Visual VM page .

Answer 3

Пару лет назад я сообщил о проблеме в Oracle, когда в JDK 7 утечка памяти начиналась в момент подключения JConsole. Утечка сохранится навсегда; даже если вы отключите JConsole.

Что протекало? Объекты, относящиеся к тому, почему работает сборщик мусора. Фактически, в основном это строки (например, «Ошибка распределения»). Я обнаружил проблему только потому, что использовал YourKit, и в YourKit вы можете анализировать объекты, помеченные как мусорные. По сути, в моем приложении ничего не указывалось на объекты, но они также не собирались сборщиком мусора.

Большинство утилит для кучного удаления немедленно удаляют из анализа объекты, которые можно собирать мусором. Таким образом, YourKit был крайне важен для определения того, что ошибка действительно была в JVM.

Не могу найти свой билет, но я нашел другие: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7143760 http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7128632

Answer 4

У меня такая же проблема.Я провел расследование 2 месяца назад, и проблема в виртуальной машине JAVA 7_0.В моем сценарии объект java.lang.management.MemoryUsage зависает и ежедневно наращивает сотни МБ.На все остальные объекты, которые вы видите висящими, ссылается объект java.lang.management.MemoryUsage.Проблема в том, что этот объект MemoryUsage висит только в java 7_0 и более поздних версиях, потому что этот класс MemoryUsage был добавлен в JAVA 7 и никогда не был в предыдущей java.И самое главное, этот класс MemoryUsage зависает в памяти только после того, как я использую JConsole для подключения к серверу.После первого подключения JConsole создается механизм отслеживания MemoryUsage, который начинает создавать объекты MemoryUsage.Эти объекты затем используются для рисования красивых графиков в JConsole.Это все хорошо.НО проблема в том, что JAVA 7 глючит и никогда не освобождает память.Объекты MemoryUsage навсегда висят в куче.Неважно, что вы закроете JConsole, после этого он будет расти.Когда вы в первый раз используете JConsole для подключения к процессу JAVA 7_0, вы создаете проблему и решения не существует.Просто не используйте Jconsole или любой другой инструмент мониторинга памяти, или не используйте Java 7. В моем сценарии я обречен, потому что мне приходится все время использовать Jconsole, а JAVA 6 для меня не вариант, потому чтоесть еще одна ошибка, которая делает утечки памяти благодаря блокировке объектов.Я сообщил об этой ошибке в ORACLE, но понятия не имею, если они ее получили, знают об этом и решают ее.Я просто жду более новой версии Java, чтобы я мог протестировать ее и прекратить перезапускать мой сервер каждые несколько дней.