В чем разница между ParallelGC и ParallelOldGC? - PullRequest
24 голосов
/ 04 июня 2011

У меня есть несколько вопросов об алгоритме GC: во-первых, когда мы используем такие параметры, как UseSerialGC, UseParallelGC, UseParallelOldGC и т. Д., Мы указываем алгоритм GC.Каждый из них может выполнять GC во всех поколениях, верно?

Например, если я использую «java -XX: + UseSerialGC», все поколения будут использовать последовательный GC в качестве алгоритма GC.

Во-вторых, могу ли я использовать ParallelGC в старом поколении и использовать SerialGC в поколении yong?

Последний как заголовок, в чем разница между ParallelGC и ParallelOldGC?

Ответы [ 4 ]

18 голосов
/ 04 июня 2011

Взгляните на Опции виртуальной машины HotSpot :

-XX: + UseParallelGC = Использовать параллельную сборку мусора для очистки. (Введено в 1.4.1).

-XX: + UseParallelOldGC = Использовать параллельную сборку мусора для полных сборок. Включение этой опции автоматически устанавливает -XX: + UseParallelGC. (Введено в 5.0 обновление 6.)

где Scavenges = молодое поколение GC.

7 голосов
/ 05 июля 2018

Что ж, после многих поисков и исследований я понял следующее:

-XX: + UseParallelGC - это позволяет GC использовать несколько потоков in Молодое поколение , но для старого / старшего поколения все еще Используется алгоритм Serial Mark and Compact .

-XX: + UseParallelOldGC -Это позволяет GC использовать Parallel Mark и Compact алгоритм в старом / постоянном поколении.

Давайте разберемся -

Алгоритм и расположение памяти,например, пометка и копирование, обмен местами, который работает в Молодое поколение не работает для Старое поколение по многим причинам

Низкая смертность - В старом поколении «уровень смертности» значительно ниже, чем в молодом поколении.В типичном Java-приложении большинство объектов быстро умирают, а немногие живут дольше.Как объекты, которые выживают в молодом поколении и продвигаются к старому поколению, наблюдается, что эти объекты стремятся жить дольше.Что приводит к очень меньшей смертности в старом поколении по сравнению с молодым поколением.

Значительный размер - Старое поколение значительно больше, чем молодое поколение.Поскольку молодое поколение быстро проясняется, для многих недолговечных объектов (относительно маленького молодого поколения) доступно относительно мало места.В старом поколении объекты накапливаются со временем.Следовательно, в старом поколении должно быть гораздо больше места, чем в молодом поколении (большое старое поколение)

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

С учетом этих различий для молодого поколения был выбран алгоритм, который завершит сбор мусора как можно скорее, потому что его приходится часто вызывать из-за высокого уровня смертности [пункт (1)].Кроме того, алгоритм должен обеспечить максимально эффективное распределение памяти [точка (3)], поскольку в молодом поколении выделяется много.Алгоритм пометки и копирования в Молодом Поколении обладает этими свойствами.

С другой стороны, , этот алгоритм не имеет смысла для Старого Поколения.Ситуация иная: сборщик мусора должен заботиться о многих объектах в старом поколении [пункт (2)], и большинство из них все еще живы;только небольшая часть стала недоступной и может быть освобождена [пункт (1)].Если бы сборщик мусора копировал все выжившие объекты в каждой сборке мусора, так же, как это делает метка-и-копия, то он потратил бы много времени, копируя его, не получая много.

Поэтому , алгоритм mark-and-sweep создан для старого поколения, где ничего не копируется, а просто недоступные объекты освобождаются.Поскольку этот алгоритм приводит к фрагментации кучи, дополнительно рассматривается вариант алгоритма разметки и развертки, в котором после фазы развертки выполняется сжатие, с помощью которого фрагментация снижается.Этот алгоритм называется алгоритмом mark-and-compact .

