Процесс MinorGC (алгоритм копирования)

Копировать -> Пусто -> Поменять местами

1. Eden, SurvivorFrom скопировано в SurvivorTo, возраст +1
   • Во-первых, когда область Эдема заполнится, вернитесь к первому сборщику мусора, скопируйте уцелевшие объекты в область SurvivorFrom, а когда область Эдема снова запустит сборщик мусора, он просканирует область Эдема и область From и выполнит сборку мусора на эти две области.
   • Объекты, пережившие эту переработку, напрямую копируются в область «Кому», и возраст этих объектов равен +1. Если есть объект, возраст которого достиг старости, он будет скопирован в старость.
2. Очистить Эдем, SurvivorFrom
   • Пустые объекты в Eden и SurvivorFrom
3. Поменяйте местами SurvivorTo и SurvivorFrom
   • SurvivorTo и SurvivorFrom меняются местами, и исходный SurvivorTo называется областью SurvivorFrom в следующем GC.
   • Некоторые объекты копируются туда и обратно в поля From и To, поэтому меняются местами 15 раз (параметр JVMMaxTenuringThresholdРешение, параметр по умолчанию 15), и если он еще выживет, то будет сохранен в старости.

GC Roots

Мусор: Пространство в памяти, которое больше не используется, является мусором.

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

GC Roots — это набор ссылок, которые должны быть активны.

Объекты, которые можно использовать в качестве корней GC:

1. Объекты, на которые имеются ссылки в стеке виртуальной машины (область локальных переменных в кадре стека, также известная как таблица локальных переменных).
2. Объект, на который ссылаются статические свойства класса в области метода.
3. Объект, на который ссылается константа в области метода.
4. Объекты, на которые ссылается JNI (собственные методы) в стеке собственных методов.

Аргументы JVM

Тип параметра JVM

1. Стандартные параметры: стабильно во всех версиях jdk

- java -version
- java -help
- java -showversion

2. Х-параметры

-Xint：解释执行
-Xcomp: 第一次使用就编译成本地代码
-Xmixed: 默认，先编译后执行

3. ХХ параметры

1. Логический тип

   • -XX:+/- 属性
   • + означает включено, - означает выключено
   • ПримерВ качестве примера возьмем, следует ли печатать сведения о коллекции GC:

     • первое использованиеjps -lПросмотр идентификатора текущего запущенного процесса

     • затем используйтеjinfo -flag PrintGCDetails 进程idсмотреть

     • Если включено, результат должен быть-XX:+PrintGCDetails,в противном случае-XX:-PrintGCDetails

2. Тип КВ

   • -XX:key=value
   • Возьмем в качестве примера размер метапространства MetaspaceSize: также используйте описанный выше метод, используйтеjinfo -flag MetaspaceSize 进程idПроверять.
   • -XmsЭквивалентно-XX:InitialHeapSize,-XmxЭквивалентно-XX:MaxHeapSize

Как просмотреть значения параметров JVM по умолчанию

1. использоватьjava -XX:+PrintFlagsInitalПросмотр исходных параметров jvm
2. использоватьjava -XX:+PrintFlagsFinal -versionПросмотр измененных параметров. используется в параметрах=Описание является неизменяемым параметром, используйте:=Описание — это параметр, измененный человеком или jvm.
3. использоватьjava -XX:+PrintCommandLineFlags

Общие параметры JVM

После JDK 1.8 постоянное поколение было отменено и заменено метапространством. Новое поколение состоит из Eden + SurvivorFrom + SurvivorTo, а размер-Xmnнастраивать. Куча JVM состоит из молодого поколения и старого поколения, состоящего из-Xmsи-XmxУстановить размер. Метапространство больше не является частью кучи.

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

По умолчанию размер метапространства ограничен только локальной памятью, метаданные класса помещаются в нативную память, пул строк и статические переменные класса помещаются в кучу java, поэтому сколько метаданных класса, который может быть загружен, больше не определяется MaxPermSize, контролируемым фактическим доступным пространством системы.

