Java управляет памятью кучи за вас. Вы запускаете свое приложение внутри виртуальной машины (JVM). JVM выполняет работу по выделению пространства, когда это необходимо, и освобождению его, когда оно больше не нужно. Сборщик мусора (GC) — вот что вам поможет.
Переработка памяти включает в себя «циклы» сборки мусора, которые влияют на производительность. Степень воздействия зависит от характера вашего приложения и выбранного вами GC. Хорошая новость заключается в том, что существует более одного сборщика мусора, и каждый последний выпуск Java предлагает больше вариантов. Вы можете выбрать GC, который наилучшим образом соответствует потребностям вашего приложения.
Новые сборщики мусора
В последних двух выпусках Java представлены три новых GC. Мы рассмотрим каждый из них и то, что они добавляют в экосистему.
Java 11 представила Epsilon и сборщик мусора Z (ZGC). Epsilon — это сборщик мусора без операций. Он выделяет новую память, но никогда не перерабатывает ее. ZGC обещает управлять большими объемами памяти с высокой пропускной способностью и коротким временем паузы.
Java 12 добавляет сборщик мусора Shenandoah. Как и ZGC, он управляет большими кучами с коротким временем паузы, но использует совершенно другой подход.
Сборщик мусора Эпсилон
Что такое Эпсилон?
Epsilon — это пассивный или «нерабочий» GC. Он обрабатывает выделение памяти, но не перерабатывает ее, когда объекты больше не используются. Когда ваше приложение исчерпывает кучу Java, JVM отключается. Другими словами, Epsilon позволит вашему приложению исчерпать память и сломаться.
Как использовать Эпсилон
| Параметры командной строки | Примечания |
-XX:+UnlockExperimentalVMOptions | Разблокируйте экспериментальные возможности Java. |
-XX:+UseEpsilonGC | Используйте Эпсилон ГХ |
-XmxXg | Установить размер кучи. JVM завершит работу с OutOfMemoryError, если это количество будет превышено. |
-XX:HeapDumpOnOutOfMemoryError | Создайте дамп кучи, если JVM не хватает памяти. |
-XX:OnOutOfMemoryError= | Выполнить указанную команду при возникновении ошибки нехватки памяти. |
Зачем использовать No-Op GC?
Неактивный сборщик мусора полезен для измерения производительности приложений и управления ею. Активные сборщики мусора — это сложные программы, которые запускаются внутри JVM вместе с вашим приложением. Они несут накладные расходы, которые могут вызвать задержку и снизить пропускную способность.
Epsilon устраняет влияние GC на производительность. Нет циклов GC или барьеров чтения или записи. При использовании Epsilon GC ваш код выполняется изолированно. Вы можете использовать его, чтобы увидеть, как сбор мусора влияет на производительность вашего приложения и каков ваш порог памяти, поскольку он сообщит вам, когда он закончится. Если вы думаете, что вам нужно всего четыре гигабайта памяти, запустите его -Xmx4g и посмотрите, правы ли вы. Если вы ошибаетесь, перезапустите его с XX:HeapDumpOnOutOfMemoryError включенным и посмотрите на дамп кучи, чтобы увидеть, где вы ошибаетесь.
Если вам нужно выжать из приложения все, что можно, от производительности, Epsilon может стать лучшим выбором для сборщика мусора. Но вам нужно иметь полное представление о том, как ваш код использует память. Если он почти не создает мусора или вы точно знаете, сколько памяти он использует за период, в течение которого он работает, Epsilon является приемлемым вариантом.
Сборщик мусора Z
Что такое сборщик мусора Z?
ZGC — сборщик мусора с малой задержкой, предназначенный для работы с огромными объемами памяти. Документация Oracle ссылается на многотерабайтные кучи в своем описании Z. Oracle представила ZGC в Java 11. В Java 12 Oracle добавила исправления производительности и выгрузку классов, хотя Z все еще находится в экспериментальном состоянии. Он доступен только в 64-разрядной версии Linux.
Как работает ЗГК?
ZGC работает параллельно с вашим приложением, выполняя всю свою работу в своих потоках. Он использует барьеры нагрузки для ссылок на кучу. Барьеры нагрузки вызывают меньше задержек, чем те, которые накладываются барьерами до и после записи коллектора G1.
ZGC использует преимущества 64-битных указателей с помощью метода, называемого раскрашиванием указателей. Цветные указатели хранят дополнительную информацию об объектах в куче. (Это одна из причин, по которой он ограничен 64-битной JVM.) Ограничив GC кучами размером 4 ТБ, разработчики получили 22 дополнительных бита в каждом указателе для кодирования дополнительной информации. В настоящее время Z использует четыре дополнительных бита. Каждый указатель имеет бит для финализации, переназначения, метки0 или метки1.
Сборщик мусора Z переназначает объекты, когда память становится фрагментированной. Сопоставление позволяет избежать снижения производительности, когда сборщику мусора требуется найти место для нового выделения. Цвет указателя помогает при переназначении, поскольку переназначенная ссылка обнаруживает новое местоположение при следующем доступе.
Когда ваше приложение загружает ссылку из кучи, ZGC проверяет лишние биты. Если ему нужно выполнить какую-либо дополнительную работу (например, получить переназначенный экземпляр), он обрабатывает ее в барьере нагрузки. Это нужно сделать только один раз, когда он загружает ссылку. Это отличает его от барьеров записи, используемых основными сборщиками мусора, такими как G1.
Сборщик мусора Z выполняет свои циклы в своих потоках. Он приостанавливает приложение в среднем на 1 мс. Сборщики G1 и Parallel в среднем составляют около 200 мс.
Как использовать ЗГК
| Параметры командной строки | Примечания |
-XX:+UnlockExperimentalVMOptions | Разблокируйте экспериментальные возможности Java |
-XX:+UseZGC | Используйте ЗГК. |
-XmxXg | Установить размер кучи. |
-XX:ConcGCThreads=X | Установить количество потоков GC |
ZGC — это параллельный сборщик мусора, поэтому установка правильного размера кучи очень важна. Куча должна быть достаточно большой для размещения вашего приложения, но также нуждается в дополнительном запасе, чтобы Z мог удовлетворять новые запросы при перемещении активных объектов. Объем необходимого запаса зависит от того, насколько быстро ваше приложение запрашивает новую память.
ZGC сам попытается установить количество потоков, и обычно это правильно. Но если у ZGC слишком много потоков, ваше приложение будет голодать. Если его недостаточно, вы создадите мусор быстрее, чем сборщик мусора сможет его собрать.
Зачем использовать ZGC?
Дизайн ZGC хорошо работает с приложениями большого размера кучи. Он управляет этими кучами с временем паузы менее 10 мс и незначительно влияет на пропускную способность. Эти времена лучше, чем у G1.
ZGC выполняет маркировку в три этапа. Первая — это короткая фаза остановки мира. Он проверяет корни GC, локальные переменные, которые указывают на остальную часть кучи. Общее количество этих корней обычно минимально и не масштабируется с размером нагрузки, поэтому паузы ZGC очень короткие и не увеличиваются по мере роста вашей кучи.
После завершения начальной фазы ZGC переходит к параллельной фазе. Он проходит по графу объектов и исследует цветные указатели, отмечая доступные объекты. Барьер нагрузки предотвращает конкуренцию между фазой сборки мусора и активностью любого приложения.
После того, как ZGC завершил маркировку, он перемещает живые объекты, чтобы освободить большие разделы кучи для более быстрого выделения памяти. Когда начинается фаза перемещения, ZGC делит кучу на страницы и работает с одной страницей за раз. Как только ZGC завершает перемещение всех корней, остальная часть перемещения происходит в параллельной фазе.
Фазы ZGC иллюстрируют, как он управляет большими кучами, не влияя на производительность по мере роста памяти приложения.
Шенандоа
Что такое Шенандоа?
Shenandoah — еще один сборщик мусора с коротким временем паузы. Эти времена короткие и предсказуемые, независимо от размера кучи. Shenandoah был разработан в Red Hat и существует уже несколько лет. Теперь это часть выпуска Java 12.
Как и ZGC, Shenandoah выполняет большую часть своей работы параллельно с работающим приложением. Но его подход к сбору мусора отличается. Shenandoah использует области памяти для управления тем, какие объекты больше не используются, а какие активны и готовы к сжатию. Shenandoah также добавляет указатель переадресации к каждому объекту кучи и использует его для управления доступом к объекту.
Как работает Шенандоа?
Дизайн Shenandoah обменивает параллельные циклы ЦП и пространство на улучшение времени паузы. Указатель переадресации упрощает перемещение объектов, но агрессивные перемещения означают, что Shenandoah использует больше памяти и требует больше параллельной работы, чем другие сборщики мусора. Но он выполняет дополнительную работу с очень короткими паузами в стиле «останови мир».
Фазы Шенандоа
Shenandoah обрабатывает кучу в несколько небольших этапов, большинство из которых выполняются одновременно с приложением. Такой дизайн позволяет сборщику мусора эффективно управлять большой кучей.
Первая фаза содержит первую остановку мира в цикле. Он подготавливает кучу для одновременной маркировки и сканирует корневой набор. Как и в ZGC, длина этой паузы соответствует размеру корневого набора, а не кучи. Затем на параллельной фазе выполняется обход кучи и идентификация доступных и недоступных объектов.
Третий завершает процесс маркировки, сливая ожидающие обновления кучи и повторно сканируя корневой набор. Эта фаза запускает вторую паузу в цикле «останови мир». Количество ожидающих обновлений и размер корневого набора определяют продолжительность паузы.
Затем другая параллельная фаза копирует объекты из регионов, определенных на последней фазе маркировки. Этот процесс отличает Shenandoah от других сборщиков мусора, поскольку он агрессивно сжимает кучу параллельно с потоками приложения.
Следующая фаза запускает третью (и самую короткую) паузу в цикле. Это гарантирует, что все потоки GC завершили эвакуацию. По завершении параллельная фаза проходит по куче и обновляет ссылки на объекты, перемещенные ранее в цикле.
Последняя пауза в цикле «останови мир» завершает обновление ссылок путем обновления корневого набора. В то же время он утилизирует эвакуированные регионы. Наконец, последняя фаза восстанавливает эвакуированные регионы, в которых теперь нет ссылок.
Как использовать Шенандоа
| Параметры командной строки | Примечания |
-XX:+UnlockExperimentalVMOptions | Разблокируйте экспериментальные возможности Java. |
-XX:+UseShenanodoahC | Используйте Шенандоа GC. |
-XmxXg | Установить размер кучи. |
-XX:ShenandoahGCHeuristics= | Выберите эвристику. |
Эвристика Шенандоа
Вы можете настроить Shenandoah с одной из трех эвристик. Они определяют, когда GC начинает свои циклы и как он выбирает регионы для эвакуации.
1. Адаптивный : наблюдает за циклами GC и запускает следующий цикл, чтобы он завершился до того, как приложение исчерпает кучу. Эта эвристика является режимом по умолчанию.
2. Статический . Запускает цикл сборки мусора в зависимости от занятости кучи и давления на выделение.
3. Компактный : Непрерывно запускает циклы ГХ. Shenandoah начинает новый цикл, как только заканчивается предыдущий или на основе объема кучи, выделенной с момента последнего цикла. Эта эвристика влечет за собой накладные расходы на пропускную способность, но обеспечивает наилучшее высвобождение пространства.
Режимы отказа
Shenandoah должен собирать кучу быстрее, чем приложение, которое он обслуживает, выделяет его. Если давление выделения слишком велико и для новых выделений недостаточно места, произойдет сбой. У Shenandoah есть настраиваемые механизмы для этой ситуации.
- Шаг : если Shenandoah начинает отставать от скорости выделения, потоки выделения останавливаются, чтобы наверстать упущенное. Прилавков обычно достаточно для умеренных всплесков распределения. Shenandoah вводит задержки в 10 мс или меньше. Если стимуляция не удалась, Шенандоа перейдет к следующему этапу: вырожденному GC.
- Вырожденный GC : если происходит сбой распределения, Shenandoah запускает фазу остановки мира. Он использует фазу для завершения текущего цикла GC. Поскольку остановивший мир не соперничает с заявкой на ресурсы, цикл должен завершиться быстро и устранить дефицит распределения. Часто вырожденный цикл происходит после того, как большая часть работы цикла уже завершена, поэтому остановка мира непродолжительна. Однако журнал GC сообщит об этом как о полной паузе.
- Полный GC : если и стимуляция, и вырожденный GC терпят неудачу, Шенандоа возвращается к полному циклу GC. Этот окончательный сборщик мусора гарантирует, что приложение не завершится с ошибкой нехватки памяти, если не останется кучи.
Зачем использовать Шенандоа?
Shenandoah предлагает те же преимущества, что и ZGC, с большими кучами, но с более широкими возможностями настройки. В зависимости от характера вашего приложения могут подойти различные эвристики. Время паузы может быть не таким коротким, как у ZGC, но оно более предсказуемо.
Хотя Shenandoah не был доступен как часть Java до версии 12, он существует дольше, чем ZGC. Он прошел больше тестов и даже доступен в качестве резервной копии для Java 8 и 10.
Заключение
Сборщик мусора Java прошел долгий путь за несколько коротких лет. Сборщик по умолчанию G1 претерпел значительные улучшения по сравнению с Java 7, и на платформу были добавлены три новых.
В зависимости от ваших потребностей, один из этих новых GC может быть тем, что вам нужно, чтобы вывести производительность вашего Java-приложения на новый уровень.