Анализ и решения 9 распространенных проблем CMS GC в Java (часть 2)

Java JVM
Анализ и решения 9 распространенных проблем CMS GC в Java (часть 2)

1. ОТ РЕДАКЦИИ

| Эта статья кратко для ВМ Hotspot в "CMS + ParNew" Некоторые используют комбинацию сцен. Ключевая часть по источнику первопричины, анализ и обобщение методов расследования, процесс расследования будет в большей степени опущен, другие более специализированные термины, используемые здесь, имеют определенный порог чтения, если они не описаны четко, пожалуйста, обратитесь к соответствующему материалу самостоятельно .

| Общее количество слов около 20 000 (исключая фрагменты кода), а общее время чтения около 30 минут.Статья длинная, и вы можете выбрать интересующую вас сцену для исследования.

Анализ и решения 9 распространенных проблем CMS GC в Java (часть 1)

4.7 Сценарий 7: Фрагментация памяти и дегенерация коллектора

4.7.1 Феномен

Параллельный алгоритм CMS GC вырождается в однопоточный последовательный режим Foreground GC, а время STW очень велико, иногда до десяти секунд. Среди них есть два вида однопоточных последовательных алгоритмов GC после вырождения сборщика CMS:

  • Алгоритм с действием сжатия называется MSC.Как мы представили выше, он использует метод пометки-очистки-сжатия, однопоточный метод полной паузы для выполнения сборки мусора во всей куче, что является полным GC в истинном смысле, и время паузы больше, чем у обычных CMS.
  • Алгоритм без действия сжатия собирает область Old, что аналогично обычному алгоритму CMS, а время паузы меньше, чем у алгоритма MSC.

4.7.2 Причины

Деградация сборщика CMS происходит в основном в следующих ситуациях:

Ошибка продвижения

Как следует из названия, сбой продвижения означает, что при выполнении Молодого ГК Выживший не может положить объект, а объект может быть помещен только в Старый, но в это время Старый также нельзя положить. Интуитивно, на первый взгляд, такая ситуация может возникать часто, но на самом деле из-за существования concurrentMarkSweepThread и гарантийного механизма условия возникновения очень жесткие, если только оставшееся место в области Old не будет быстро заполнено за короткий период например, как упоминалось выше, преждевременное продвижение по службе из-за динамического определения возраста (см. «Отказ от гарантии инкрементного сбора» ниже). Другая ситуация — Ошибка продвижения, вызванная фрагментацией памяти. Молодой сборщик мусора считает, что в старом достаточно места. В результате при выделении продвигаемые большие объекты не могут найти непрерывное пространство для хранения.

Когда CMS используется в качестве сборщика мусора, старая область, которая работала в течение определенного периода времени, показана на рисунке ниже Алгоритм очистки приводит к прерывистым множественным сегментам памяти и большому количеству фрагментов памяти.

Фрагментация представляет две проблемы:

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

Гарантия инкрементного сбора не удалась

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

Явный GC

В этом случае см. Сценарий 2.

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

Последний случай также имеет более высокую вероятность возникновения.Ключевое слово Concurrent Mode Failure часто встречается в журнале GC. Это связано с тем, что выполняется параллельный фоновый GC CMS, а объекты, продвигаемые молодым GC, помещаются в старую область, а места в старой области в настоящее время недостаточно.

Почему CMS GC выполняется и приводит к ухудшению работы сборщика? В основном из-за неспособности CMS обрабатывать плавающий мусор. Во время параллельной фазы очистки CMS Мутатор все еще работает, поэтому постоянно генерируется новый мусор, и этот мусор не попадает в область действия этой отметки очистки и не может быть удален в этом GC.Это плавающий мусор. отключенные от барьера чтения-записи до Remark, также считаются плавающим мусором. Поэтому порог перезапуска старой области не может быть слишком высоким, иначе зарезервированного места в памяти, вероятно, будет недостаточно, что приведет к сбою параллельного режима.