1. -Xms
   • Эквивалентно-XX:InitialHeapSize
   • Начальный размер памяти, по умолчанию 1/64 физической памяти
2. -Xmx
   • Эквивалентно-XX:MaxHeapSize
   • Максимальная выделенная память, по умолчанию 1/4 физической памяти
3. -Xss
   • Эквивалентно-XX:ThreadStackSize
   • Установите размер стека одного потока
   • Linux по умолчанию 1024 КБ
   • OS X по умолчанию имеет размер 1024 КБ.
   • Windows по умолчанию зависит от виртуальной памяти
4. -Xmn
   • Установите размер нового поколения: по умолчанию — 1/3 пространства кучи.
5. -XX:MetaspaceSize
   • Метапространство похоже на постоянное поколение, оба являются реализациями области метода. Метапространство находится не в виртуальной машине, а использует локальную память. По умолчанию размер метапространства ограничен только локальной памятью.
   • Но это не означает, что в метапространстве не будет OOM, потому что его размер памяти по умолчанию ограничен.
6. -XX:+PrintGCDetails
   • Вывод подробной информации из журнала телефонных звонков GC

[GC [PSYoungGen: 2048K -> 496K(2560K)] 2048K->777K(9728k)]

• [GC [PSYoungGen:Указывает тип ГХ
• 2048KУказывает использование памяти молодым поколением до YoungGC.
• 496KУказывает объем памяти молодого поколения после YoungGC.
• (2560K)Указывает общую численность молодого поколения
• 2048KУказывает использование памяти кучи JVM перед YoungGC.
• 777KУказывает использование памяти кучи JVM после YoungGC.
• 9728KУказывает общий размер кучи JVM.

[Full GC (System) [PSYoungGen:3408K->0K(296688k)] [PSOldGen:0K->3363K(682688K)]3408K->3363K(981376K)[Metaspace:10638K->10638K(131072K)]]

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

7. -XX:SurvivorRatio
   • Установить соотношение Эдема и S0/S1 в молодом поколении
   • По умолчанию 8, что означает, что соотношение трех 8:1:1
8. -XX:NewRatio
   • Установить пропорцию молодого поколения и старого поколения в куче
   • Установленное значение устанавливает соотношение старшего поколения к молодому поколению.
9. -XX:MaxTenuringThreshold
   • Установить максимальный возраст мусора, по умолчанию 15
   • Порог, который можно установить в java8, равен 0 ~ 15.
   • Установите небольшое значение, подходящее для приложений со многими старыми поколениями.
   • Установка большего значения может увеличить время выживания объектов в новом поколении и увеличить вероятность повторного использования в новом поколении.

четыре цитаты

SoftReference, WeakReference и PhantomReference наследуются от класса Reference, который является подклассом класса Object.

сильная цитата

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

мягкая ссылка

Для объектов только с программными ссылками они не будут утилизированы при заполнении системы и будут утилизированы при нехватке системной памяти. Мягкие ссылки обычно используются вчувствительный к памятипрограмма, напримертайникИспользуйте мягкие ссылки.

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

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

Map<String, SoftReference<Bitmap>> imageCache = new HashMap<>();

слабая ссылка

Пока GC работает, независимо от того, достаточно ли места в памяти JVM, память, занятая объектом, будет восстановлена.

WeakHashMap

По сравнению с HashMap, когда элементы WeakHashMap перерабатываются, соответствующая пара ключ-значение в карте больше не существует.

public class WeakHashMapDemo {
    public static void main(String[] args) {
        myHashMap();
        System.out.println("======================");
        myWeakHashMap();
    }

    private static void myWeakHashMap() {
        WeakHashMap<Integer,String> map=new WeakHashMap<>();

        Integer k=new Integer(1);
        String v="str";

        map.put(k,v);
        System.out.println(map);

        k=null;
        System.out.println(map);

        System.gc();
        System.out.println(map);
    }

    private static void myHashMap() {
        HashMap<Integer,String> map=new HashMap<>();

        Integer k=new Integer(1);
        String v="str";

        map.put(k,v);
        System.out.println(map);

        k=null;
        System.out.println(map);

        System.gc();
        System.out.println(map);
    }
}

результат операции

{1=str}
{1=str}
{1=str}
======================
{1=str}
{1=str}
{}

эталонная очередь

public class ReferenceQueueDemo {
    public static void main(String[] args) throws InterruptedException {
        Object o1=new Object();
        ReferenceQueue<Object> referenceQueue=new ReferenceQueue<>();
        WeakReference<Object> weakReference=new WeakReference<>(o1,referenceQueue);
        System.out.println(o1);
        System.out.println(weakReference.get());
        System.out.println(referenceQueue.poll());

        System.out.println();
        o1=null;
        System.gc();
        Thread.sleep(1000);

        System.out.println(o1);
        System.out.println(weakReference.get());
        System.out.println(referenceQueue.poll());

    }
}

java.lang.Object@1b6d3586
java.lang.Object@1b6d3586
null

null
null
java.lang.ref.WeakReference@4554617c

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

фантомная ссылка

Как следует из названия, виртуальная ссылка — это виртуальная ссылка, и она не определяет период объявления объекта. Если объект содержит только фантомную ссылку, он может быть восстановлен в любое время, как если бы у него не было ссылки. Виртуальную ссылку нельзя использовать отдельно, и через нее нельзя получить доступ к объекту, она должна использоваться в сочетании с очередью ссылок.

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

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

public class PhantomReferenceDemo {
    public static void main(String[] args) throws InterruptedException {
        Object o1=new Object();
        ReferenceQueue<Object> referenceQueue=new ReferenceQueue<>();
        PhantomReference<Object> phantomReference=new PhantomReference<>(o1,referenceQueue);

        System.out.println(o1);
        System.out.println(phantomReference.get());
        System.out.println(referenceQueue.poll());

        System.out.println();
        o1=null;
        System.gc();
        Thread.sleep(1000);

        System.out.println(o1);
        System.out.println(phantomReference.get());
        System.out.println(referenceQueue.poll());
    }
}

результат операции:

java.lang.Object@1b6d3586
null
null

null
null
java.lang.ref.PhantomReference@4554617c

Как видите, возвращаемое значение get() виртуальной ссылки всегда равно null.

Суммировать

При создании ссылки вы можете указать соответствующую очередь.Когда GC освобождает память объекта, ссылка будет добавлена ​​в очередь ссылок. Если программа обнаруживает, что виртуальная ссылка была добавлена ​​в очередь ссылок, она может предпринять необходимые действия, прежде чем память объекта, на который указывает ссылка, будет освобождена, что эквивалентно механизму уведомления. Таким образом, JVM позволяет нам делать то, что мы хотим, после уничтожения объекта.

OOM

java.lang.StackOverflowError

При выполнении рекурсивного вызова глубина вызова стека слишком велика, что приводит к ошибке переполнения стека. Отношения наследования следующие:

Throwable -> Error -> VirtualMachineError -> StackoverflowError

java.lang.OutOfMemoryError: Java heap space

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

java.lang.OutOfMemoryError: GC overhead limit exceeded

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

Что произойдет, если ошибка ограничения накладных расходов сборщика мусора не будет выдана: память, очищенная сборщиком мусора, быстро снова заполняется, и неисправный сборщик мусора выполняется снова, образуя порочный круг. Результаты.

public class GCOverheadDemo {
    public static void main(String[] args) {
        int i = 0;
        List<String> list = new ArrayList<>();
        
        while (true) {
            list.add(String.valueOf(++i).intern());
        }
    }
}

java.lang.OutOfMemoryError: Direct buffer memory

При написании программ NIO часто используется ByteBuffer для чтения или записи данных. Он может использовать библиотеку собственных функций для прямого выделения памяти вне кучи, а затем работать с объектом DirectByteBuffer, хранящимся в куче Java, в качестве ссылки на эту память. Это может значительно повысить производительность в некоторых сценариях, поскольку позволяет избежать копирования данных туда и обратно между кучей Java и собственной кучей.

ByteBuffer.allocate(capability)Это выделение памяти кучи JVM, которая относится к юрисдикции GC, и скорость относительно низкая из-за необходимости копирования.

ByteBuffer.allocateDirect(capability)Он предназначен для выделения локальной памяти ОС, которая не находится под юрисдикцией GC.Это относительно быстро, потому что не требует копирования памяти.

Если локальная память выделяется постоянно, а память кучи используется редко, то JVM не нужно выполнять сборку мусора, и объект DirectByteBuffer не будет перерабатываться, в результате чего памяти кучи достаточно, но локальная память уже израсходована.

java.lang.OutOfMemoryError: Unable to create new native thread

Это исключение возникает при большом количестве одновременных запросов к серверу.

Вызванный:

1. Приложение создает слишком много потоков, а один процесс приложения создает несколько потоков, что превышает лимит системы.
2. Сервер не позволяет приложениям создавать так много потоков.По умолчанию количество потоков, которое может создать один процесс в системе Linux, равно 1024.

Решение:

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

java.lang.OutOfMemoryError: metaspace

MetaSpace — это реализация области методов в HotSpot, она не находится в памяти виртуальной машины, а использует локальную память, то есть метаданные класса хранятся в родной памяти MetaSpace.

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

уборщик мусора

Четыре идеи сборщика мусора

Serial

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

Процесс таков: программа запущена -> один поток GC -> запущена программа

Parallel

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

Процесс: выполнение программы -> параллельное выполнение нескольких потоков GC -> выполнение программы

CMS

параллелизмСборщик мусора, пользовательский поток и поток GC выполняются одновременно, и нет необходимости приостанавливать пользовательский поток, что подходит для сценариев, требующих времени отклика (сильное взаимодействие).

Процесс: начальная метка (пауза, один поток) -> параллельная метка (поток GC и пользовательский поток выполняются одновременно) -> конечная метка (пауза, несколько потоков GC) -> очистить

G1

Сборщик мусора G1 делит память кучи на разные регионы (регионы) и одновременно выполняет сборку мусора в них.

Просмотр сборщика мусора по умолчанию

использоватьjava -XX:+PrintCommandLineFlags -versionПроверьте сборщик мусора по умолчанию.

В java8 по умолчанию-XX:+UseParallelGC.

Что такое сборщики мусора по умолчанию

Типы gc в Java следующие:

• UseSerialGC
• UseParallelGC
• UseConcMarkSweepGC
• UseParNewGC
• UseParallelOldGC
• UseG1GC

Среди семи сборщиков мусора в jvm от Serial Old отказались, поэтому в исходном коде gc их шесть, как указано выше.

Семь типов сборщиков мусора

В новом поколении есть:

1. Serial
2. Parallel Scavenge
3. ParNew

В пожилом возрасте бывают:

1. Serial Old
2. Parallel Compacting
3. CMS

Оба могут использоваться с G1.

DefNew: Default New Generation
Tenured: Old
ParNew: Parallel New Generation
PSYoungGen: Parallel Scavenge
ParOldGen: Parallel Old Generation

Коллекционер сериалов нового поколения: сериал

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

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

Аргументы JVM:-XX:+UseSerialGCПосле его включения новое поколение использует Serial, а старое поколение использует Serial Old.И новое поколение, и старое поколение используют сборщик серийных коллекций, новое поколение использует алгоритм репликации, а старое поколение использует алгоритм сортировки по меткам. .

В журнале GC молодое поколение используетDefNew, используется в пожилом возрастеTenured.

Параллельный коллекционер молодого поколения: ParNew

Используйте многопоточность для сборки мусора.Во время сборки мусора STW приостанавливает другие потоки до завершения сборки мусора.

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

Аргументы JVM:-XX:+UseParNewGC. Когда этот параметр включен, молодое поколение использует ParNew , старое поколение использует Serial Old, молодое поколение использует алгоритм копирования, а старое поколение использует алгоритм маркировки-сопоставления. Обратите внимание, что ParNew + Serial Old больше не рекомендуется.

В журнале GC молодое поколение используетParNew, используется в пожилом возрастеTenured.

Параллельный коллекционер нового поколения: Parallel Scavenge

Сборщик Parallel Scavenge похож на ParNew, это тоже сборщик мусора нового поколения, использующий алгоритм репликации, это параллельный многопоточный сборщик мусора.приоритет пропускной способностиколлекционер.

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

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

Аргументы JVM:-XX:+UseParallelGC, с использованием-XX:+UseParallelOldGCЭффект тот же, два коллектора по умолчанию используются вместе, поэтому они будут активировать друг друга. Когда эта функция включена, новое поколение использует алгоритм репликации, а старое поколение использует алгоритм маркировки-сопоставления.

После включения коллектора в логе GC вывод нового поколенияPSYoungGen, выход в старостиParOldGen.

В Java 8 этот сборщик является сборщиком по умолчанию.

Параллельный коллектор старого поколения: Parallel Old

Сборщик Parallel Old — это старая версия Parallel Scavenge, использующая многопоточный алгоритм маркировки и сортировки, доступный, начиная с JDK 1.6.

До JDK 1.6 Parallel Scavenge в новом поколении можно было использовать только с Serial Old старого поколения, что может гарантировать только пропускную способность нового поколения.

В JDK 1.8 и более поздних версиях конфигурация по умолчанию — Parallel Scavenge + Parallel Old, что обеспечивает общий приоритет пропускной способности.

Аргументы JVM:-XX:+UseParallelOldGC, после старта новое поколение использует Parallel Scavenge, а старое поколение использует Parallel Old.

После включения коллектора в логе GC вывод нового поколенияPSYoungGen, выход в старостиParOldGen.

Параллельный сборщик меток-разверток старого поколения: CMS

CMS (Councurrent Mark Sweep) — этоМинимальное время восстановительной паузыСборщик в качестве цели подходит для приложения на сервере Интернета или системы B / S. В этом типе приложения это соответствующая скорость сервера, и есть надежда, что время паузы системы будет кратчайшим. CMS подходит для серверных приложений с большой памятью кучи и большим количеством ядер ЦП.

Аргументы JVM:-XX:+UseConcMarkSweepGC, после включения этого параметра он будет включен автоматически-XX:+UseParNewGC. Используйте комбинацию коллекторов ParNew (новое поколение) + CMS + Serail Old, где Serial Old — резервный коллектор для ошибок CMS.

1. Начальная метка: помечайте объекты, напрямую связанные с GC Roots, что быстро и требует STW.
2. Параллельная маркировка: процесс отслеживания корней GC, работа с пользовательскими потоками, маркировка всех объектов без приостановки рабочих потоков.
3. Remarking: Исправляет запись объектов, маркировка которых изменилась, поскольку пользовательская программа продолжает работать во время одновременной маркировки.Требуется STW.
4. Параллельная очистка: очищайте недоступные объекты от корней сборщика мусора, работайте с пользовательскими потоками и не приостанавливайте рабочие потоки.

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

Достоинства: одновременный сбор, малая пауза.

недостаток:

• Параллельное выполнение сильно нагружает ресурсы ЦП: при параллельном выполнении CMS увеличивает использование памяти кучи во время сбора данных. Поэтому CMS должен завершить сборку мусора до того, как память кучи старого поколения будет исчерпана, иначе при сбое сборки CMS сработает механизм гарантии, и Serial Old выполнит сборку мусора в режиме STW, что приведет к большой паузе.
• Использование алгоритма маркировки-развертки приводит к сильной фрагментации.

Коллекционер сериалов старого поколения: Serial Old

Serial Old — это версия сборщика Serial старого поколения.Это однопоточный сборщик, который использует алгоритм сортировки меток и является сборщиком старого поколения по умолчанию для клиента.

В режиме сервера:

• В паре с Parallel Scavenge следующего поколения до JDK 1.5.
• Используйте сборщик CMS в качестве резервной схемы сборки мусора для старого поколения.

Как выбрать сборщик мусора

• Один процессор или небольшая память, автономная программа:-XX:+UseSerailGC
• Несколько процессоров, требующих максимальной пропускной способности, например приложения для фоновых вычислений:-XX:+UseParallelGCили-XX:+UseParallelOldGC
• Приложения с несколькими процессорами, стремящиеся к малому времени паузы и быстрому отклику:-XX:+UseConcMarkSweepGC

параметр	Сборщик мусора молодого поколения	алгоритм нового поколения	Сборщик мусора старого поколения	алгоритм старости
-XX:+UseSerialGC	SerialGC	копировать	SerailOldGC	разметка
-XX:+UseParNewGC	ParNew	копировать	SerailOldGC	разметка
-XX:+UseParallelGC/-XX:+UseParallelOldGC	Parallel Scavenge	копировать	Parallel Old	разметка
-XX:+UseConcMarkSweepGC	ParNew	копировать	CMS+Serial Old	пометить как очищенный

коллектор G1

garbage-first heap+metaspace

Особенности коллекторов до G1

1. Молодое и старое поколения являютсянезависимый и непрерывныйблок памяти
2. Молодое поколение использует алгоритм репликации eden + s0 + s1.
3. Коллекция старого поколения должна сканировать всю область старого поколения
4. Оба предназначены для выполнения GC как можно меньше и как можно быстрее

Введение в G1

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

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

Цель разработки G1 — заменить сборщик CMS по сравнению с CMS:

• G1 имеет процесс сортировки памяти, который не вызовет сильной фрагментации памяти.
• STW G1 более управляем, и к времени паузы добавлен механизм прогнозирования, и пользователь может указать желаемое время паузы.

Основное изменение G1 заключается в том, что области памяти, такие как Eden, Survivor и Tenured, больше не являются смежными, а становятся областями одинакового размера.

Особенности G1

1. G1 может в полной мере использовать аппаратные преимущества нескольких ЦП и минимизировать STW.
2. G1 использует алгоритм сортировки меток в целом и частично передает алгоритм копирования, что не приводит к фрагментации памяти.
3. G1 делит память на несколько независимых регионов.
4. G1 логически сохраняет новое поколение и старое поколение, но они уже не физически изолированы, а представляют собой совокупность части регионов (и регионы не обязаны быть непрерывными), и для обработки разных регионов будут использоваться разные методы GC. .
5. G1 имеет только логическую концепцию поколения, и каждый раздел может переключаться между разными поколениями во время работы G1.

Region

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

Размер каждого региона варьируется от 1 МБ до 32 МБ, и можно установить максимум 2048 регионов (по умолчанию также 2048), поэтому максимальный поддерживаемый объем памяти составляет 64 ГБ.

G1 по-прежнему является коллекционером поколения. Часть этих регионов содержит новое поколение, а сборщик мусора (Эдем) нового поколения использует метод STW для копирования уцелевших объектов в старое поколение или в пространство оставшихся в живых. Другая часть региона относится к старому поколению, G1 завершает очистку копированием объектов из одного региона в другой, поэтому проблемы с фрагментацией памяти CMS не будет.

В G1 также есть особая область под названием Humongous area.Если объект занимает более 50% пространства в Регионе, он считается огромным объектом и будет выделен непосредственно в старом поколении. G1 разделяет Humongous область для хранения огромных предметов. Если Огромный регион не может содержать огромный объект, G1 будет искать последовательные Огромные регионы для сохранения.Чтобы найти последовательные H-регионы, иногда приходится запускать полный сборщик мусора.

этапы переработки

Молодой ГК: Сбор ведется для района Эдем, а район Эдема истощается и наказывается, в основном из-заСбор небольшой области + формирование непрерывного блока памяти, чтобы избежать фрагментации памяти.

• Данные из области Eden перемещаются в область Survivor.Если в области Survivor недостаточно места, они будут перемещены в область Old.
• Данные в области Survivor перемещаются в новую область Survivor, а некоторые перемещаются в старую область.
• GC завершается, приложение продолжает выполнение

шаг:

1. начальная отметка
2. одновременная маркировка
3. окончательная оценка
4. Проверка на переработку: переработка по времени для максимизации ценности

Развертывание микросервисов в производственной среде и оптимизация настройки параметров

Рабочий сервер тормозит

1. Проверить всю машину
   • использоватьtopКоманда для просмотра использования ЦП, использования памяти и средней загрузки первой строки
   • Три числа после средней нагрузки отражают среднюю загрузку системы за одну, пять и пятнадцать минут соответственно.
   • также можно использоватьuptimeкоманда, которая представляет собой урезанную версию команды производительности системы
2. Проверьте ЦП
   • использоватьvmstat -n 2 3Представляет выборку каждые 2 секунды, всего 3 выборки
   • в процессах
     • r представляет собой количество запущенных процессов и ожидающих квантов процессорного времени.Очередь выполнения всей системы не должна превышать 2-кратное общее количество ядер, в противном случае это означает, что нагрузка на систему слишком велика.
     • b представляет количество процессов, ожидающих ресурсов, таких как дисковый ввод-вывод, сетевой ввод-вывод
   • в процессоре
     • us представляет процент процессорного времени, потребляемого пользовательским процессом, если долгосрочное больше 50%, программа должна быть оптимизирована
     • sy представляет собой процент процессорного времени, потребляемого процессом ядра.
     • Эталонное значение us + sy составляет 80%, если сумма больше 80%, может быть недостаточно ЦП.
   • использоватьmpstat -P ALL 2Просмотр всей информации о ядре ЦП
   • использоватьpidstat -u 1 -p pidПросмотр разбивки использования ЦП каждым процессом
3. Просмотр информации о памяти
   • использоватьfree -mДля просмотра ситуации с памятью единицей измерения является МБ.
   • Доступная память приложения/физическая память системы должна быть 20%~70%
   • использоватьpidstat -p pid -r 采样间隔秒数
4. Просмотр информации о жестком диске
   • использоватьdf -h
5. Просмотр дискового ввода-вывода
   • использоватьiostat -xdk 2 3
     • rkB/s Количество считываемых данных в секунду
     • wkB/s Количество данных, записываемых в секунду
     • Среднее время обслуживания запросов ввода/вывода svctm, мс
     • util Какой процент секунды используется для операций ввода-вывода
   • использоватьpidstat -d 采样间隔秒 -p pid
6. Просмотр сетевого ввода-вывода
   • использоватьifstat 采样间隔秒

Анализ высокой загрузки ЦП

1. использоватьtopКоманда для определения процесса с наибольшей загрузкой ЦП
2. ps -efилиjpsДалее найдите информацию о процессе
3. Найдите конкретный поток или код
   • использоватьps -mp pid -o THREAD,tid,time
     • -m показать все темы
     • -p процесс pid с использованием процессорного времени
     • -o сопровождается определяемым пользователем форматом
4. Преобразование требуемого идентификатора потока в шестнадцатеричный формат (строчный английский формат)
5. jstack 进程id | grep tid -A60