вывоз мусора
Теория переработки поколений
Большинство современных коммерческих сборщиков мусора для виртуальных машин разработаны в соответствии с теорией «сборки поколений», которая обычно описывается следующим образом:
1. Большинство объектов — это жизнь и смерть.
2. Объекты, пережившие многократную сборку мусора, труднее перерабатывать.
Согласно двум вышеупомянутым теориям, объекты, которые скоро умирают, помещаются в одну область, а объекты, которые трудно перерабатывать, помещаются в другую область, что составляет новое поколение и старое поколение.
классификация ГХ
1. Young GC (Minor GC/Young GC): относится только к восстановлению нового поколения.
2. Коллекция старого поколения (Major GC/Old GC): относится только к коллекции старого поколения. В настоящее время только сборщик мусора CMS имеет это отдельное поведение старого поколения.
(Определение Major GC довольно запутанно. Некоторые говорят, что оно относится к старому поколению, а некоторые говорят, что это сбор всей кучи. Это нужно определять по чужим сценариям, а фиксированного утверждения нет.)
3. Полная переработка кучи (Full GC): собрать всю кучу Java и область метода (обратите внимание, что область метода включена).
алгоритм сборки мусора
Алгоритм копирования (Copying)
Разделите доступную память на две части одинакового размера в соответствии с емкостью и используйте только одну из них за раз. Когда память этого блока будет израсходована, скопируйте уцелевший объект в другой блок, а затем за один раз очистите используемое пространство памяти. Таким образом, память каждый раз освобождается для всей половинной области, и нет необходимости рассматривать сложные ситуации, такие как фрагментация памяти, при выделении памяти, поскольку память выделяется по порядку, что просто реализовать и эффективно работать. Просто стоимость этого алгоритма заключается в том, чтобы уменьшить объем памяти вдвое по сравнению с ее первоначальным размером.
Но будьте осторожны: перемещение памяти — это реальное перемещение (копирование), поэтому соответствующую ссылку (прямой указатель) необходимо скорректировать.
Алгоритм восстановления копий подходит для нового поколения, потому что большинство объектов рождаются и умирают, поэтому объектов, скопированных в прошлом, относительно мало, а эффективность, естественно, высока, а другая половина одноразовой очистки составляет очень быстро.
Переработка аппеля
Более оптимизированная стратегия генерации для восстановления копии: конкретный метод заключается в выделении большей области Эдема и двух меньших пространств Выживших (вы можете назвать это От или Кому, или Выживший1 и Выживший2).
Специальные исследования показывают, что 98% объектов в новом поколении «живут и умирают», поэтому не нужно делить пространство памяти по соотношению 1:1, а делить память на одно большее пространство Эдема и два маленькое место для выживших, используйте Иден и одного выжившего[1] каждый раз. При переработке скопируйте уцелевшие объекты в Эдеме и Выжившем в другое пространство Выжившего за один раз и, наконец, очистите Эдем и только что использованное пространство Выжившего.
Соотношение Eden к Survivor по умолчанию для виртуальной машины HotSpot составляет 8:1, то есть доступное пространство памяти в каждом новом поколении составляет 90% (80%+10%) от всей емкости нового поколения и только 10% от память будет "утрачена". Конечно, 98% перерабатываемых объектов - это только данные в общих сценариях. У нас нет возможности гарантировать, что не более 10% объектов переживут каждую переработку. Когда места Survivor недостаточно, нам нужно полагаться на другие память (здесь относится к старому поколению) для выполнения гарантийного назначения (ручка продвижения)
Алгоритм маркировки-очистки (Mark-Sweep)
Алгоритм разделен на два этапа «маркировки» и «очистки»: сначала сканируются все объекты, чтобы пометить объекты, которые необходимо переработать, а затем сканируются и перерабатываются все отмеченные объекты после завершения маркировки, поэтому сканирование необходимо дважды.
Эффективность восстановления несколько ниже, если большая часть объектов живая и мертвая, то эффективность восстановления будет снижена, так как требуется большое количество помеченных объектов и переработанных объектов, что ниже эффективности восстановления копирования.
Его основная проблема заключается в том, что после очистки метки будет сгенерировано большое количество прерывистых фрагментов памяти.Слишком большая фрагментация пространства может привести к тому, что когда программе потребуется выделить большие объекты в будущем, она не сможет найти достаточно непрерывной памяти и должна будет запускать другой заранее Действие по сбору мусора.
При переработке, если необходимо переработать больше объектов, необходимо выполнить больше работы по маркировке и очистке, поэтому алгоритм очистки маркировки подходит для старого поколения.
Алгоритм маркировки-сопоставления (Mark-Compact)
Сначала отметьте все объекты, которые необходимо переработать.После того, как маркировка завершена, следующим шагом будет не прямая очистка перерабатываемых объектов, а перемещение всех уцелевших объектов в один конец, а затем непосредственно очистка памяти за пределами конца граница. Хотя алгоритм сортировки по меткам не имеет фрагментации памяти, его эффективность невысока.
Мы видим, что алгоритмы сортировки по меткам и подметания по меткам различаются главным образом перемещением объектов. Перемещение объектов не только увеличит нагрузку на систему, но и потребует приостановки пользовательского потока на весь процесс, а также необходимость обновления всех ссылок на объекты (необходима корректировка прямых указателей).
Таким образом, можно видеть, что алгоритм сортировки меток и алгоритм очистки меток, используемые в старом поколении, имеют свои преимущества и недостатки.
Общие сборщики мусора в JVM
В новом поколении обнаружено, что большое количество объектов умирает и только небольшое количество объектов выживает каждый раз, когда выполняется сборка мусора, поэтому используется алгоритм репликации, и переработка может быть завершена только путем оплаты стоимости копирования. небольшое количество уцелевших объектов.
В старом поколении из-за того, что объект имеет высокую выживаемость и нет дополнительного места для его выделения, необходимо использовать для утилизации алгоритм «отметить-очистить» или «отметить-организовать».
Серийный/Серийный Старый
Существует только такая JVM, когда она родилась, самая старая, однопоточная, эксклюзивная, зрелая, подходящая для одного процессора и обычно используемая в режиме клиента.
Этот вид сборщика мусора подходит только для сборки мусора от десятков мегабайт до одной или двухсот мегабайт пространства кучи (время паузы можно контролировать примерно до 100 мс), но скорость восстановления памяти, превышающей этот размер, очень низкая, поэтому а пока этот мусор Переработчик уже безвкусный.
Останови мир (STW)
Когда один поток выполняет сборку мусора, все рабочие потоки должны быть приостановлены до тех пор, пока он не завершит переработку. Эта приостановка называется «Остановить мир», но эта STW приносит плохой пользовательский опыт, например: приложение должно приостанавливаться на 5 минут каждый час, когда оно работает. Это также важная причина, по которой ранние JVM и java подвергались критике за низкую производительность языка C/C++. Поэтому команда разработчиков JVM усердно работала над устранением или сокращением времени STW.
Parallel Scavenge (ParallerGC)/Parallel Old
Чтобы повысить эффективность утилизации, начиная с JDK1.3, JVM использует многопоточный механизм сборки мусора, ориентируясь на пропускную способность сборщика мусора.Высокая пропускная способность позволяет эффективно использовать время ЦП и выполнять вычислительные задачи программы, как только Это в основном подходит для задач, которые работают в фоновом режиме без особого взаимодействия.
Так называемая пропускная способность — это отношение времени, затрачиваемого ЦП на выполнение пользовательского кода, к общему времени, затрачиваемому ЦП, то есть пропускная способность = время выполнения пользовательского кода/(время выполнения пользовательского кода + время сборки мусора) , виртуальная машина работает всего 100 минут, из них сбор мусора занимает 1 минуту, поэтому пропускная способность 99%.
Сборщик мусора подходит для высвобождения от сотен мегабайт до нескольких гигабайт пространства кучи.
ParNew
Многопоточный сборщик мусора взаимодействует с CMS, для CMS (CMS собирает только старое поколение) сборщик мусора нового поколения может выбирать только Serial и ParNew. Отличий от Serial в принципе нет, единственное отличие: многопоточность, многопроцессорность и меньшее время паузы, чем у Serial. (После JDK9 ParNew был объединен с CMS)
Параллельная развертка меток (CMS)
процесс переработки
Сборщик — это сборщик, целью которого является получение кратчайшего времени паузы сбора. В настоящее время большая часть Java-приложений сосредоточена на веб-сайтах в Интернете или системных серверах B/S.Такие приложения уделяют особое внимание скорости отклика служб и надеются, что время паузы системы будет кратчайшим, чтобы улучшить опыт пользователям. Сборщик CMS очень подходит для нужд этого типа приложений.
Как видно из названия (в том числе «Mark Sweep»), сборщик CMS реализован на основе алгоритма «отметить-очистить», и его работа сложнее, чем у предыдущих сборщиков.
Весь процесс делится на 4 этапа, в том числе:
初始标记
В течение короткого времени просто отмечайте объекты, к которым GC Roots может иметь непосредственное отношение, и скорость очень высокая.
并发标记
Одновременно с прикладной программой пользователя выполняется процесс отслеживания GC Roots, и все объекты, связанные с GCRoots, помечаются для прохождения всего достижимого пути анализа. Это время относительно велико, поэтому используется параллельная обработка (потоки сборщика мусора и пользовательские потоки работают одновременно).
重新标记
Короткий, чтобы исправить запись метки той части объекта, чья метка изменяется из-за продолжающейся работы пользовательской программы во время одновременной маркировки, время паузы на этом этапе обычно немного больше, чем на начальной стадии маркировки, но намного короче совпадающего знака.
并发清除
Поскольку самые длинные параллельные потоки сборщика процесса маркировки и параллельной очистки во всем процессе могут работать вместе с пользовательскими потоками, вообще говоря, процесс восстановления памяти сборщика CMS выполняется одновременно с пользовательскими потоками.
Проблемы с ресайклером CM
CPU敏感：CMS чувствительна к ресурсам процессора, ведь используется параллельный сбор, когда количество процессорных ядер меньше 4, CMS оказывает большее влияние на пользователей.
浮动垃圾：Так как пользовательский поток все еще работает во время параллельной фазы очистки CMS, новый мусор, естественно, будет продолжать генерироваться по мере работы программы.Эта часть мусора появляется после процесса маркировки, и CMS не может избавиться от него в текущей коллекции, поэтому его нужно сохранить для следующего раза.Очистите его во время GC. Эта часть мусора называется «плавающий мусор».
Из-за существования плавающего мусора часть памяти необходимо резервировать, а это значит, что CMS-коллекция не может ждать, пока старое поколение будет почти заполнено, как другие сборщики, прежде чем утилизировать.
会产生空间碎片：Алгоритм пометки и очистки приводит к несмежным фрагментам пространства.
Фрагментация создает две проблемы:
проблема эффективности
1、空间分配效率较低：
Если это непрерывное пространство, JVM можно выделить с помощью коллизии указателей, но для такого свободного списка с большим количеством фрагментов необходимо обращаться к элементам в свободном списке один за другим, чтобы найти адрес, который может сохранить новый объект.
2、空间利用效率变低：
Размер продвигаемых в новом поколении объектов больше, чем размер непрерывного пространства.Даже если вместимости всей Старой области достаточно, она не может хранить новые объекты из-за своей прерывистости. Это сбой продвижения, вызванный фрагментацией памяти. Молодой GC думал, что в старом достаточно места. В результате, когда он был выделен, продвигаемый большой объект не мог найти непрерывное пространство для его хранения.
деградация сборщика мусора
Если это произойдет, Promotion Failed, то CMS выродится, а однопоточный последовательный режим GC обычно использует Serial Old, потому что Serial Old является однопоточным, поэтому, если объем памяти большой и объектов много, эта ситуация будет происходят в CMS с задержкой.
Serial использует алгоритм сортировки по меткам и однопоточный метод полной паузы для сбора мусора во всей куче, а время паузы больше, чем у CMS.