Обзор

В этой статье представлены основные принципы и теории GC, идеи и методы методов настройки GC, основанные на Hotspot jdk1.8, после обучения вы узнаете, как устранять неполадки и решать проблемы GC в производственной системе.

Время чтения составляет около 30 минут, а основное содержание выглядит следующим образом:

• Основные принципы GC, включая цели настройки, классификацию событий GC, стратегию распределения памяти JVM, анализ журнала GC и т. д.
• Принцип и настройка CMS
• Принцип G1 и настройка
• Устранение неполадок GC и идеи решения

Основы GC

1 Цели настройки GC

В большинстве случаев настройка сборщика мусора для Java-программ в основном направлена ​​на достижение двух целей: скорость отклика, пропускная способность.

• Ответная реакцияСкорость отклика означает, насколько быстро программа или система отвечает на запрос. Например, время отклика на запрос пользователя, система, требующая высокой скорости отклика, недопустимо большое время паузы. Суть настройки заключается в быстром реагировании в течение короткого промежутка времени.

• пропускная способностьПропускная способность фокусируется на максимальной рабочей нагрузке прикладной системы в определенный период времени, например, на количестве задач, которые могут быть выполнены пакетной системой в час. высокой пропускной способности.Массовые приложения больше заботятся о том, чтобы выполнить всю задачу как можно быстрее, не принимая во внимание быструю реакцию на запросы пользователей

При настройке сборщика мусора время паузы приложения, вызванное сборщиком мусора, влияет на скорость отклика системы, а использование ЦП потоком обработки сборщика мусора влияет на пропускную способность системы.

2 Алгоритм сбора поколений GC

Современные сборщики мусора в основном используют алгоритмы сборки поколений.Основные идеи: Память кучи Java логически разделена на две части: новое поколение и старое поколение, и для объектов с разным жизненным циклом и разным размером применяются разные стратегии сборки мусора.

• Молодое поколение

Новое поколение также называют молодым поколением.Большинство объектов создается в новом поколении, и многие объекты имеют очень короткий жизненный цикл. После каждой сборки мусора нового поколения (также известной как Young GC, Minor GC, YGC) выживает лишь небольшое количество объектов, поэтому, используя алгоритм копирования, сборку можно завершить с небольшой стоимостью операции копирования.

Новое поколение разделено на три области: одна область Эдема, две области Выживших (S0, S1, также известные как From Survivor, To Survivor), большинство объектов генерируется в области Эдема. Когда область Эдема заполнена, выжившие объекты будут скопированы в (одну из) двух областей Выживших. Когда эта область Выжившего заполнится, объекты, уцелевшие в этой области и не соответствующие условиям повышения до старости, будут скопированы в другую область Выжившего. Каждый раз, когда объект подвергается репликации, возраст увеличивается на 1, а после достижения порога возраста продвижения он переводится в старость.

• Старое поколение

Объекты, пережившие N сборок мусора в молодом поколении, будут помещены в старое поколение, а выживаемость объектов в этой области высока. Сборка мусора для пожилых людей обычно использует алгоритм «пометки и сортировки».

3 Классификация событий GC

Сборка мусора обычно делится на Young GC, Old GC, Full GC, Mixed GC в соответствии с различными областями сборки мусора.

(1) Young GC

Событие сборки мусора памяти молодого поколения называется Young GC (также известное как Minor GC).Когда JVM не может выделить новые объекты в пространстве памяти молодого поколения, Young GC всегда запускается, например, когда область Eden заполнена. Чем выше частота выделения новых объектов, тем выше частота Young GC

Молодой GC каждый раз будет вызывать Stop-The-World, приостанавливая все потоки приложения, а время паузы почти ничтожно по сравнению с паузой, вызванной старым GC.

(2) Старый GC, полный GC, смешанный GC

Old GC, только очистить GC события старого пространства, только параллельный сбор CMS это режимFull GC, очистить события GC всей кучи, включая новое поколение, старое поколение, метапространство и т. д.

• Mixed GC,очистить ГК всего нового поколения и некоторых старых поколений,только у Г1 есть этот режим

4 Анализ журнала сборщика мусора

Журнал сборщика мусора — очень важный инструмент. Он точно фиксирует время выполнения и результат выполнения каждого сборщика мусора. Анализируя журнал сборщика мусора, вы можете настроить параметры кучи и параметры сборщика мусора или улучшить режим выделения объектов приложения и запустить его. JVM, параметры следующие:

-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps  -XX:+PrintGCTimeStamps

Журналы Common Young GC и Full GC имеют следующие значения:

Бесплатный инструмент анализа графика журнала GC рекомендует следующие два:

• GCViewer, загрузите пакет jar и запустите его напрямую
• gceasy, веб-инструмент, загрузка журнала GC для использования в Интернете

5 Стратегия распределения памяти

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

• Предметы предпочтительно размещаются в районе ЭдемаВ большинстве случаев объекты размещаются в области Эдема первого поколения. Когда в области Eden недостаточно места для выделения, виртуальная машина инициирует Young GC.

• Крупные предметы уходят прямо в старостьJVM предоставляет пороговый параметр размера объекта (-XX:PretenureSizeThreshold, значение по умолчанию равно 0, что означает, что независимо от того, насколько он велик, память сначала выделяется в Eden). непосредственно выделяется в старости, что позволяет избежать объектов Большая копия памяти происходит непосредственно в Эдеме и двух выживших

• Долгоживущие объекты войдут в старостьКаждый раз, когда объект подвергается сборке мусора и не собирается, его возраст увеличивается на 1. Объекты, размер которых превышает параметр порога возраста (-XX:MaxTenuringThreshold, по умолчанию 15), будут переведены в старость.

• гарантия распределения местаПеред выполнением Young GC JVM должна оценить: может ли старое поколение разместить уцелевшие объекты, переведенные из нового поколения в старое поколение после Young GC, чтобы определить, необходимо ли заранее инициировать GC, чтобы вернуть пространство старого поколения, и рассчитывать на основе стратегии гарантированного распределения пространства:

continueSize: максимально доступное непрерывное пространство в старом поколении.

Если Young GC проходит успешно (объект, продвинутый после Young GC, может быть помещен в старую возрастную категорию), это означает, что гарантия успешна, и нет необходимости выполнять Full GC для повышения производительности; Full GC

• Динамическое определение возрастаВозраст объекта молодого поколения может не достигать порогового значения (заданного параметром MaxTenuringThreshold), прежде чем он будет переведен в старое поколение.Все предметы одного возраста имеют размерСумма больше половины любого пространства Survivor (общее пространство S0 или S1).В это время площадь S0 или S1 не сможет вместить уцелевшие кайнозойские объекты.Объекты, возраст которых больше или равен этому возрасту, могут напрямую ввести старость, не дожидаясь MaxTenuringThreshold.

Кроме того, если площади S0 или S1 после Young GC недостаточно для размещения: выжившие объекты молодого поколения, не соответствующие условиям продвижения в старое поколение, приведут к тому, что эти выжившие объекты попадут непосредственно в старое поколение, что должно быть по возможности избегал.

Принцип и настройка CMS

1 Объяснение терминов

Алгоритмы анализа достижимости: используется для определения того, является ли объект живым, основная идея состоит в том, чтобы использовать серию объектов, называемых «GC Root», в качестве отправной точки (общие корни GC включают загрузчик системных классов, объекты в стеке, потоки в активном состоянии и т. д. ), основанный на объекте Эталонное отношение начинается с корней GC и ведет поиск вниз, а пройденный путь называется цепочкой ссылок Когда объект не связан с корнем GC какой-либо цепочкой ссылок, это доказывает, что объект не дольше жив.

Stop The World: связь ссылок на объекты анализируется во время процесса GC. Чтобы обеспечить точность результатов анализа, необходимо приостановить все потоки выполнения Java, чтобы гарантировать, что отношения ссылок больше не изменяются динамически. Это событие паузы называется Stop The Мир (STW)

Safepoint: Некоторые специальные позиции в процессе выполнения кода.Выполнение потока до этих позиций означает, что текущее состояние виртуальной машины безопасно.Если есть необходимость в сборке мусора, поток можно приостановить на этой позиции. HotSpot использует метод активного прерывания, чтобы позволить потоку выполнения опросить флаг о том, нужно ли его приостановить во время выполнения, и при необходимости прервать приостановку.

2 Введение в CMS

CMS (Concurrent Mark and Sweep concurrency-mark-sweep) — это алгоритм сборки мусора, основанный на параллелизме и использующий алгоритм mark-sweep, который выполняет сборку мусора только для старых. Когда сборщик CMS работает, позвольте потоку GC и пользовательскому потоку выполняться одновременно, насколько это возможно, чтобы сократить время STW.