4.7.3 Стратегия

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

  • Фрагментация памяти:по конфигурации-XX:UseCMSCompactAtFullCollection=trueЧтобы контролировать, организовано ли пространство во время процесса полного GC (включено по умолчанию, обратите внимание, что это полный GC, а не обычный CMS GC) и-XX: CMSFullGCsBeforeCompaction=nчтобы контролировать, сколько полных GC следует за уплотнением.

  • Инкрементальная коллекция:Понизьте порог, который запускает CMS GC, параметр-XX:CMSInitiatingOccupancyFractionЗначение , позволяющее CMS GC выполняться как можно скорее, чтобы обеспечить достаточное непрерывное пространство, а также уменьшить размер использования старого пространства области и необходимость использования-XX:+UseCMSInitiatingOccupancyOnlyВ противном случае JVM будет использовать значение параметра только в первый раз, а затем автоматически скорректирует его позже.

  • Плавающий мусор:Контролируйте размер каждого рекламного объекта в зависимости от ситуации или сократите время каждой CMS GC и при необходимости отрегулируйте значение NewRatio. Кроме того, используйте-XX:+CMSScavengeBeforeRemarkЗаранее активируйте Young GC, чтобы не допустить последующего повышения слишком большого количества объектов.

4.7.4 Резюме

В нормальных условиях CMS GC, который запускает параллельный режим, имеет очень короткую паузу и мало влияет на бизнес.Однако после того, как CMS GC ухудшится, влияние будет очень большим.Рекомендуется полностью вылечить его, как только он выйдет из строя. обнаруживается. Пока можно обнаружить конкретные причины фрагментации памяти, плавающего мусора и инкрементной сборки, решить ее относительно легко.-XX:CMSFullGCsBeforeCompactionЕсли значение нелегко выбрать, вы можете использовать-XX:PrintFLSStatisticsЧтобы наблюдать скорость фрагментации памяти, а затем установить конкретное значение.

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

4.8 Сценарий 8: OOM памяти вне кучи

4.8.1 Феномен

Использование памяти продолжает расти и даже начинает использовать память подкачки, в то же время может резко возрасти время сборки мусора, потоки заблокированы и т. д.Команда top обнаружила, что RES процесса Java даже превышает-Xmxразмер. Когда происходят эти явления, почти наверняка происходит утечка памяти вне кучи.

4.8.2 Причины

Есть две основные причины утечек памяти JVM вне кучи:

  • пройти черезUnSafe#allocateMemory,ByteBuffer#allocateDirectАктивно применяется для памяти вне кучи, не освобождая ее, что характерно для связанных компонентов, таких как NIO и Netty.
  • В коде память, запрошенная вызовом Native Code через JNI, не освобождается.

4.8.3 Политика

Что вызывает утечку памяти вне кучи?

Во-первых, нам нужно определить, что вызывает утечку памяти вне кучи. Здесь вы можете использовать NMT (NativeMemoryTracking) для анализа. добавить в проект-XX:NativeMemoryTracking=detailПерезапустите проект после параметров JVM (следует отметить, что открытие NMT приведет к потере примерно 5%~10% производительности). использовать командуjcmd pid VM.native_memory detailПосмотреть распределение памяти. Сосредоточьтесь на общем количестве зафиксированных данных, поскольку память, отображаемая командой jcmd, включает в себя память в куче, область кода иUnsafe.allocateMemoryиDirectByteBufferЗапрошенная память, но не включает память вне кучи, запрошенную другим собственным кодом (код C).

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

Причина 1: Активное приложение не выпущено

Использование JVM-XX:MaxDirectMemorySize=sizeпараметр для управления максимальным объемом памяти вне кучи, который может быть применен. В Java8, если этот параметр не настроен, значения по умолчанию и-Xmxравный.

И НИО, и Нетти возьмут-XX:MaxDirectMemorySizeНастроенное значение для ограничения размера запрошенной памяти вне кучи. В NIO и Netty также есть поле счетчика, которое используется для расчета размера используемой в данный момент памяти вне кучи.java.nio.Bits#totalCapacity, в Неттиio.netty.util.internal.PlatformDependent#DIRECT_MEMORY_COUNTER.

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

В НИО есть:OutOfMemoryError: Direct buffer memory.

В Нетти есть:OutOfDirectMemoryError: failed to allocate capacity byte(s) of direct memory (used: usedMemory , max: DIRECT_MEMORY_LIMIT ).

