Java-программа с 16 ГБ виртуальной памяти и ростом: это проблема?

Подозреваю, что это тоже утечка. Но это не может быть утечка «нормальной» памяти, потому что опция -Xmx1024m ограничивает обычную кучу. Точно так же это не будет утечка кучи «permgen», потому что максимальный размер permgen по умолчанию мал.

Поэтому я подозреваю, что это одно из следующего:

• Вы пропускаете потоки; то есть потоки создаются, но не завершаются. Они могут быть не активны, но у каждого потока есть сегмент стека (от 256 КБ до 1 МБ по умолчанию... в зависимости от платформы), который не выделен в обычной куче.

• Вы пропускаете файлы прямого сопоставления. Они сопоставляются с сегментами памяти, выделенными ОС за пределами обычной кучи. (@bestsss предлагает вам искать дескрипторы просочившихся ZIP-файлов, что, я думаю, будет частным случаем этого.)

• Вы используете некоторый код JNI/JNA, в котором происходит утечка распределенной памяти или что-то подобное.

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

Утечка памяти JVM также возможна, но неразумно начинать подозревать JVM до тех пор, пока вы окончательно не устраните возможные причины в своем собственном коде и библиотеках/приложениях, которые вы используете.

Поскольку ваше приложение не является приложением реального времени, вы можете сделать следующее:

jps -v

Получите идентификатор процесса из этой таблицы и сохраните его как pid.

jmap -histo $pid > before-gc.hgr
jmap -histo:live $pid > after-gc.hgr
jstack -v $pid > threads.txt

Файл threads.txt говорит вам, что процесс делает в данный момент.

Гистограммы использования кучи before-gc.hgr и after-gc.hgr показывают, сколько памяти может освободить полная сборка мусора.

Может быть, вы получите некоторые намеки на то, что происходит.

Правильно ли вы NULL делаете все ссылки после того, как закончите с объектами? Интересно, это простая утечка памяти...

Я видел такое поведение в программах на C, которые смешивают большое количество выделений и освобождений для объектов разного размера. Вы можете получить страницы памяти, которые используются наполовину, но не имеют дыр достаточно больших, которые можно было бы использовать для удовлетворения новых запросов памяти.

Это не только вызывает подкачку, но и разрушает локальность ссылок с течением времени — подкачка становится хуже, а затем намного хуже.

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

Конечно, сделать это в управляемой среде, такой как Java, может быть сложно. Можно было бы надеяться, что JVM уже делает это. (Учитывая, что управляемые среды могут обновлять ссылки на новые области памяти и периодически переупаковывать, даже простой подход к распределению памяти должен предотвратить появление глупых дыр.)

Указание на наличие проблемы обычно исходит от трафика подкачки. Если вы видите большой трафик подкачки в своей системе, даже когда RSS (размер резидентного набора) процесса остается стабильным, то вы можете выполнять тонны операций ввода-вывода на диск для операций, которые кажутся полностью выполняемыми в памяти. В Linux и некоторых других системах Unix информацию о трафике подкачки можно найти с помощью команды vmstat 1:

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0      0 727392 351128 3846980    0    0    13    16   41   73  3  1 96  0
 0  0      0 727392 351128 3846988    0    0     0     0 1267 4742  5  1 95  0
...

Столбцы si и so показывают блоков в секунду. (Ну, какой бы временной интервал вы ни выбрали с помощью vmstat 1, vmstat 2 и так далее.)

Если трафик подкачки низкий, то вам, вероятно, не о чем беспокоиться. Если трафик подкачки высок, вам обязательно нужно попытаться выяснить, почему вы выполняете подкачку. Это требует больше работы. :)

Для меня это определенно звучит как утечка памяти. Вам следует исследовать с помощью профилировщика кучи, такого как VisualVM (который поставляется с вашим JDK).

Редактировать: я упустил ваш предел кучи. Так что на самом деле это не может быть простой утечкой памяти Java (хотя может быть так, что по какой-то причине размер кучи игнорируется - все же стоит проверить). Другая возможность заключается в том, что ваше приложение удерживает большое количество ресурсов памяти, не относящихся к куче, таких как одноранговые узлы собственного графического интерфейса (окна, которые скрыты, но не депонированы), потоки (объекты потоков малы, но имеют большой объем памяти стека, который может никогда не освобождаться, если поток, например, создан, но не запущен) или IO (не знаю, как это может занимать столько памяти до исчерпания дескрипторов файлов). На более глубоком уровне это может быть проблема выделения памяти, как писал Сарнольд, или утечка памяти внутри самой JVM.

Если jvisualvm не сообщает о чрезмерном использовании памяти, это превращается в проблему приложения OS X, где приложением является JVM.

Я предлагаю вам открыть такой вопрос вместо этого.

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

В любом случае вы можете попробовать подключиться к процессу с помощью инструмента VisualVM и посмотреть, что происходит с выделением памяти и освобождение.

Кроме того, существует довольно много -XX: options для отладки сборки мусора они могут предоставить еще больше информации.