Java: Как оптимизировать распределение кучи и сборку мусора?

#java #spring #jvm #spring-batch #heap-memory

Вопрос:

У меня есть пакетное приложение spring, оно потребляет ~16 ГБ памяти и 75% процессора(4 ядра X2, 5 ГГц), и иногда оно выбрасывает исключение из памяти.

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

Я не мог понять некоторые из этих параметров, так как копировал вставленные непосредственно из статьи

JAVA_OPTS=»-сервер -Xmx20480m -Xms512m -начала XX: UseConcMarkSweepGC -начала XX: UseParNewGC -начала XX: CMSClassUnloadingEnabled -начала XX: CMSParallelRemarkEnabled -XX вв.:CMSInitiatingOccupancyFraction=30 -начала XX: CMSIncrementalMode -XX вв.: CMSIncrementalPacing -ХХ:ParallelCMSThreads=2 -ХХ: UseCMSCompactAtFullCollection -начала XX: DisableExplicitGC -начала XX:MaxHeapFreeRatio=70 -XX вв.:MinHeapFreeRatio=40 -начала XX:MaxTenuringThreshold=0 -начала XX:NewSize=450м -начала XX:MaxNewSize=650м»

действительно ли это оптимизирует распределение кучи и сборку мусора и устранит исключение нехватки памяти?

Комментарии:

1. Сначала нужно было бы проанализировать дамп кучи java. Особенно партии могут раздуться, и их следует содержать в чистоте. Сделайте SonarLint для действительно легкого ремонта И профилирования для структурных горлышек бутылок. Более быстрые пакеты с меньшим количеством ресурсов более важны, чем можно было бы подумать.

2. отбросьте CMS , он старый, его никто не поддерживает, и он был удален в jdk-14.

Ответ №1:

Во-первых, вам нужно создать дамп кучи процесса, когда он выдает ошибку OOM. Вы можете сделать это, добавив -XX: HeapDumpOnOutOfMemoryError опцию JVM. После того, как у вас будет дамп кучи, попробуйте использовать любой из следующих инструментов для анализа вашего дампа кучи. Найдите, какой объект растет в памяти, а затем оптимизируйте его. Инструменты анализа дампа кучи-это :

  1. Анализатор памяти Eclipse
  2. Куча Героев
  3. jxray

Ответ №2:

Эта ошибка обычно возникает, когда недостаточно места для размещения объекта в куче Java или если процесс Java тратит более 98% своего времени на сборку мусора и если он восстанавливает менее 2% кучи и выполнял до сих пор последние 5 циклов сбора мусора.

Я бы сначала использовал профилировщик Java, чтобы определить, какие методы выделяют большое количество объектов в куче, и убедиться, что на них больше нет ссылок после того, как они больше не нужны. Если это не устранит проблему, и я подтвердил, что мне нужны все объекты, другим вариантом будет увеличение максимального размера кучи программы.

Ответ №3:

  • Это также может произойти, когда вы используете слишком много «строковых» объектов или обновляете эти строки снова и снова.
  • Строки хранятся в пуле хэшированных строк, который находится в пространстве кучи. Когда вы манипулируете строкой, новая строка формируется и сохраняется в другом пуле (хэшированные пулы), но исходная строка не удаляется до тех пор, пока сборщик мусора не сделает это.
  • Если мы используем StringBuilder или StringBuffer (оба являются изменяемыми, в отличие от строк), пространство используется лучше.

Прочитайте больше о неизменяемости строк и о том, почему предпочтительнее использовать stringbuilder, когда вам нужно выполнить множество операций со строками.

StringBuilder-Строковый буфер-Строки в java
Почему строки неизменяемы в java?