Мы можем проверить, как в коде используется память вне кучи, NIO или Netty, через рефлексию, получить поле счетчика в соответствующем компоненте, и проверить значение поля в проекте, можно точно отслеживать эту часть Off-heap использование памяти.

На этом этапе вы можете использовать отладку, чтобы определить, правильно ли выполняется код, освобождающий память, где используется память вне кучи. Кроме того, нужно проверить, имеют ли параметры JVM-XX:+DisableExplicitGCудалите, если он есть, так как этот параметр делает System.gc недействительным. (Сценарий 2: явный сборщик мусора уходит и остается)

Причина 2: память, запрошенная собственным кодом, вызываемым JNI, не освобождается

Эту ситуацию сложнее устранить. Мы можем использовать такие инструменты, как Google perftools + Btrace, которые помогут нам проанализировать, где находится проблемный код.

gperftools — это очень полезный набор инструментов, разработанный Google, его принцип заключается в использовании его libtcmalloc.so при вызове malloc во время работы Java-приложения, чтобы можно было вести некоторую статистику по распределению памяти. Мы используем gperftools для трассировки команд, выделяющих память. Как показано на рисунке ниже, найдено через gperftoolsJava_java_util_zip_Inflater_initдовольно подозрительно.

Затем вы можете использовать Btrace, чтобы попытаться найти определенный стек вызовов. Btrace — это инструмент отслеживания и мониторинга Java, выпущенный Sun, который может отслеживать онлайн-программы Java без простоев. Как показано на рисунке ниже, найдите проект в проекте через Btrace.ZipHelperчасто звонюGZIPInputStream, который размещает объекты в памяти вне кучи.

Окончательное позиционирование - да, проект правильныйGIPInputStreamИспользование неправильное, нет правильного close().

Помимо причин самого проекта, также могут быть утечки, вызванные внешними зависимостями, такими как Netty и Spring Boot.Подробности можно узнать в этих двух статьях.Устранение неполадок и сводка опыта «Утечка памяти вне кучи», вызванная Spring Boot,Праздник устранения неполадок с утечкой памяти в куче Netty.

4.8.4 Резюме

Во-первых, вы можете использовать NMT + jcmd для анализа того, где применяется утечка памяти вне кучи.После определения причины используйте другие средства для ее обнаружения.

4.9 Сценарий 9: Проблемы с сборщиком мусора, вызванные JNI

4.9.1 Феномен

В журнале GC Причина GC отображается как GCLocker Initiated GC.

2020-09-23T16:49:09.727+0800: 504426.742: [GC (GCLocker Initiated GC) 504426.742: [ParNew (promotion failed): 209716K->6042K(1887488K), 0.0843330 secs] 1449487K->1347626K(3984640K), 0.0848963 secs] [Times: user=0.19 sys=0.00, real=0.09 secs]
2020-09-23T16:49:09.812+0800: 504426.827: [Full GC (GCLocker Initiated GC) 504426.827: [CMS: 1341583K->419699K(2097152K), 1.8482275 secs] 1347626K->419699K(3984640K), [Metaspace: 297780K->297780K(1329152K)], 1.8490564 secs] [Times: user=1.62 sys=0.20, real=1.85 secs]

4.9.2 Причины

JNI (Java Native Interface) означает Java Native Call, который позволяет Java-коду взаимодействовать с Native-кодом, написанным на других языках.

Если JNI нужно получить строку или массив в JVM, есть два способа:

  • доставка копия.
  • Общие ссылки (указатели), более высокая производительность.

Поскольку нативный код напрямую использует указатель области кучи JVM, если в это время произойдет сборка мусора, это вызовет ошибки данных. Следовательно, когда происходит такой вызов JNI, возникновение GC запрещается, и другие потоки не могут войти в критическую секцию JNI до тех пор, пока GC не будет запущен, когда последний поток покинет критическую секцию.

Эксперимент с GC Locker:

public class GCLockerTest {

  static final int ITERS = 100;
  static final int ARR_SIZE =  10000;
  static final int WINDOW = 10000000;

  static native void acquire(int[] arr);
  static native void release(int[] arr);

