спецификации, руководства, описания, API

Эргономика Сборщика "мусора"

Следующие изменения вступают в силу с J2SE 5.0.

Сборщик "мусора" Сервера VM, Измененный, чтобы быть Параллельным Сборщику "мусора"

На машинах сервера-class, выполняющих сервер VM, сборщик "мусора" (GC) изменился от предыдущего последовательного коллектора (-XX:+UseSerialGC) к параллельному коллектору (-XX:+UseParallelGC). Можно переопределить это значение по умолчанию при использовании -XX:+UseSerialGC параметр командной строки к java команда.

Начальный Размер "Кучи" и Максимальный Размер "Кучи", Измененный для Параллельного Сборщика "мусора"

На машинах сервера-class, работающих или VM (клиент или сервер) с параллельным сборщиком "мусора" (-XX:+UseParallelGC) начальный размер "кучи" и максимальный размер "кучи" изменились следующим образом.

начальный размер "кучи": Больше из 1/64-ой из физической памяти машины на машине или некотором разумном минимуме. Перед J2SE 5.0, размер "кучи" начальной буквы значения по умолчанию был разумным минимумом, который изменяется платформой. Можно переопределить это значение по умолчанию, используя -Xms параметр командной строки.
максимальный размер "кучи": Меньший из 1/4-ой из физической памяти или 1 Гбайт. Перед J2SE 5.0, размер "кучи" максимума значения по умолчанию составлял 64 МБ. Можно переопределить это значение по умолчанию, используя -Xmx параметр командной строки.

Отметьте: границы и части, данные для размера "кучи", корректны для J2SE 5.0. Они, вероятно, будут отличаться в последующих выпусках, поскольку компьютеры становятся более мощными.

Параллельный Сборщик "мусора" Выдает Исключение если Чрезмерное Количество времени Потраченное Небольшое количество Сбора "Кучи"

Параллельный сборщик "мусора" (UseParallelGC) выдает исключение из памяти, если чрезмерное количество времени проводится, собирая небольшое количество "кучи". Чтобы избежать этого исключения, можно увеличить размер "кучи". Можно также установить параметры -XX:GCTimeLimit=ограничение по времени и -XX:GCHeapFreeLimit=предел пространства, где:

ограничение по времени:: Верхний предел количества времени, проведенного в сборке "мусора" в процент полного времени (значение по умолчанию 98).
предел пространства:: Более низкий предел на количестве пространства, освобожденного во время сборки "мусора" в проценте максимальной "кучи" (значение по умолчанию 2).

Реализация-XX: + UseAdaptiveSizePolicy, Используемый Параллельным Измененным Сборщиком "мусора"

Реализация -XX:+UseAdaptiveSizePolicy используемый по умолчанию с -XX:+UseParallelGC сборщик "мусора" изменился, чтобы рассмотреть три цели:

требуемая максимальная цель паузы GC
требуемая цель пропускной способности приложения
минимальное место

Проверки реализации (в этом порядке):

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

Флаги

-XX:MaxGCPauseMillis=nnn

Подсказка к виртуальной машине, что времена паузы nnn миллисекунд или меньше требуется. VM скорректирует размер "кучи" java и другие связанные с GC параметры в попытке сохранить вызванные GC паузы короче чем nnn миллисекунды. Отметьте, что это может заставить VM уменьшать полную пропускную способность, и в некоторых случаях VM не будет в состоянии удовлетворить требуемой цели времени паузы.

По умолчанию нет никакой цели времени паузы. Есть определенные ограничения на то, как хорошо цели времени паузы можно удовлетворить. Время паузы для GC зависит от количества живых данных в "куче". Незначительные и главные наборы зависят по-разному от количества живых данных. Этот параметр должен использоваться с осторожностью. Значение, которое является слишком маленьким, заставит систему проводить чрезмерное количество времени, делающее сборку "мусора".

-XX:GCTimeRatio=nnn

Подсказка к виртуальной машине, что это является требуемым что не больше чем 1 / (1 + nnn) времени выполнения приложения быть потраченным в коллекторе.

Например -XX:GCTimeRatio=19 устанавливает цель 5 % полного времени для GC и цели пропускной способности 95 %. Таким образом, приложение должно получить в 19 раз больше времени как коллектор.

По умолчанию значение 99, означая, что приложение должно получить по крайней мере в 99 раз больше времени как коллектор. Таким образом, коллектор должен работать не больше 1 % полного времени. Это было выбрано как хороший выбор для серверных приложений. Значение, которое слишком высоко, заставит размер "кучи" расти к ее максимуму.

Предложенная стратегия

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

В идеальной ситуации "куча" вырастет к значению (меньше чем максимум), который будет поддерживать выбранную цель пропускной способности.

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

Если цели пропускной способности можно удовлетворить, но есть паузы, которые являются слишком длинными, выбирают цель времени паузы. Это будет, вероятно, означать, что Вашей цели пропускной способности не удовлетворят, так выберет значения, которые являются приемлемым компромиссом для приложения.

Свяжитесь с Нами