Влияние параметров кучи на GC/производительность?

Большая часть места в сети, я получаю ниже информации о параметрах кучи

-Xms<size> set initial Java heap size -Xmx<size> set maximum Java heap size

Вот мое понимание/вопрос, когда я упоминаю параметры -Xms 512M -Xmx 2048M,

-Xms: - Мое понимание заключается в том, что для моего Java-процесса на самом деле требуется только 200M с упоминанием -Xms 512M, java-процесс по-прежнему будет назначен только 200M (требуется фактическая память) вместо 500M, Но если я уже знаю, что мое приложение собирается взять эту 512M-память при запуске, то указание меньше, чем будет иметь влияние на производительность, так как любой кусок блока должен быть изменен, что является дорогостоящей операцией.

За обсуждение с моим коллегой. По умолчанию GC будет срабатывать на 60% от значения Xms. Это верно? Если да, то это небольшой GC или полный GC, который зависит от значения Xms?

Обновление на Xms: -  Это кажется правдой после прочтения параметров кучи JVM, но по умолчанию это значение 60%, и является ли это незначительным или полным GC, который зависит от значения Xms?

-Xmx: - Мое понимание заключается в упоминании -Xmx 2048M, Java-процесс на самом деле собирается зарезервировать память 2048M для его использования с ОС, так что другому процессу не может быть предоставлена ​​его доля. Если Java-процесс, необходимый как угодно больше, чем 2048M памяти, тогда из памяти будет выброшено.

Кроме того, я считаю, что существует некоторое отношение триггера Full GC к значению -Xmx. Поскольку я наблюдал, когда память достигает около 70% Xmx, Full GC происходит в jconsole. Это правильно?

Конфигурация: Я использую linux box (64-битный JVM 8). По умолчанию GC i.e Parallel GC

Ответы

Ответ 1

GC не запускается на основе только значения Xms или Xmx.

Куча = Новое + Старые поколения
Размер кучи (первоначально установленный на Xms) разделен на 2 поколения - Новый (он же Янг) и Старый (ака Тьюринга). Новое поколение по умолчанию 1/3-го от общего размера кучи, а у старого поколения 2/3 от размера кучи. Это можно настроить с помощью параметра JVM под названием NewRatio. Его значение по умолчанию равно 2.

Молодое поколение далее делится на районы Идена и 2 Оставшихся в живых. Соотношение по умолчанию для этих трех пространств: 3/4th, 1/8, 1/8.

Боковое примечание. Речь идет о параллельных сборщиках GC. Для G1 - новый алгоритм GC по-разному делит пустое пространство.

Незначительный GC Все новые объекты выделены в пространстве Eden (кроме массивных, которые хранятся непосредственно в старом поколении). Когда пространство Eden заполняется, запускается Minor GC. Объекты, которые выдержали несколько второстепенных GC, продвигаются до старого поколения (по умолчанию это 15 циклов, которые можно изменить с помощью параметра JVM: MaxTenuringThreshold).

Основной GC В отличие от параллельного коллектора, где Major GC запускается на основе используемого пространства (по умолчанию 70%), параллельные сборщики вычисляют порог на основе 3 целей, упомянутых ниже.

Цели параллельных коллекторов

  • Максимальное время паузы GC - Максимальное время, затрачиваемое на выполнение GC
  • Пропускная способность - процентное время, затрачиваемое на GC vs Application. По умолчанию (1%)
  • След - максимальный размер кучи (Xmx)

Таким образом, по умолчанию Parallel Collector пытается потратить максимум 1% от общего времени работы приложения в Garbage Collection.

Подробнее здесь

Xms to Xmx
Во время запуска JVM создает кучу размера Xms, но резервирует дополнительное пространство (Xmx), чтобы иметь возможность расти позже. Это зарезервированное пространство называется Virtual Space. Обратите внимание, что он просто резервирует пространство и не фиксирует.

2 параметра определяют, когда размер кучи растет (или уменьшается) между Xms и Xmx.

  • MinHeapFreeRatio (по умолчанию: 40%). Когда свободное пространство кучи опускается ниже 40%, срабатывает Full GC, а размер кучи увеличивается на 20%. Таким образом, размер кучи может продолжать расти постепенно, пока не достигнет Xmx.
  • MaxHeapFreeRatio (по умолчанию: 70%). На оборотной стороне свободное пространство кучи пересекает 70%, затем размер кучи уменьшается на 5% постепенно в течение каждого GC до тех пор, пока он не достигнет Xms.

Эти параметры могут быть установлены во время запуска. Подробнее об этом здесь и здесь.

PS: JVM GC - увлекательная тема, и я бы рекомендовал прочитать эту , чтобы понять ее подробно. Все параметры настройки JVM можно найти здесь здесь.