  static final Object[] window = new Object[WINDOW];

  public static void main(String... args) throws Throwable {
    System.loadLibrary("GCLockerTest");
    int[] arr = new int[ARR_SIZE];

    for (int i = 0; i < ITERS; i++) {
      acquire(arr);
      System.out.println("Acquired");
      try {
        for (int c = 0; c < WINDOW; c++) {
          window[c] = new Object();
        }
      } catch (Throwable t) {
        // omit
      } finally {
        System.out.println("Releasing");
        release(arr);
      }
    }
  }
}

#include <jni.h>
#include "GCLockerTest.h"

static jbyte* sink;

JNIEXPORT void JNICALL Java_GCLockerTest_acquire(JNIEnv* env, jclass klass, jintArray arr) {
sink = (*env)->GetPrimitiveArrayCritical(env, arr, 0);
}

JNIEXPORT void JNICALL Java_GCLockerTest_release(JNIEnv* env, jclass klass, jintArray arr) {
(*env)->ReleasePrimitiveArrayCritical(env, arr, sink, 0);
}

Запустив программу JNI, вы можете увидеть, что все GC, которые происходят, являются GCLocker, инициированными GC, и обратите внимание, что GC не может происходить, когда «Приобретен» и «Выпущен».

Возможными неблагоприятными последствиями GC Locker являются:

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

  • Если в старой области нет места, он будет ждать снятия блокировки, что приведет к блокировке потока.

  • Могут быть инициированы дополнительные ненужные молодые сборщики мусора.В JDK есть ошибка, и есть определенная вероятность того, что молодые сборщики мусора, которые должны запускать сборщик мусора, инициированный GCLocker, только после того, как на самом деле произошел сбор мусора с ошибкой выделения, за которым следует сборщик мусора, инициированный GCLocker. Это связано с тем, что для свойства GCLocker Initiated GC установлено значение full, из-за чего два GC не сходятся.

4.9.3 Стратегия

  • Добавить к-XX+PrintJNIGCStallsпараметр, вы можете распечатать поток, когда происходит вызов JNI, и проанализировать его дальше, чтобы найти вызов JNI, вызвавший проблему.

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

  • Обновите версию JDK до 14, чтобы избежатьJDK-8048556Вызвано повторными GC.

4.9.4 Резюме

Проблемы GC, созданные JNI, трудно устранить, и их нужно использовать с осторожностью.

5. Резюме

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

5.1 Процедура обработки (СОП)

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

  • Разработка стандартов:Это содержание на самом деле очень важно, но большая часть систем отсутствует.Только менее 10% студентов, опрошенных автором в прошлом, могут дать свои собственные системные стандарты ОК., отсутствие предсказуемости, конкретные показатели могут относиться к содержание в 3.1, необходимо установить определенные индикаторы в сочетании со временем TP9999, задержкой и пропускной способностью прикладной системы, а не из-за проблем.

  • Зарезервированный сайт:В настоящее время онлайн-сервисы в основном являются распределенными сервисами.После возникновения проблемы на узле, если позволяют условия, не выполняйте напрямую перезапуск, откат и другие действия для восстановления, а восстанавливайте, сначала удаляя трафик, чтобы мы могли восстановить кучу и stack., журналы GC и другая ключевая информация сохраняются, в противном случае будет упущена возможность локализовать первопричину, а сложность последующих решений значительно возрастет. Конечно, в дополнение к этому, журналы приложений, журналы промежуточного программного обеспечения, журналы ядра и различные метрики также очень полезны для анализа проблем.

  • Причинный анализ:Чтобы судить о причинно-следственной связи между аномалиями GC и другими аномалиями системного индекса, вы можете обратиться к четырем методам причинно-следственного анализа, включая анализ временных рядов, вероятностный анализ, экспериментальный анализ и анализ контрдоказательств, которые автор представил в 3.2, чтобы избежать ошибки в процессе расследования.

  • Анализ причин:После того, как это действительно проблема GC, вы можете использовать инструменты, упомянутые выше, и сопоставить их с девятью распространенными сценариями в разделах с 3 по 5, почему метод анализа первопричины, или напрямую обратиться к диаграмме первопричины ниже. причину проблемы и, наконец, выбрать метод оптимизации.