Включите сборщик мусора CMS со следующими параметрами командной строки:

-XX:+UseConcMarkSweepGC

Стоит добавить, что описанный ниже сборщик мусора CMS относится к сборщику мусора старого поколения, тогда как полный сборщик мусора относится к событиям сборщика мусора всей кучи, включая новое поколение, старое поколение, метапространство и т. д., а два разные.

3 Сборка мусора нового поколения

Сборщики мусора нового поколения, которые можно использовать с CMS, — это сборщик Serial и сборщик ParNew. Эти два коллектора используют алгоритм репликации тегов, который инициирует события STW и останавливает все потоки приложения. Разница в том, что Serial — однопоточное исполнение, ParNew — многопоточное.

4 Сборка мусора старого поколения

Цель CMS GC – получить минимальное время паузы и максимально сократить время STW, которое можно разделить на 7 этапов.

• Этап 1: Начальная оценка

Цель этого этапа — пометить все уцелевшие объекты в старом поколении, включая прямые ссылки на корень GC, и объекты, на которые ссылаются уцелевшие объекты в молодом поколении, инициировав первое событие STW.

Этот процесс поддерживает многопоточность (один поток до JDK7, параллельный после JDK8, что можно настроить с помощью параметра CMSPallelInitialMarkEnabled)

• Фаза 2: одновременная отметка

На этом этапе поток GC и поток приложения выполняются одновременно, обходят уцелевшие объекты, изначально отмеченные на этапе 1, а затем продолжают рекурсивно отмечать объекты, достижимые этими объектами.

• Фаза 3: Параллельная предварительная очистка

На этом этапе поток GC и поток приложения также выполняются одновременно, поскольку фаза 2 выполняется одновременно с потоком приложения, и некоторые отношения ссылок могли измениться. С помощью маркировки карты старое возрастное пространство заранее логически делится на равные по размеру области (карта). будут найдены грязные области, эталонное отношение будет обновлено, а флаг «грязная область» будет очищен.

• Фаза 4: Параллельная прерываемая предварительная очистка

Эта фаза также не останавливает поток приложения. Эта фаза пытается выполнить как можно больше работы перед фазой Final Remark STW, чтобы сократить время паузы приложения. На этом этапе обработка цикла: помечать достижимые объекты в старом поколении, сканировать и обрабатывать объекты в области Dirty Card, а условия завершения цикла таковы: 1 достигнуто количество циклов 2 Достигнут порог времени выполнения цикла 3 Использование памяти нового поколения достигает порога

• Этап 5: Заключительное замечание

Это вторая (и последняя) фаза STW в событии GC, и цель состоит в том, чтобы завершить маркировку всех живых объектов в старом поколении. Выполнить на этом этапе: 1 Пройдитесь по объектам нового поколения и перемаркируйте 2 Замечание по GC Roots 3 Пройдитесь по старым грязным картам и перемаркируйте их.

• Фаза 6: Параллельная проверка

Эта фаза выполняется одновременно с приложением и не требует приостановки STW, а объекты мусора очищаются в соответствии с результатом маркировки.

• Фаза 7: Параллельный сброс

Эта фаза выполняется одновременно с приложением, сбрасывает внутренние данные, связанные с алгоритмом CMS, и готовится к следующему циклу GC.

5 Часто задаваемые вопросы по CMS

Долгая пауза в заключительной фазе маркировки

Около 80% времени паузы GC CMS приходится на финальную стадию маркировки (Заключительное замечание).Если время паузы на этой стадии слишком велико, то распространенной причиной является неверная ссылка нового поколения на старое поколение. предыдущий этап, параллельный этап может отменить этап предварительной очистки. , цикл не завершается в течение порогового времени выполнения, и уже слишком поздно запускать Young GC для очистки этих недопустимых ссылок.

Добавив параметр: -XX:+CMSScavengeBeforeRemark. Запуск Young GC перед финальной операцией, тем самым уменьшая недействительные ссылки на старое поколение со стороны молодого поколения, уменьшая паузу в завершающей фазе маркировки, но если Young GC сработал на предыдущей фазе (одновременная отменяемая предварительная очистка), это также повторит Trigger Young GC

Сбой параллельного режима и проблема с продвижением

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

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

Сбой параллельного режима и сбой продвижения приведут к длительным паузам. Общие решения следующие:

• Уменьшите порог срабатывания CMS GC, то есть значение параметра -XX:CMSInitiatingOccupancyFraction, чтобы CMS GC выполнялся как можно быстрее, чтобы обеспечить достаточно места
• Увеличьте количество потоков CMS, то есть параметр -XX:ConcGCThreads,
• Увеличить пространство старости
• Пусть объект максимально перерабатывается в новом поколении, чтобы не попасть в старое поколение

проблема с фрагментацией памяти

Обычно процесс GC CMS основан на алгоритме маркировки-очистки без сжатия, что приводит к увеличению количества фрагментов памяти, которые необходимо сжать.Обычно следующие сценарии вызывают сжатие фрагментов памяти:

• Новое поколение Young GC имеет сбой гарантии продвижения нового поколения (продвижение не удалось)
• Программа активно выполняет System.gc()

Вы можете установить, сколько раз полный сборщик мусора запускает уплотнение с помощью значения параметра CMSFullGCsBeforeCompaction. Значение по умолчанию равно 0, что означает, что уплотнение будет запускаться каждый раз, когда вы входите в полный сборщик мусора. Алгоритм действия уплотнения — однопоточный последовательный Старый алгоритм, упомянутый выше.Время паузы (STW) очень велико и необходимо максимально сократить время сжатия.

Принцип G1 и настройка

1 Введение в G1

G1 (Garbage-First) — серверно-ориентированный сборщик мусора, который поддерживает сборку мусора в пространствах нового и старого поколений.В основном он предназначен для машин, оснащенных многоядерными процессорами и памятью большого объема.Основные цели разработки G1 являются:Обеспечивает предсказуемое и настраиваемое время паузы STW.

2 разделения пространства кучи G1

• Region

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

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

• гигантский объект

Когда размер объекта превышает половину Региона, он считается Огромным Объектом и напрямую относится к Огромным регионам старого поколения.Эти Огромные регионы представляют собой непрерывный набор регионов, и каждый Регион имеет не более одного Гигантские объекты, гигантские объекты могут занимать несколько регионов.

Значение G1, разделяющего память кучи на регионы, заключается в следующем:

• Каждый GC не должен иметь дело со всем пространством кучи, а каждый раз обрабатывается только часть Region для реализации GC памяти большой емкости.
• Рассчитав стоимость переработки для каждого региона, включая время, необходимое для переработки, и место, пригодное для переработки,Восстановите как можно больше памяти за ограниченное время, время паузы, вызванное сборкой мусора, контролируется в пределах ожидаемого диапазона времени конфигурации, который также является источником имени G1:garbage-first

3 G1 рабочий режим

Для нового поколения и старого поколения G1 предоставляет два режима GC, Young GC и Mixed GC, оба из которых ведут к Stop The World.

• Молодой ГК Когда места нового поколения недостаточно, G1 запускает Young GC, чтобы вернуть пространство нового поколения. Молодой GC в основном выполняет GC на области Эдема.Он срабатывает, когда пространство Эдема исчерпано.Основываясь на идее алгоритма повторного использования и репликации поколений, каждый Молодой GC выберет все регионы нового поколения и рассчитает необходимое количество следующего Young GC одновременно Пространство в области Eden и Survivor, динамически регулируйте количество регионов, занятых новым поколением, чтобы контролировать накладные расходы Young GC

• Смешанный GC Когда пространство старого поколения достигает порогового значения, запускается Mixed GC, выбираются все регионы в новом поколении, и в соответствии с фазой глобальной параллельной маркировки (описанной ниже) получаются несколько регионов старого поколения с высоким доходом от сбора. В пределах заданного пользователем диапазона затрат максимально выделяйте регионы старого поколения с высоким доходом для GC, а также контролируйте стоимость Mixed GC, выбирая, какие старые регионы и сколько регионов выбрать.

4 Глобальный маркер параллелизма

глобальный флаг параллелизмаВ основном для определения области региона с более высоким доходом от добычи для расчета смешанного GC, который разделен на 5 этапов.

• Этап 1: Начальная оценкаПриостановите все потоки приложения (STW) и одновременно пометьте объекты (собственные объекты стека, глобальные объекты, объекты JNI), которые напрямую доступны из корня GC.При достижении условия триггера G1 не будет немедленно инициировать параллельный цикл маркировки, но Он заключается в ожидании следующей коллекции нового поколения и использовании периода времени STW коллекции нового поколения для завершения начальной маркировки.Этот метод называется Piggybacking.

