Параллельный сборщик мусора или Parallel GC, также его называют throughput collector, схож с Serial GC. Он тоже использует деление на молодое и старшее поколения. И также он использует области Eden и Survivor. Однако порядок областей другой:
Включить параллельный сборщик мусора можно с помощью аргумента -XX:+UseParallelGC, переданного в качестве параметра командной строки виртуальной машины Java. Параллельный сборщик мусора выбирается по умолчанию для серверных машин.
По умолчанию параллельно основным потокам программы происходит сборка мусора как из молодого поколения, так и полная.
Параллельный сборщик мусора особенно полезен для систем с несколькими физическими процессорами. Для машин с N физическими процессорами Parallel GC создаёт N потоков для случая N<8 и целую часть от дроби 5/8 при N>=8.
Количество создаваемых потоков можно задать с помощью командной строки -XX:ParallelGCThreads=<N>.
Так как при сборке мусора работают несколько потоков, то при перемещении объектов из молодого поколения в старшее возможна фрагментация старшего поколения, так как каждому потоку выделяется своя, изолированная от остальных область в tenured.
При тюнинге parallel GC можно указать не размеры поколений и другие низкоуровневые параметры, а более высокоуровневые настройки: максимальную паузу для сборки мусора, throughput (производительность) и footprint (размер кучи).
- Максимальная пауза для сборки мусора устанавливается с помощью параметра XX:MaxGCPauseMillis=<N> в миллисекундах. Причём указанное значение не всегда будет успешно выдерживаться, но сборщик мусора будет пытаться подстраивать размер кучи и другие параметры так, чтобы сборка мусора была меньше указанного здесь значения.
- Throughput или производительность устанавливается с помощью параметра -XX:GCTimeRatio=<N>, где указывается отношение времени затраченного на сборку мусора к остальному времени работы приложения. Parallel GC будет стараться придерживаться этого целевого значения производительности.
- Footprint или максимальный размер кучи устанавливается с помощью параметра -Xmx<N>, причём сборщик будет пытаться выдерживать как можно меньший размер кучи при достижении остальных целевых параметров.
Цели рассматриваются в следующем приоритете:
- Максимальная пауза при сборке мусора
- Производительность
- Минимальный размер кучи.
Если больше 98 % времени тратится на сборку мусора и удалось очистить меньше 2 % кучи, то параллельный сборщик мусора бросает исключение OutOfMemoryError.
Размеры поколений при необходимости увеличиваются и уменьшаются. По умолчанию увеличение идёт на 20 %, а уменьшение на 5 %. Эти значения настраиваются с помощью параметров командной строки. Для шага увеличения размера молодого поколения используйте параметр -XX:YoungGenerationSizeIncrement=<Y> (в процентах), для шага увеличения размера старшего поколения используйте -XX:TenuredGenerationSizeIncrement=<T> (тоже в процентах). Для шага уменьшения размеров поколения используется -XX:AdaptiveSizeDecrementScaleFactor=<D>, где процент уменьшения размера поколения вычисляется по формуле X/D, (X — процент увеличения размера поколения, D — значение параметра -XX:AdaptiveSizeDecrementScaleFactor).
Почему когда я читаю это, ничего не понимаю, хотя на Java программировать могу?
В 99 % случаев информация из этой статьи не нужна.
а 1 % — это собеседование, где этакий «умник» — собеседующий, предчувствуя свой коронный час и ехидно улыбаясь, задает в 100 для себя раз свой вызубренный вопрос….