Что потребляет память в процессе Java?

Проблема может быть связана с этим проблема с glibc.

По сути, когда у вас есть несколько потоков, выделяющих память, glibc будет увеличивать количество доступных арен для выделения, чтобы избежать конфликта блокировок. Размер арены - 64 Мб. Верхний предел - создание арен в 8 раз большее количество ядер. Арены будут создаваться по запросу, когда поток обращается к арене, которая уже заблокирована, поэтому она со временем увеличивается.

В Java, где вы разбрасываете потоки, это может быстро привести к созданию множества арен. И распределения распределяются по всем этим аренам. Первоначально каждая арена размером 64 Мбайт - это просто отображенная незавершенная память, но по мере выделения вы начинаете использовать для них реальную память.

Скорее всего, ваш pmap содержит списки, подобные приведенным ниже. Обратите внимание, как 324K + 65212K = 65536K, 560K + 64976K == 65536K, 620K + 64916K == 65536K. То есть в сумме они составляют 64Мб.

00007f4394000000    324K rw---    [ anon ]
00007f4394051000  65212K -----    [ anon ]
00007f4398000000    560K rw---    [ anon ]
00007f439808c000  64976K -----    [ anon ]
00007f439c000000    620K rw---    [ anon ]
00007f439c09b000  64916K -----    [ anon ]

Что касается обходные пути: В ошибке упоминаются некоторые параметры среды, которые вы можете установить для ограничения количества арен, но вам нужна достаточно высокая версия glibc.

Как насчет Ламдба Зонд? Среди прочего, он может показать вам разбивку использования памяти, как на скриншоте ниже:

Иногда pmap -x your_java_pid также может быть полезным.

JProfiler может быть тем, что вы ищете, но это не бесплатно. Еще один хороший и бесплатный инструмент для исследования использования памяти Java-процессом - это Java VisualVM, доступный как инструмент JDK в дистрибутивах Oracle / Sun JDK. Я лично рекомендую более целостный подход к проблеме (т.е. для мониторинга JDK + OS + дисков и т. Д.) - использование какой-либо системы мониторинга сети - Nagios, Verax NMS или OpenNMS.

Проблема находится вне кучи, поэтому лучшими кандидатами являются:

JNI leak  
Allocation of direct memory buffer

Из-за того, что вы ограничили размер прямого буфера, лучшим кандидатом, на мой взгляд, является утечка JNI.

Существует удобный инструмент для просмотра распределения памяти кучи, включенной в JDK, под названием jmap, помимо этого у вас также есть стек и т. Д. (Xss). Выполните эти две команды jmap, чтобы получить дополнительную информацию об использовании памяти:

jmap -heap <PID>
jmap -permstat <PID>

Чтобы получить еще больше информации, вы можете подключиться к процессу с помощью jconsole (также включенного в JDK). Однако Jconsole требует, чтобы JMX был настроен в приложении.

Используйте JVisualVM. Он имеет различные представления, которые сообщают вам, сколько памяти кучи используется, PermGen и так далее и так далее.

Что касается ответа на ваш вопрос. Java обрабатывает память совсем не так, как вы могли ожидать.

Когда вы устанавливаете параметры -Xms и -Xmx, вы сообщаете JVM, сколько памяти она должна выделить в куче для начала, а также сколько она должна выделить как максимум.

Если у вас есть приложение Java, которое использовало в общей сложности 1 м памяти, но передало в -Xms256m -Xmx2g, тогда JVM инициализируется с использованием 256 м памяти. Он не будет использовать меньше этого. Не имеет значения, что ваше приложение использует только 1 м памяти.

Во-вторых. В приведенном выше случае, если ваше приложение в какой-то момент использует более 256 МБ памяти, JVM выделит столько памяти, сколько необходимо для обслуживания запроса. Однако это не буду уменьшите размер кучи до минимального значения. По крайней мере, не в большинстве случаев.

В вашем случае, поскольку вы устанавливаете минимальную и максимальную память на 2g, JVM будет выделять 2g в начале и поддерживать его.

Управление памятью Java довольно сложно, и настройка использования памяти может быть задачей сама по себе. Однако есть много ресурсов, которые могут помочь.