CMS устарела. Следующие шаги? | Кодементор

Популярный алгоритм Concurrent Mark Sweep (CMS) GC устарел в JDK 9. Согласно JEP-291, это решение было принято, чтобы уменьшить нагрузку на обслуживание кодовой базы GC и ускорить новую разработку.

Таким образом, из Java 9, если вы запустите приложение с -XX:+UseConcMarkSweepGC (аргумент, который активирует алгоритм CMS GC), вы увидите ниже ПРЕДУПРЕЖДАЮЩЕЕ сообщение:

Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.

Почему CMS устарела?
Если есть много багажа, который нужно нести, трудно двигаться вперед быстро. Это то, что происходит и в случае с CMS. CMS представляет собой сложный алгоритм с широкими возможностями настройки и, таким образом, наследует множество сложностей кодовой базы GC в JDK. Только если команда разработчиков JDK сможет упростить кодовую базу GC, они смогут ускорить и внедрить инновации на арене GC. В таблице ниже указано количество аргументов JVM, которые можно передать каждому алгоритму GC.

Захват01.PNG

В JVM можно передать около 50 аргументов, связанных с GC, которые являются общими для всех алгоритмов GC. Помимо этих 50 аргументов, только для CMS, вы можете передать 72 дополнительных аргумента. Гораздо большее количество аргументов, чем у любых других алгоритмов GC, как указано в таблице выше. Таким образом, вы можете увидеть сложность кода, требуемую командой JDK для поддержки всех этих аргументов.

Каковы следующие шаги, если вы используете CMS?
Когда я пишу этот блог в феврале 2019 года, я вижу перед собой 3 разных варианта:

Переключиться на алгоритм G1 GC
Переключиться на алгоритм Z GC (ранний доступ в JDK 11, 12)
Продолжить с CMS
Давайте рассмотрим каждый вариант в этом разделе.

(1). Переключиться на алгоритм G1 GC
G1 GC стал алгоритмом GC по умолчанию, начиная с Java 9. Таким образом, вы можете рассмотреть возможность переноса вашего приложения на этот алгоритм. Он может обеспечить лучшие характеристики производительности, чем алгоритм CMS GC. Его намного проще настроить, так как аргументов сравнительно меньше. Кроме того, он предоставляет варианты удалить повторяющиеся строки из памяти. Если вы можете удалить повторяющиеся строки, это может помочь вам сократить общий объем памяти.

(2). Переключиться на алгоритм Z GC
Z ГК является масштабируемым сборщиком мусора с малой задержкой. Его цель — удерживать время паузы GC менее 10 мс. Ранний доступ к алгоритму Z GC доступен в Java 11, 12. Поэтому, если ваше приложение работает на Java 11, 12, вы можете рассмотреть возможность перехода на алгоритм Z GC. Наш предварительный анализ Z GC показывает отличные результаты.

(3). Продолжить с CMS
Мы видели, что для некоторых приложений CMS давала впечатляющие результаты, которые не сравнимы с G1 GC даже после многочисленных настроек. Итак, если вы изучили два других варианта и убедились, что алгоритм CMS — это брак, созданный для вашего приложения на небесах. 😃, вы можете рассмотреть возможность использования самого алгоритма CMS. Есть даже аргументы, продолжающие поддерживать CMS в этом Список рассылки OpenJDK JDK9-dev. По своему личному опыту я вижу, что функции и API, которые устарели в Java 1.1, продолжают существовать даже в Java 12 (даже по прошествии 20 лет). Кажется, что все устаревшие API и функции выживают (и никогда не умирают). Таким образом, продолжение работы на CMS также является вариантом. Конечно, это ваш звонок и звонок заинтересованных сторон вашего приложения.

Вывод
Обратите внимание, что каждое приложение уникально и отличается. Так что не увлекайтесь журналами, литературой, которую вы найдете в Интернете, в которой рассказывается о настройке/настройке сборщика мусора (включая эту статью). Когда вы применяете новые настройки GC, проводите тщательное тестирование, оценивайте характеристики производительности, изучайте эти ключевые показатели эффективности а затем принять осознанное решение.

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *