Почему сборщик мусора Java включается, когда есть много доступной оперативной памяти? - PullRequest
2 голосов
/ 18 октября 2011

C # dev здесь, вынужден иметь дело с Java ... Я взаимодействую с веб-службой Java, которая требует достаточно много памяти и ресурсов процессора. Это .

Факты:

  • Работает под Tomcat и это Java 1.6.x
  • Это все на Windows Server 2008 R2, x64 с 32 ГБ оперативной памяти.
  • Tomcat настроен на 16 ГБ ОЗУ
  • Веб-служба обычно потребляет около 6,5 ГБ.

Время от времени веб-служба подвергается воздействию штормов «Сборщика мусора», что замедляет обработку (как определено поставщиком веб-службы Java).

Мой вопрос, мало знающий о Java GC, почему GC даже начинает работать, если имеется достаточно оперативной памяти. Есть ли какая-либо настройка, которая заставляет его пинать, когда осталось мало памяти?

Моя система отсчета - это .NET GC, которая срабатывает только при нехватке памяти.

Ответы [ 5 ]

7 голосов
/ 18 октября 2011

В Java доступно несколько моделей сбора мусора.Вы можете поэкспериментировать, чтобы увидеть, какой из них имеет наименьшее влияние в вашем конкретном случае использования.См .:

Некоторое время назад мне удалось добиться гораздо более плавной / предсказуемой производительности в веб-службе, выбрав соответствующуюКоллекционная модель.

4 голосов
/ 18 октября 2011

Вам нужен профилировщик.Два хороших варианта - это JProfiler и YourKit.Любой из них покажет вам точно, что происходит, так что ни вы, ни люди здесь не должны пытаться угадать.

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

3 голосов
/ 18 октября 2011

Честно говоря, причин для такого поведения может быть много. При вышеупомянутых обстоятельствах вам, вероятно, придется настроить сборщик мусора в соответствии с вашими результатами. У Oracle есть отличный ресурс на http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

В основном, для краткости ГХ по умолчанию, существует 2 типа прогонов: 1) Частичный ГХ, где освобождаются объекты молодого возраста. 2) Полный сборщик мусора, где сбор мусора выполняется над всеми объектами.

Можете ли вы указать в журнале аргументы в виде -XX: + PrintGCDetails -XX: + PrintGCTimeStamps. Ваша задержка может быть связана с полным сбором мусора, так как частичный сборщик мусора, как правило, не боится повреждений Как вы сказали, доступно много оперативной памяти, но не могли бы вы указать выделенный размер кучи. При любом повреждении это происходит из-за частичного ГХ (вероятность низкая), затем один раз попробуйте с одновременной меткой и разверните, используя + UseConcMarkSweepGC, так как это сделано специально для больших потерь в частичном ГХ

2 голосов
/ 18 октября 2011

Большинство Java-сборщиков мусора работают только по мере необходимости. В целом, увеличение объема памяти приводит к менее частому и более длительному сбору мусора. Обычно сборщик мусора ленив, что означает, что он действительно начнет пытаться восстановить внутреннюю память только тогда, когда куча достигает своего максимального размера. , Если вы не установите верхний предел, среда выполнения будет продолжать увеличиваться до тех пор, пока не будет использован каждый доступный бит памяти в вашей системе.

Sun JVM использует фиксированный верхний предел для размера своего пула выделения памяти (-Xmx). Вы можете вручную изменить предел (параметр -Xmx)

1 голос
/ 29 октября 2011

Может случиться так, что размер разных поколений будет неправильным.

Хорошая статья об этом http://java.sun.com/docs/hotspot/gc1.4.2/

...