#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. После того, как у вас будет дамп кучи, попробуйте использовать любой из следующих инструментов для анализа вашего дампа кучи. Найдите, какой объект растет в памяти, а затем оптимизируйте его. Инструменты анализа дампа кучи-это :
Ответ №2:
Эта ошибка обычно возникает, когда недостаточно места для размещения объекта в куче Java или если процесс Java тратит более 98% своего времени на сборку мусора и если он восстанавливает менее 2% кучи и выполнял до сих пор последние 5 циклов сбора мусора.
Я бы сначала использовал профилировщик Java, чтобы определить, какие методы выделяют большое количество объектов в куче, и убедиться, что на них больше нет ссылок после того, как они больше не нужны. Если это не устранит проблему, и я подтвердил, что мне нужны все объекты, другим вариантом будет увеличение максимального размера кучи программы.
Ответ №3:
- Это также может произойти, когда вы используете слишком много «строковых» объектов или обновляете эти строки снова и снова.
- Строки хранятся в пуле хэшированных строк, который находится в пространстве кучи. Когда вы манипулируете строкой, новая строка формируется и сохраняется в другом пуле (хэшированные пулы), но исходная строка не удаляется до тех пор, пока сборщик мусора не сделает это.
- Если мы используем StringBuilder или StringBuffer (оба являются изменяемыми, в отличие от строк), пространство используется лучше.
Прочитайте больше о неизменяемости строк и о том, почему предпочтительнее использовать stringbuilder, когда вам нужно выполнить множество операций со строками.
StringBuilder-Строковый буфер-Строки в java
Почему строки неизменяемы в java?