5.2 Диаграмма первопричины «рыбий скелет»

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

5.3 Предложения по настройке

  • Компромисс:Точно так же, как CAP обречен на отсутствие угла, оптимизация GC требует компромисса между задержкой, пропускной способностью и емкостью.

  • Крайнее средство:Проблемы с GC не обязательно требуют настройки параметров GC для JVM. В большинстве случаев некоторые бизнес-проблемы обнаруживаются в ситуации с GC. Не забывайте настраивать параметры GC, когда вы сталкиваетесь с ними. Конечно, существуют явные сценарии неправильной настройки.

  • Переменные управления:Метод управляющих переменных — это технический метод, используемый для уменьшения дисперсии в методе Монте-Карло.Мы стараемся использовать его при настройке и максимально корректируем только одну переменную в каждом процессе настройки.

  • Воспользуйтесь поиском:Теоретически, 99,99% проблем с GC встречались. Нам нужно изучить передовые методы использования поисковых систем, сосредоточившись на StackOverFlow, проблемах на Github и различных блогах на форумах. Давайте сначала посмотрим, как их решают другие люди. Решайте проблемы с меньшими усилиями . Если вы видите эту статью, значит, ваши поисковые способности успешно прошли проверку~

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

  • Параметры ГХ:Если куча и стек не могут быть сохранены в первый раз, необходимо сохранить журнал GC, чтобы мы могли хотя бы увидеть причину GC и иметь общее руководство по устранению неполадок. Что касается параметров, связанных с журналом GC, самые основные-XX:+HeapDumpOnOutOfMemoryErrorНекоторые параметры больше не будут упоминаться, автор предлагает добавить следующие параметры, которые могут повысить эффективность анализа нашей задачи.

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

    • Активный ГК:Существует также новый способ мониторинга и наблюдения за использованием старой области с помощью методов мониторинга.Когда пороговое значение будет достигнуто, служба приложения будет удалена из трафика, а основной сборщик мусора будет запущен вручную, чтобы уменьшить пауза, вызванная CMS GC, но робастность системы последует.Секс также будет снижен, и вводить его без необходимости не рекомендуется.

    • Чтобы отключить блокировку смещения:Смещенная блокировка очень эффективна, когда блокировку использует только один поток, но в случае интенсивной конкуренции она будет заменена на облегченную блокировку.Устранить блокировку смещения, этот процесс stwиз. Если каждый ресурс синхронизации будет обновляться это обновление, накладные расходы будут очень большими, поэтому он обычно отключен с предпосылкой известного параллелизма.-XX:-UseBiasedLockingдля повышения производительности.

    • Виртуальная память:На ранней стадии запуска некоторые операционные системы (например, Linux) фактически не выделяют физическую память для JVM, а выделяют ее в виртуальной памяти, а при ее использовании выделяют страницы памяти в физической памяти, что также приведет к более длительному время ГК. В этом случае вы можете добавить-XX:+AlwaysPreTouchпозволяет виртуальной машине запускать цикл при выделении памяти, чтобы принудительно зафиксировать запрошенную память и избежать возникновения исключений сбоя страницы во время выполнения. В некоторых сценариях с большим объемом памяти первые несколько раз GC иногда можно сократить на порядок, но после добавления этого параметра процесс запуска может замедлиться.

6. Пишите в конце

Наконец, давайте поговорим о некоторых личных предложениях автора: если вы столкнулись с некоторыми проблемами GC, если у вас есть энергия, вы должны исследовать первопричину и найти самую глубокую причину. Кроме того, в нашу эпоху информационного флуда некоторые опыты, которые "принимаются за эталон", могут быть ошибочными. Попробуйте выработать привычку смотреть исходный код. Есть поговорка, что "нет секрета перед исходный код», что означает, что, если мы не понимаем проблему, мы можем получить представление о ней из исходного кода, и в некоторых сценариях это действительно творит чудеса. Но это не просто чтение исходного кода, чтобы учиться.Если вы копаетесь в исходном коде, но игнорируете теоретическую основу, которая может стоять за ним, легко «собирать семена кунжута и бросать арбузы», «видеть только деревья, но не лес», так что «секретов нет» Это стало пустым разговором, и нам еще предстоит целенаправленно изучить в сочетании с некоторыми реальными бизнес-сценариями.

