Успокаивающий возбужденный сборщик мусора

Question

У меня есть программа, которая очень счастливо работает с -Xmx2g. С -Xmx1g он останавливается. Он никогда не получает исключение из памяти - или, по крайней мере, у меня никогда не было терпения ждать достаточно долго.

Это говорит о том, что общий размер места вписывается в 1g, но что GC испытывает некоторое беспокойство по поводу возможного выхода из космоса.

Отпечаток памяти - это комбинация некоторых крупных, стабильных предметов с большим количеством эфемерного трафика.

Существуют ли какие-либо более или менее неясные варианты GC, имеющие отношение к этой ситуации?

Answer 1

В большинстве случаев может потребоваться . Это связано с тем, что, когда GC начинает работать, он останавливает все действия в вашей программе. Если вы обычно получаете, скажем, 1 секунду полезного времени программы за каждые 0,01 секунды времени GC, в этих случаях вы можете увидеть, что она полностью отменена - 0,01 с полезного программного времени для каждых 1 с GC времени. При такой скорости может потребоваться смехотворное долгое время, чтобы съесть последние 512 тыс. Кучи 1 ГБ.

VisualVM и его плагин VisualGC - ваши друзья; их графики будут отображать различные шаблоны, когда вы находитесь в таком состоянии.

Answer 2

Существует множество вариантов, которые вы можете установить на JVM для сбора мусора с помощью http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html. Когда приложение останавливается из-за GC, вы обычно видите много крупных сборок, которые могут остановить все при сборе. Вы можете настроить мелкие и основные параметры сбора, чтобы увидеть, есть ли у вас более частые второстепенные коллекции.

Я рекомендую взглянуть на то, что едят кучу, используя такой инструмент, как VisualVM (поставляется с JDK6, я считаю, обновляет 7+) и анализирует графические объекты. Также рассмотрите инструменты для анализа файла hprof (How do I analyze a .hprof file?).

Answer 3

Похоже, вы не получили достаточную кучу JVM. Конечно, рабочий набор может поместиться в 1 Гбайт, но вам все равно нужно дать ему больше. Чтобы понять, почему, читайте дальше.

Предположим, что при выполнении сборщик мусора, он делает количество работы W1, которое пропорционально количеству не-мусора, который он просматривает, чтобы идентифицировать мусор и другой объем работы W2, которая пропорциональна количество мусора, которое он находит. (На самом деле, это немного сложнее, чем это ... но давайте держать анализ простым.)

Предположим, что у вас есть куча 1Gb кучи с 0.9Gb, занятая доступными объектами. Каждый раз, когда GC запускается, он может восстановить не более 0,1 Гбайт кучного пространства, и при этом ему необходимо выполнить W1 * 0.9Gb + W2 * 0.1Gb работы. Объем работы на один байт, обработанный, равен (W1 * 0.9Gb + W2 * 0.1Gb)/0.1Gb; т.е. 9 * W1 + W2.

Теперь предположим, что у вас есть куча 2Gb с 0.9Gb, занятая доступными объектами. Теперь количество исправленных работ на байт составляет (W1 * 0.9Gb + W2 * 1.1Gb)/1.1Gb или W1 * 9/11 + W2.

Если вы сравните эти два, вы увидите, что GC делает примерно W1 * 8 больше работы за каждый байт, исправленный в куче 1Gb по сравнению с кучей 2Gb.

Как правило, чем ближе к полному вы запускаете кучу, тем более неэффективным будет сборщик мусора.Уроки:

• Настройка виртуальной машины Java, чтобы использовать щедрое кучу, и

• Настройка виртуальной машины Java, чтобы бросить OOM, если есть меньше, чем (скажем) 25% от кучи бесплатно после запуска полный GC.

Answer 4

Если вы wan't сделать некоторые тонкой настройки необходимо проверить MinHeapFreeRatio и MaxHeapFreeRatio параметры среди других здесь Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning мы проделали это sould привести к «эффекту транквилизатор».