A mark и compact алгоритма может занимать много времени, так как для его обхода необходимо выполнить следующие действия:Этапы.

  1. Маркировка.
  2. Расчет новых локаций.
  3. Справочные настройки.
  4. Перемещение

В фазе Вычисление новой локации , когда она получает свободное пространство, пытается найти объект, который может переместиться в это пространство ( дефрагментация ).Сохраняет пару для использования на более поздних этапах.Это приводит к тому, что алгоритм занимает больше времени.

Хотя отметка и сравнение решают некоторые проблемы, относящиеся к генерации с постоянным доступом, у него есть серьезная проблема, поскольку это событие STW (остановка мира), и оно потребляет много времени, можетсерьезно повлиять на приложение.

Альтернативные алгоритмы для старого поколения

Для сокращения времени разрыва были рассмотрены альтернативы последовательному алгоритму разметки и компактности.:

Параллельный разметочный и компактный алгоритм , который по-прежнему фиксирует все потоки приложения, но затем обрабатывает маркировку и последующее сжатие с помощью нескольких потоков сборщика мусора.Несмотря на то, что это по-прежнему подход «остановка мира», результирующая пауза на многоядерном или многопроцессорном компьютере короче, чем в последовательном алгоритме разметки и компактности.Этот параллельный алгоритм в старом поколении (называемый «ParallelOld») был доступен после Java 5 Update 6 и выбирается с параметром -XX: + UseParallelOldGC .

A конкурирующийалгоритм mark-and-sweep , который хотя бы частично конкурирует с приложением, не останавливая его потоки, и иногда нуждается в коротких этапах остановки мира.Этот параллельный алгоритм разметки и развертки (называемый «CMS») существует с Java 1.4.1;он включается с опцией -XX: + UseConcMarkSweepGC.Важно отметить, что это всего лишь алгоритм метки и развертки;Сжатие не происходит, что приводит к уже обсуждаемой проблеме фрагментации.

Таким образом, в двух словах: -XX: + UseParallelOldGC используется в качестве указания на использование нескольких потоков при выполнении основного сбора с использованием Mark and Compact алгоритм.Если используется вместо этого, младшая или младшая коллекция параллельны, но основные коллекции все еще однопоточные.

Я надеюсь, что это ответ.

1 голос
/ 06 октября 2018

Из документов Oracle Java SE 8:

https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/collectors.html

Параллельный сборщик (также известный как сборщик пропускной способности) выполняет параллельные сборки параллельно, что может значительно уменьшить количество мусорасбор накладных.Он предназначен для приложений с наборами данных среднего и большого размера, которые работают на многопроцессорном или многопоточном оборудовании.Параллельный сборщик выбирается по умолчанию на определенных конфигурациях оборудования и операционной системы или может быть явно включен с параметром -XX: + UseParallelGC.

Параллельное сжатие - это функция, которая позволяет параллельному сборщику выполнять основные сборки впараллельно.Без параллельного уплотнения основные коллекции выполняются с использованием одного потока, что может значительно ограничить масштабируемость.Параллельное сжатие включено по умолчанию, если указан параметр -XX: + UseParallelGC.Можно отключить эту опцию -XX: -UseParallelOldGC.

Поэтому, если вы укажете -XX: + UseParallelGC, по умолчанию основная коллекция также будет выполняться с использованием нескольких потоков.Обратное также верно, т. Е. Если вы укажете -XX: + UseParallelOldGC, второстепенные коллекции также будут выполняться с использованием нескольких потоков.

1 голос
/ 11 августа 2015

Это две политики gc, применяемые к разным областям кучи Java, а именно к новому и старому поколениям. Вот ссылка, которая помогает уточнить, какие варианты подразумевают другие. Это особенно полезно, когда вы начинаете понимать, что вы получаете, когда вы указываете, скажем, ParallelOldGC или ParNewGC. http://www.fasterj.com/articles/oraclecollectors1.shtml

...