Где твоё время, где твоё достижение. Автор также начал постепенно углубляться в сторону GC в первые два года, проверять проблему, читать исходники и делать резюме.Каждый случай образует небольшой замкнутый цикл.В настоящее время я изначально нашел некоторые способы иметь дело с проблемами GC и одновременно обобщать свой опыт Применительно к практике производственной среды, медленно формируя благотворный круг.

В этой статье в основном представлен анализ некоторых распространенных сценариев CMS GC.Другие, такие как проблема с CodeCache, приводящая к сбою JIT, длительное время готовности SafePoint и время сканирования таблицы карт, не слишком распространены и не занимают слишком много места для объяснения. Java GC много лет интровертировался под идеей «поколения», прежде чем прорваться к «разделу».В настоящее время Meituan начал использовать G1 для замены CMS, которая использовалась в течение многих лет, хотя G1 немного уступает в плане малой кучи Для CMS, но это тенденция, обновиться до ZGC за короткое время невозможно, поэтому проблемы G1 встречающиеся в будущем могут постепенно увеличиваться. В настоящее время собраны такие проблемы, как «Запомнить набор огрубления», «Огромное распределение», «Эргономическое исключение», «Сбой эвакуации в смешанном GC» и т. д. Кроме того, будут даны некоторые предложения по обновлению CMS до G1. эта часть статьи. Оставайтесь с нами.

"Профилактика пожаров" всегда лучше "тушения пожаров",Не пропустите ни одного аномального маленького индикатора(Вообще любойНегладкие кривыесомнительны), можно избежать возникновения отказа. Как Java-программисты, мы в основном сталкиваемся с некоторыми проблемами GC.Решение проблем GC самостоятельно — это препятствие, которое мы должны преодолеть. Во вступительной главе я также упомянул, что GC — это классическая технология, которую очень стоит изучить.Также часто читают некоторые учебные материалы по GC, такие как «Руководство по сборке мусора» и «Углубленное понимание виртуальной машины Java». и новые, так что поторопитесь и усердно тренируйтесь.Основные навыки GC.

И последнее, но не менее важное: еще одно слово, первое предложение всех статей, связанных с настройкой GC, звучит так: «Не оптимизируйте преждевременно», что отпугивает многих студентов от оптимизации GC. Здесь автор выдвигает другую точку зрения.Закон возрастания энтропии (в изолированной системе, если нет внешней силы для совершения работы, ее общий беспорядок (т.е. энтропия) будет продолжать возрастать) применим и к компьютерным системам ,Если вы не будете активно работать над снижением энтропии, система в конечном итоге выйдет из-под вашего контроля., когда мы достаточно глубоко понимаем бизнес-систему и принципы GC, мы можем уверенно проводить оптимизацию, потому что мы можем в основном предсказать результаты каждой операции, давайте попробуем, мальчик!

читать далее:

Анализ и решения 9 распространенных проблем CMS GC в Java (часть 1)

7. Ссылки

8. Об авторе

  • Xinyu: Присоединился к Meituan в 2015 году в качестве инженера по развитию бизнеса билетов на проживание в магазинах.
  • Сян Мин: присоединился к Meituan в 2018 году в качестве инженера по разработке клиентских платформ.
  • Сянпу: присоединился к Meituan в 2018 году в качестве инженера по разработке клиентских платформ.

9. Информация о наборе

Группа аналитики данных билетов бизнес-групп Meituan в магазинах искренне ищет небольших партнеров для повышения конкурентоспособности бизнеса во всех аспектах, от поставок, контроля, выбора, продаж и т. Д., С обработкой 100 000 уровней запросов в секунду, анализом данных 100 миллионов уровней. , и завершить бизнес с обратной связью.Massive HC, если вы заинтересованы, отправьте электронное письмо по адресуhezhiming@meituan.com, Мы свяжемся с вами как можно скорее.

Чтобы прочитать больше технических статей, подпишитесь на официальный аккаунт Meituantech в WeChat.

Категории