• Фаза 2: сканирование корневой областиПосле того, как начальная пауза пометки заканчивается, новое поколение собирает и завершает работу по копированию объектов в Survivor, и поток приложения становится активным; В это время, чтобы обеспечить корректность алгоритма маркировки, всем объектам, вновь скопированным в раздел Survivor, необходимо выяснить, какие объекты имеют ссылки на объекты в старости, и пометить эти объекты как корни; Этот процесс называется сканированием корневого региона, а сканируемый раздел Suvivor также называется корневым регионом; Сканирование корневого раздела должно быть завершено до начала следующей сборки мусора нового поколения (следующий параллельный процесс маркировки может быть прерван несколькими сборками мусора нового поколения), поскольку каждый сборщик мусора будет генерировать новый набор живых объектов.

• Фаза 3: параллельная маркировкаПоток маркировки выполняется параллельно с потоком приложения, помечая уцелевшую информацию об объекте Region в каждой куче, этот шаг может быть прерван новым GC Young. Все задачи маркировки должны быть просканированы до того, как куча будет заполнена.Если параллельная маркировка занимает много времени, возможно, что в процессе параллельной маркировки было испытано несколько коллекций нового поколения.

• Этап 4: ЗамечаниеКак и в CMS, все потоки приложений (STW) приостанавливаются для завершения процесса маркировки.Кратковременно останавливайте потоки приложений, помечайте объекты, которые были изменены на этапе параллельной маркировки, и все непомеченные активные объекты, а также завершайте расчет оперативных данных одновременно. время

• Этап 5: ОчисткаПодготовьтесь к предстоящему этапу переноса, который также выполняет все необходимые чистовые расчеты для следующей разметки:

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

5 Примечания по настройке G1

Полная проблема GC

В обычном потоке обработки G1 нет полной сборки мусора.Это происходит только тогда, когда сборка мусора не может быть обработана (или активно запущена).Полная сборка мусора G1 — это серийная старая сборка мусора, выполняемая одним потоком, очень долгий STW, который представляет собой процесс настройки. Главное — максимально избегать полного GC. Общие причины следующие:

• Программа активно выполняет System.gc()
• Пространство старого поколения заполнено во время глобальной параллельной маркировки (сбой параллельного режима)
• Пространство старого поколения заполнено во время Mixed GC (продвижение не удалось)
• Пространство выжившего и старость не имеют достаточно места для выживших объектов во время Young GC

Как и в случае с CMS, распространенными решениями являются:

• Увеличение параметра -XX:ConcGCThreads=n увеличивает количество параллельных потоков маркировки или количество параллельных потоков во время STW: -XX:ParallelGCThreads=n
• Уменьшите -XX:InitiatingHeapOccupancyPercent, чтобы начать цикл маркировки раньше.
• Увеличьте зарезервированную память -XX:G1ReservePercent=n , значение по умолчанию равно 10, что означает, что 10% памяти кучи используется в качестве зарезервированной памяти. использовать зарезервированную память

размещение больших объектов

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

Не задавайте размер области Юнга

Причина в том, что для максимального соблюдения целевого времени паузы логическая область Юнга будет динамически корректироваться. Если установлен размер, он будет переопределен, и управление временем паузы будет отключено.

Настройки среднего времени отклика

Используйте среднее время отклика приложения в качестве эталона для установки MaxGCPauseMillis. JVM попытается выполнить это условие. Может случиться так, что 90% запросов или больше времени отклика находятся в пределах этого времени, но это не означает, что все запросы могут В среднем слишком маленькое время отклика приведет к частому сбору мусора.

Методы и идеи тюнинга

Как проанализировать состояние работы JVM GC в системе и правильно его оптимизировать?

Основная идея оптимизации GC заключается в следующем:Насколько это возможно, позвольте объектам выделяться и перерабатываться в новом поколении, старайтесь избегать слишком большого количества объектов, попадающих в старое поколение, что приводит к частой сборке мусора старого поколения, и в то же время дайте системе достаточно памяти, чтобы уменьшить количество сборок мусора в новом поколении, вокруг этой идеи также проводится системный анализ и оптимизация

1 Анализ состояния системы

• Количество запросов в секунду в системе, сколько объектов создается за один запрос и сколько занято памяти
• Частота запуска Young GC, скорость, с которой объекты достигают старости.
• Память, занимаемая старым поколением, частота срабатывания Full GC, причины срабатывания Full GC, причины длительного срабатывания Full GC

