В этой статье здесь предлагается использовать -XX:+UseParNewGC "Чтобы включить параллельный сборщик мусора молодого поколения с параллельным сборщиком мусора" .
Меня смущает то, что для того, чтобы включить как параллельный, так и параллельный GC, я должен
-XX:+UseParNewGC или-XX:+UseParNewGC и -XX:+UseConcMarkSweepGC ?Я использую JVM6.
Поскольку документ, на который вы ссылаетесь, был для виртуальной машины 1.4.2, я предполагаю, что вы используете (JVM 5 и 6 ведут себя по-разному).
Из https://web.archive.org/web/20120624153924/http://java.sun.com/docs/hotspot/gc1.4.2/
если -XX:+UseConcMarkSweepGC используется в командной строке, то флаг UseParNewGC также устанавливается в значение true, если он не установлен явно в командной строке.
Таким образом, ответ заключается в том, что вам нужно использовать только -XX:+UseConcMarkSweepGC, и это включит параллельный сборщик с параллельным сборщиком молодого поколения.
Изменить: для Java 6 тот же флаг (-XX:+UseConcMarkSweepGC) включает параллельный сборщик. Выбор коллектора, который вы хотите, зависит от нескольких вещей, и вы должны протестировать различные конфигурации. Но есть несколько очень общих рекомендаций. Если у вас есть однопроцессорная машина с одним потоком, вам следует использовать сборщик последовательных портов (по умолчанию для некоторых конфигураций, можно явно включить с помощью -XX:+UseSerialGC). Для многопроцессорных машин, где ваша рабочая нагрузка в основном привязана к процессору, используйте параллельный сборщик. Это включено по умолчанию, если вы используете флаг -server, или вы можете включить его явно с помощью -XX:+UseParallelGC. Если вы предпочитаете, чтобы паузы сборщика мусора были короче за счет использования большего общего времени ЦП для сборщика мусора, и у вас более одного ЦП, вы можете использовать параллельный сборщик (-XX:+UseConcMarkSweepGC). Обратите внимание, что параллельный сборщик, как правило, требует больше оперативной памяти, выделенной для JVM, чем последовательный или параллельный сборщики для данной рабочей нагрузки, поскольку может произойти некоторая фрагментация памяти.
Настройка java/JDK 6 GC: http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html. Это от SUN (теперь Oracle). Полный материал.
См. также
http://kirk.blog-city.com/is_your_concurrent_collector_failing_you.htm
http://www.javaperformancetuning.com/
В этой записи блога есть хорошая разбивка по различным сборщикам и допустимым вариантам: http://blogs.oracle.com/jonthecollector/entry/our_collectors
Настройка Java GC — это, по сути, темное искусство, но в моем приложении (работает с кучей 50+ ГБ и 16 физическими ядрами) сборщик ConcMarkSweep привел к 3-кратному ускорению по сравнению с -server по умолчанию и 2,2-кратному ускорению по сравнению с ParallelOldGC.
Если вы не делите машину с другими процессами (поэтому простаивающие ядра просто тратятся впустую), используйте ConcMarkSweepGC.
ParNew является коллектором молодого поколения по умолчанию при использовании CMS. Вам просто нужно указать -XX: + UseConcMarkSweepGC для использования CMS, и ParNew будет использоваться по умолчанию. CMS является хорошим коллектором, если предотвращение дрожания GC имеет более высокий приоритет, но если пропускная способность более важна, например, для пакетного задания, параллельный коллектор SUN по умолчанию работает лучше.
Вы не можете включить две опции GC одновременно. Я бы посоветовал вам использовать CMS, которая лучше, чем GC следующего поколения по сравнению с UseParNewGC. и если вы используете Java 1.7 или более позднюю версию и размер кучи относительно больше (например,> 4 ГБ), рассмотрите возможность использования G1.
