выследить распределения ИНТА []

Question

При просмотре моего удаленного применения в JVisualVM над JMX, я вижу пилообразное использование памяти во время простоя:

Принимая дамп кучи и анализ его с JVisualVM, я вижу, что большая часть памяти находится в нескольких больших массивах int[], у которых нет ссылок, и, сравнивая кучи кучи, я вижу, что они, похоже, берут память и периодически регенерируются GC.

Мне любопытно отследить их, так как это вызвало мой интерес к тому, что мой собственный код никогда не сознательно выделяет любые int[] массивы.

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

Как узнать, кто их распределяет?

Answer 1

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

Это не ответ на ваш вопрос, но мой вопрос:

Почему вы заботитесь?

Вы сказали, что сборщик мусора jvm (GC) может использовать до 1 ГБ памяти. Java использует менее 250M.

GC пытается быть умным, когда собирает мусор, а также, как сильно он работает при сборке мусора. На вашем графике нет потребности в памяти. Jvm не находится рядом с установленным пределом 1 ГБ. Я не вижу причин, по которым GC должен очень стараться. Не уверен, почему вам тоже будет интересно.

Его хорошая вещь для сборщика мусора, чтобы быть ленивым. Чем меньше работает GC, тем больше ресурсов доступно для вашего приложения.

Вы пробовали запускать GC через кнопку JVisualVM «Выполнить GC»? Эта кнопка должна инициировать операцию по сборке мусора «остановить мир». Попробуйте, когда график находится посередине одного из этих скачков зубьев пилы - я предсказываю, что использование упадет на основание пилы или ниже. Если это так, это доказывает, что зуб за память - это просто накопление мусора, и GC делает все правильно.

Вот скриншот использования памяти для приложения Java Swing, я использую:

Уведомления пилообразного узора.

Вы сказали, что беспокоитесь о int []. Когда я начинаю профайлер памяти и иметь его профиль все, что я могу видеть распределения ИНТ []

В основном все распределения приходят от метода ObjectOutputStream $ HandleTable.growEntries. Похоже, что поток, на который были сделаны выделения, был развернут для обработки сетевого сообщения.
Я подозреваю, что это вызвано самой jmx. Возможно, rmi (вы используете rmi?). Или отладчик (у вас есть отладчик подключен?).

Answer 2

Я просто подумал, что добавлю к этому вопросу, что пилообразный паттерн очень нормальный и не имеет ничего общего с вашими int[] массивами. Это происходит потому, что в Eden-gen происходят новые распределения, и только эфемерная коллекция запускается только после того, как она заполнилась, оставив старый ген. Поэтому, пока ваша программа вообще выполняет какие-либо ассигнования, генерал Eden будет заполняться, а затем повторно пустым. Тем более, если у вас есть регулярное количество ассигнований за единицу времени, вы увидите очень обычный пилообразный рисунок.

Есть тонны статей в Интернете, в которых подробно описывается, как работает GC Hotspot, поэтому мне не нужно расширять его здесь. Если вы вообще не знаете, как работает эфемерная коллекция, вы можете проверить Wikipedia's article on the subject (см. Раздел «Generational GC», «generational» и «ephemeral» являются синонимами в этом контексте).

Что же касается массивов int[], они немного загадочны. Я тоже вижу их, и есть another question here on SO на тему их без реального ответа. На самом деле это не нормально для объектов, не имеющих ссылок на отображение в дампе кучи, потому что куча кучи обычно содержит только живые объекты (поскольку Hotspot всегда выполняет стоп-мировую коллекцию до фактического сброса кучи). Моя личная догадка заключается в том, что они выделяются как часть некоторой внутренней структуры данных JVM (и поэтому имеют только ссылки из C++-части Hotspot, а не из кучи Java), но это действительно просто предположение.