Общие инструменты следующие:

• jstatJVM поставляется с инструментами командной строки, которые можно использовать для подсчета скорости выделения памяти, времени сборки мусора, затрат времени на сборку мусора, общих форматов команд.

jstat -gc <pid> <统计间隔时间>  <统计次数>

Значение выходного возвращаемого значения следующее:

Например: jstat -gc 32683 1000 10 , считать процессы с pid=32683, считать 1 раз в секунду и считать 10 раз

• jmapJVM поставляется с инструментом командной строки, который можно использовать для понимания распределения объектов во время работы системы.Общий формат команды выглядит следующим образом.

// 命令行输出类名、类数量数量，类占用内存大小，
// 按照类占用内存大小降序排列
jmap -histo <pid>

// 生成堆内存转储快照，在当前目录下导出dump.hrpof的二进制文件，
// 可以用eclipse的MAT图形化工具分析
jmap -dump:live,format=b,file=dump.hprof <pid>

• jinfoформат команды

jinfo <pid> 

Расширенные аргументы для просмотра запущенных приложений Java, включая свойства системы Java и аргументы командной строки JVM.

Другие инструменты ГХ

• Мониторинг охранной сигнализации: Zabbix, Prometheus, Open-Falcon
• инструмент автоматического мониторинга памяти jdk в реальном времени: VisualVM
• Мониторинг памяти вне кучи: Java VisualVM устанавливает плагин Buffer Pools, инструмент Google perf, инструмент Java NMT (Native Memory Tracking)
• Анализ журнала сборщика мусора: GCViewer, gceasy
• Проверка и оптимизация параметров ГХ:xxfox.perfma.com/

2 Случай оптимизации сборщика мусора

• Система платформы анализа данных часто Полный GC

Платформа в основном проводит регулярный анализ и статистику поведения пользователя в приложении и поддерживает экспорт отчетов с использованием алгоритма CMS GC. За время использования аналитик данных обнаружил, что системная страница часто зависала при открытии.С помощью команды jstat было установлено, что около 10% выживших объектов уходили в старость после каждого Young GC.

Получается, что из-за того, что пространство в области Survivor задано слишком маленьким, уцелевшие объекты нельзя размещать в области Survivor после каждого GC Young, поэтому он входит в старость заранее.Увеличивая область Survivor, область Survivor может разместить уцелевшие объекты после Young GC. Несколько раз Young GC достигает порога возраста перед входом в старость. После корректировки уцелевшие объекты, вступающие в старость после каждого Young GC, стабильно работают всего несколько сотен Кб, а частота полного GC значительно снижена.

• Стыковочный шлюз для бизнеса OOM

Шлюз в основном потребляет данные Kafka, выполняет обработку и расчет данных, а затем перенаправляет их в другую очередь Kafka.OOM возникает, когда система работает в течение нескольких часов, а OOM возникает после перезапуска системы в течение нескольких часов.Куча памяти экспортируется через jmap, и причина находится после анализа инструментом eclipse MAT. : В коде данные темы определенного бизнеса Kafka печатаются асинхронно в журнале. Объем бизнес-данных большой, и большое количество объекты накапливаются в памяти, ожидая печати, что приводит к OOM

• Система управления правами учетных записей часто является полным GC в течение длительного времени.

Система предоставляет различные услуги аутентификации учетной записи для внешнего мира.При ее использовании обнаруживается, что система часто недоступна.С помощью платформы мониторинга Zabbix обнаруживается, что в системе часто происходит полное GC в течение длительного времени, и куча памяти старого поколения обычно не заполняется при ее срабатывании System.gc() вызывается в бизнес-коде

Суммировать

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

Из-за нехватки места я больше не буду вводить использование общих параметров GC, я опубликую это на github:GitHub.com/Это ты/Это...

Ссылаться на

Производительность Java: полное руководство Скотта Оукса

«Понимание виртуальной машины Java: расширенные функции и лучшие практики JVM (второе издание», Чжихуа Чжоу)

Практика настройки производительности Java

Getting Started with the G1 Garbage Collector

Справочное руководство по ГХ — версия для Java

Спросите принцип алгоритма G1 - ответ RednaxelaFX

Некоторые ключевые технологии Java Hotspot G1 GC - Техническая команда Meituan