помещение
В последнее время, в связи с относительно большим объемом системного бизнеса, от производстваGCжурнал (объединенныйPinpoint), некоторые системы должны бытьGCТюнинг. Но ввиду того, что в прошлом это не делалось специально, а имело место разрозненное накопление, вот относительно исчерпывающее резюме. Эта статья только дляHotSpot VMто естьOracle Hotspot VMилиOpenJDK Hotspot VM, версия естьJDK8.
Что такое GC (сборка мусора)
Garbage CollectionМожно перевести как "сборка мусора" -- вообще субъективно думаю, что метод такой: найти мусор, а потом его выкинуть. существуетJVMсередина,GCПроцесс реализации прямо противоположный,GCЦель состоит в том, чтобы отслеживать все используемые объекты и помечать оставшиеся объекты как мусор, а затем объекты, помеченные как мусор, будут очищены, а память, занятая этими объектами мусора, будет освобождена, тем самым реализуя автоматическое управление памятью.
Поколенческая гипотеза
| имя | конкретное содержание |
|---|---|
| Слабая гипотеза поколений | Большинство испытуемых умирают молодыми |
| Сильная гипотеза поколений | У пожилых людей меньше шансов умереть |
гипотеза слабого поколениябыл продемонстрирован во множестве различных типов парадигм программирования или языков программирования, в то время какГипотеза сильного поколенияДоказательств, представленных на данный момент, недостаточно, и мнения все еще обсуждаются.
Основная цель разработки сборщика мусора поколения состоит в том, чтобы сократить время паузы в процессе сборки, одновременно улучшая пространственную пропускную способность. Если для сбора объектов молодого поколения используется алгоритм копирования, ожидаемое время паузы сильно зависит от вторичных коллекций (Minor Collection), что в свою очередь зависит от общего пространства молодого поколения.
Если общее пространство молодого поколения слишком мало, хотя процесс одной коллекции происходит быстрее, поскольку интервал между двумя коллекциями слишком короткий, у объектов молодого поколения может не хватить времени, чтобы «достичь смерти», в результате чего не так много собирается память. , может привести к следующим ситуациям:
- Объекты молодого поколения собираются слишком часто, и количество объектов, которые необходимо скопировать, чтобы сохраниться, увеличивается, что увеличивает нагрузку сборщика мусора на приостановку потока и сканирование данных в его стеке.
- Продвижение большой доли объектов молодого поколения к старому поколению приведет к быстрому заполнению старого поколения, что повлияет на скорость сборки мусора всей кучи.
- Существует много свидетельств того, что модификация объектов молодого поколения происходит чаще, чем модификация объектов старого поколения.Если объекты молодого поколения продвигаются до старого поколения преждевременно, то большое количество операций обновления (
Mutation) окажет сильное давление на барьер записи оценщика. - Продвижение объектов разрежает рабочий набор программы.
Искусство уравновешивания вышеперечисленных аспектов разработчиками сборщиков мусора поколений:
- Максимально ускорить вторичное восстановление.
- Свести к минимуму затраты на вторичную переработку.
- Для снижения затрат на переработку более высокая первичная переработка (
Major Collection). - Соответствующим образом уменьшить накладные расходы на управление памятью оценщика.
на основегипотеза слабого поколения,JVMКуча памяти делится на молодые поколения (Young Generation) и старость (Old Generation), а старость иногда называютTenured.
JVMДля разных поколений предусмотрены разные алгоритмы сборки мусора. На самом деле объекты между разными поколениями могут ссылаться друг на друга, и эти объекты, на которые есть ссылки, также будут рассматриваться как сборщик мусора поколений.GC Roots(см. следующий раздел для анализа). Гипотеза слабой генерации может быть неприемлемой для определенных приложений в определенных сценариях.GCАлгоритм оптимизирован для объектов в молодом или старом поколении, для объектов со «средней» (имеются в виду те объекты, которые не умирают, но не достигли возраста выведения в старое поколение) продолжительностью жизни,JVMПроизводительность сборки мусора относительно ниже.
алгоритм обнаружения объектов
JVMin через алгоритм достижимости (Reachability Analysis- определить, жив ли объект. Основная идея этого алгоритма такова: через некоторые столбцы, называемыеGC RootsАктивные ссылки (корневой набор GC) являются начальными точками, и поиск начинается с этих узлов набора, а путь, пройденный поиском, называется цепочкой ссылок (Reference Chain), когда объектGC RootsКогда нет подключенной цепочки ссылок, объект недоступен.
GC RootsЧто именно это означает? Это можно получить изHotSpot VMизParallel ScavengeРеализация исходного кода резюмирована, ссылкаjdk9Разветвленные исходные файлыpsTasks.hppа такжеpsTasks.cpp:
// psTasks.hpp
class ScavengeRootsTask : public GCTask {
public:
enum RootType {
universe = 1,
jni_handles = 2,
threads = 3,
object_synchronizer = 4,
flat_profiler = 5,
system_dictionary = 6,
class_loader_data = 7,
management = 8,
jvmti = 9,
code_cache = 10
};
private:
RootType _root_type;
public:
ScavengeRootsTask(RootType value) : _root_type(value) {}
char* name() { return (char *)"scavenge-roots-task"; }
virtual void do_it(GCTaskManager* manager, uint which);
};
// psTasks.cpp
void ScavengeRootsTask::do_it(GCTaskManager* manager, uint which) {
assert(ParallelScavengeHeap::heap()->is_gc_active(), "called outside gc");
PSPromotionManager* pm = PSPromotionManager::gc_thread_promotion_manager(which);
PSScavengeRootsClosure roots_closure(pm);
PSPromoteRootsClosure roots_to_old_closure(pm);
switch (_root_type) {
case universe:
Universe::oops_do(&roots_closure);
break;
case jni_handles:
JNIHandles::oops_do(&roots_closure);
break;
case threads:
{
ResourceMark rm;
Threads::oops_do(&roots_closure, NULL);
}
break;
case object_synchronizer:
ObjectSynchronizer::oops_do(&roots_closure);
break;
case flat_profiler:
FlatProfiler::oops_do(&roots_closure);
break;
case system_dictionary:
SystemDictionary::oops_do(&roots_closure);
break;
case class_loader_data:
{
PSScavengeKlassClosure klass_closure(pm);
ClassLoaderDataGraph::oops_do(&roots_closure, &klass_closure, false);
}
break;
case management:
Management::oops_do(&roots_closure);
break;
case jvmti:
JvmtiExport::oops_do(&roots_closure);
break;
case code_cache:
{
MarkingCodeBlobClosure each_scavengable_code_blob(&roots_to_old_closure, CodeBlobToOopClosure::FixRelocations);
CodeCache::scavenge_root_nmethods_do(&each_scavengable_code_blob);
AOTLoader::oops_do(&roots_closure);
}
break;
default:
fatal("Unknown root type");
}
// Do the real work
pm->drain_stacks(false);
}
из-заHotSpot VMВ исходном коде мало комментариев, поэтому я могу сослаться только на некоторые материалы и конкретное предположение реализации метода исходного кода.GC RootsСпецифическая композиция:
-
Universe::oops_do: Активные ссылки на объекты в кучи GC в некоторых статических структурах данных VM и т. Д. -
JNIHandles::oops_do:всеJNI handle, включая всеglobal handleа такжеlocal handle. -
Threads::oops_do: стек виртуальной машины всех потоков, в частности ссылки на объекты в куче сборщика мусора в текущих активных кадрах стека всех потоков Java, или, другими словами, параметры ссылочного типа, локальные переменные или временное значение. -
ObjectSynchronizer::oops_do: Все объекты, связанные с объектным синхронизатором, см. исходный код должны бытьObjectMonitorв серединеBlockгосударственный объект, отJavaУровень кода должен быть черезsynchronizedБлокировка по ключевому слову или объект, ожидающий блокировки. -
FlatProfiler::oops_do: во всех темахThreadProfiler. -
SystemDictionary::oops_do:System Dictionary, то есть системный словарь, в который записывается указатель наKlass,KEYЯвляетсяEntry,Зависит отKalssNameа такжеClassloaderсоставлен, по сути,YGCне справитсяSystem Dictionary, но сканируетSystem Dictionary,немногоGCМожет сработать функция выгрузки класса, что можно понять следующим образом:System DictionaryСодержит все загрузчики классов. -
ClassLoaderDataGraph::oops_do: Все загруженные классы или загруженные системные классы. -
Management::oops_do:MBeanудерживаемый объект. -
JvmtiExport::oops_do:JVMTIЭкспортированные объекты, точки останова или объекты, которые выделяют объекты, связанные со сборщиком событий. -
CodeCache::scavenge_root_nmethods_do:кэш кода(Code Cache). -
AOTLoader::oops_do:AOTСвязанные с загрузчиком, в том числеAOTКэш связанного кода.
Возможны и другие ссылки:
StringTable::oops_do: все резидентные строки (StringTableстрока в ).
Пул памяти в JVM
JVMРазделите пул памяти на несколько областей. Состав и основные функции каждой области описаны ниже для удобства.GCАлгоритмы для понимания того, как сборка мусора играет свою роль в разных пространствах пула памяти.
- молодое поколение (Young Generation):включатьEdenа такжеSurvivor Spaces,а такжеSurvivor Spacesразделен наSurvivor 0а такжеSurvivor 1, иногда называемыйfromа такжеtoдва округа.
- старость (Old Generation): широко известный какTenured.
- Метапространство: называетсяMetaspace,существует
JDK[8+Постоянная генерация удаленаPermanent Generation.
Eden
Эдемский сад – это рай на земле Согласно записям «Библии, Ветхого Завета и Бытия», Бог, Иегова, создал Адама, прародителя человечества, по своему образу, а затем создал женщину Еву с ребром Адама и поместил первую пару мужчин и женщин, живущих в Эдемском саду.
Eden,也就是伊甸园,是一块普通的在创建对象的时候进行对象分配的内存区域。 а такжеEdenдалее делится на резиденциюEdenодно или несколько пространствThread Local Allocation Buffer (Thread Local Allocation Buffer, сокращенно TLAB),TLABявляется эксклюзивным для потока.JVMПозволяет потокам создавать большинство объектов непосредственно в соответствующихTLABВыделите таким образом, чтобы избежать снижения производительности, вызванного синхронизацией между несколькими потоками.
когда не в состоянииTLABПри размещении объекта в (обычно в буфере не хватает места) операция размещения объекта будет выполняться вEdenобщее место в (Common Area) в. если весьEdenнедостаточно места, он сработаетYGC (Сборка мусора молодого поколения), чтобы выпустить большеEdenпространство в. вызыватьYGCПосле этого еще не хватает памяти, тогда объект будет аллоцироваться в старости (вообще такая ситуация называетсяПродвижение по ручке, есть предпосылки).
когда сборщик мусора собираетEden, он будет проходить все относительноGC Rootsдостижимые объекты и пометить их какжитьобъект, этот этап называетсяотметкасцена.
Еще один момент, на который следует обратить внимание, заключается в том, что объекты в куче могут быть связаны между поколениями, то есть объекты в молодом поколении могут удерживаться объектами в старом поколении (Примечание: объекты в старом поколении удерживаются объектами в молодом поколении). , держите это условие вYGCВ настоящее время, если вы не просматриваете объекты в старом поколении, невозможно проанализировать, доступны ли объекты молодого поколения, содержащиеся в объектах в старом поколении, с помощью алгоритма достижимости. JVM используетCard Marking(отметка карты) решает эту проблему, и подробная реализация маркировки карт здесь не раскрывается.
После завершения этапа маркировкиEdenВсе уцелевшие объекты будут скопированы вМеста для выжившиходно из пространств. После завершения фазы репликации всеEdenСчитается пустым и может быть повторно использован для размещения большего количества других объектов. используется здесьGCалгоритм называетсяОтметить и скопироватьАлгоритм: отметьте живые объекты, затем скопируйте их вМеста для выжившиходно из пространств, обратите внимание сюдакопировать, а не перемещать.
оEdenСтолько вводится, среди которыхTLABа такжеCard MarkingдаJVMОтносительно низкоуровневая реализация в юникоде, видимо это знает.
Survivor Spaces
Survivor SpacesТакже известное как «пространство выживших», наиболее распространенное название пространства выживших —fromа такжеto. Самый важный момент: одна из двух областей в пространстве выжившего всегда пуста.
в следующий разYGCПосле срабатывания триггера свободное пространство выжившего осядет внутри объекта. Все сохранившиеся объекты в молодом поколении (в т.ч.Edenи непустойfromвыжившие объекты в области выживших), копируются вtoЗона выживших, после завершения этого процесса,toОбласть выжившего будет содержать активные объекты иfromЗона выживших будет очищена. Следующий,fromЗона выживания иtoРоль зоны выживших будет изменена, это следующий раунд.YGCОбъекты, оставшиеся в живых после срабатывания триггера, копируются вfromЗона выживания, в то время какtoЗона выживших очищается, и цикл повторяется.
После того, как процесс репликации уцелевших объектов, упомянутых выше, прошел туда и обратно между двумя оставшимися пространствами много раз, некоторые уцелевшие объекты стали «достаточно старыми» (и выжили после многократного повторения), тогда эти «более старые» объекты будут переведены в старого поколения, эти объекты будут перемещены из пространства оставшихся в живых в пространство старого поколения, а затем они будут находиться в старом поколении, пока не станут недоступными.
если объектEdenродился в и после первогоYGCвыжить и можноSurvivor SpacesЕсли он содержится, объект будет скопирован вSurvivor SpacesИ возраст субъекта установлен на 1. объект вSurvivor Spacesопыт каждый разYGCЕсли он выживет после этого, возраст объекта увеличится на 1, когда его возраст увеличится доВозрастной порог продвижения старшего поколения, то он будет повышен до старого поколения, то есть перемещен в старое поколение.Возрастной порог продвижения старшего поколенияизJVMпараметр-XX:MaxTenuringThreshold=n:
| параметры ВМ | Функция | необязательное значение | По умолчанию |
|---|---|---|---|
-XX:MaxTenuringThreshold=n |
Survivor SpacesВозрастной порог для выживших объектов, которые будут переведены в старое поколение | 1<= n <= 15 | 15 |
Стоит отметить, что:JVMустановить в-XX:MaxTenuringThresholdЗначением по умолчанию является максимальное необязательное значение, равное 15.
JVMТакже естьДинамическая оценка возраста объектафункция,JVMНе всегда требуется, чтобы возраст выжившего субъекта былMaxTenuringThresholdмогут быть отправлены в старость, если вSurvivor SpacesСумма размеров всех предметов одного возраста вSurvivor Spacesполовина, то объекты, возраст которых больше или равен этому возрасту, могут быть напрямую повышены до старости, не дожидаясь достижения возраста объектаMaxTenuringThreshold,Например:
| Типы | пропорция | возраст | действие(MaxTenuringThreshold=15) |
|---|---|---|---|
ObjectType-1 |
60% | 5 | Если следующий YGC выживет, он будет напрямую переведен в старое поколение. |
ObjectType-2 |
1% | 6 | Если следующий YGC выживет, он будет напрямую переведен в старое поколение. |
ObjectType-3 |
10% | 4 | Следующий YGC, если возраст выжившего объекта увеличивается на 1 |
Несколько ситуаций, в которых объекты вступают в старость, можно кратко обобщить:
- неоднократно
YGCСубъект выживает и достигает установленного возраста-XX:MaxTenuringThreshold=nВызывает продвижение объекта. - Продвижение объекта из-за динамической оценки возраста объекта.
- Большие объекты сразу входят в старость.Здесь большие объекты обычно относятся к объектам Java, которые требуют большого объема непрерывной памяти.Наиболее распространенным являетсяобъекты большого массиваилиочень длинная строка, потому что вполне возможно, что молодое поколение не может держать такие большие предметы.
- При недостатке места в молодом поколении старое поколение выполнит гарантию выделения места, в этом случае объекты также размещаются непосредственно в старом поколении.
Tenured
старость (Old Generation) чаще называютTenured, реализация его памяти, как правило, сложнее. Пространство старости, как правило, намного больше, чем в молодости, и объекты, переносимые в нем, как правило, не являются «мусором памяти».Сторона также показывает, что скорость восстановления объектов в старости, как правило, низкая.
старостьGCЧастота обычно ниже, чем в молодом поколении, и ожидается, что большинство объектов в старом поколении выживут.GCПосле этого выживаемость выше), поэтому алгоритм пометки и копирования не подходит для старого поколения. старостьGCАлгоритм обычно заключается в перемещении объектов для минимизации фрагментации памяти, общие правила таковы:
- пройти через
GC RootsПройдите и отметьте все достижимые объекты. - удалить все относительно
GC Rootsнедосягаемый объект. - Путем непрерывного копирования уцелевших объектов в начало пространства памяти старого поколения (то есть на один конец начального адреса) для сжатия содержимого пространства памяти старого поколения этот процесс в основном включает явное сжатие памяти, чтобы избежать чрезмерной фрагментации памяти.
Metaspace
существуетJDK8ДоJVMВ пуле памяти также определено пространство, называемое постоянным поколением (Permanent Generation), это пространство памяти в основном используется для хранения метаданных, таких какClassинформации и т. д., он также хранит другое содержимое данных, например резидентные строки (пул строковых констант). На самом деле постоянное поколение раньше давалоJavaРазработчики доставили много хлопот, потому что в большинстве случаев трудно предсказать, сколько места нужно установить постоянному поколению, потому что разработчикам также сложно предсказать конкретный размер метаданных или пула строковых констант после выделения метаданных, и т. д. Если произойдет сбой, вы столкнетесьjava.lang.OutOfMemoryError: Permgen spaceаномальный. Исключить переполнение памяти, вызванноеjava.lang.OutOfMemoryErrorИсключение, если это вызвано предпосылкой точного определения проблемы, единственным решением являетсяVMпараметр-XX:MaxPermSize=XXXXmУвеличить память постоянной генерации, но это тоже временное решение.
Поскольку такие вещи, как метаданные, непредсказуемы,JDK[8+Удалена постоянная генерация и добавлена новая область памяти.Метапространство, много других разных вещей, таких как пулы строковых констант, перемещеныJavaв куче.ClassМетаданные, такие как информация об определениях, в настоящее время загружаются непосредственно в метапространство. Метапространство — это часть локальной памяти, выделенная на машине (native memory) области памяти,Он изолирован от кучи памяти, в которой хранятся объекты Java.. По умолчанию размер метапространства ограничен только локальной памятью компьютера, которая может быть выделена дляJavaПредельное значение программы, которое может в принципе избежать добавления новых классовjava.lang.OutOfMemoryError: Permgen spaceСценарии, в которых возникают исключения.
| параметры ВМ | Функция | необязательное значение | По умолчанию |
|---|---|---|---|
XX:MetaspaceSize=Xm |
Порог инициализации для запуска FullGC при расширении Metaspace. | - | - |
XX:MaxMetaspaceSize=Ym |
Ограничение памяти Metaspace | - | близко к бесконечности |
Общие параметры ВМ, связанные с пулом памяти
- -Xmxа также-Xms
| параметры ВМ | Функция | необязательное значение | По умолчанию |
|---|---|---|---|
-Xmx |
Установить максимальный размер кучи памяти | Есть контроль нижнего предела, в зависимости от версии ВМ | - |
-Xms |
Установить минимальный размер кучи памяти | Есть контроль нижнего предела, в зависимости от версии ВМ | - |
- -Xmn,-XX:NewRatioа также-XX:SurvivorRatio
| параметры ВМ | Функция | необязательное значение | По умолчанию |
|---|---|---|---|
-Xmn |
Установите размер памяти молодого поколения | - | - |
-XX:NewRatio= |
Установите соотношение размера памяти между старым поколением и молодым поколением.Установка его на 4 означает, что молодое поколение занимает 1/5 памяти кучи. | - | 4 |
-XX:SurvivorRatio= |
Установите соотношение размера памяти Эдема и области выживших, установите значение 8, что означает от: до: Эдема = 1: 1: 8. | - | 8 |
Тип ГХ
Артикул R большой (RednaxelaFX) ответ Чжиху, на самом деле,HotSpot VMизGCВсего две категории:
-
Partial GC: то естьЧастичный GC, не собирает весьGCкуча.-
Young GC: только собиратьyoung genизGC. -
Old GC: только собиратьold genизGC, на данный момент толькоCMSизconcurrent collectionэто режим. -
Mixed GC: собрать всюyoung genи немногоold genизGC, на данный момент толькоG1Есть этот режим.
-
-
Full GC: Собрать всю кучу, включаяyoung gen,old gen,perm gen(если он существует) и так далее для всех частей схемы.
потому чтоHotSpot VMПосле многих лет развития внешний мирGCТолкование существительного запуталось, поэтому оно появилосьMinor GC,Major GCа такжеFull GC.
Minor GC
Minor GC, то есть,Minor Garbage Collection, дословно переводится как вторичная сборка мусора, его определение относительно ясное:происходит в молодом поколениисбор мусора называетсяMinor GC.Minor Garbage CollectionПри обработке происходит:
- Всегда срабатывает, когда JVM не может выделить место в памяти для нового объекта
Minor GC, обычная ситуация, напримерEdenПамять заполнена, и чем выше частота выделения объектов,Minor GCЧем выше частота возникновения. -
Minor GCВ это время объекты старого поколения игнорируются. Объекты старого поколения, на которые ссылаются объекты молодого поколения, считаютсяGC RootsНа этапе маркировки объекты старого поколения, на которые ссылаются объекты молодого поколения, просто игнорируются. -
Minor GCприведет кStop The World, который, по-видимому, приостанавливает поток приложения. в большинстве случаев,EdenБольшинство объектов можно считать мусором, и на этот раз этот мусор не будет скопирован в пространство оставшегося в живых.Minor GCВремя паузы будет очень коротким или даже незначительным. И наоборот, еслиEdenЕсть большое количество выживших объектов, которые нужно скопировать в пространство выживших, затемMinor GCВремя паузы значительно увеличится.
Основной сборщик мусора и полный сборщик мусора
Major GC(Major Garbage Collection, что дословно можно перевести как основная сборка мусора) иFull GCВ настоящее время существует два термина, не имеющих формального определения, а именно:JVMНе ясно определено в спецификации или в исследовательской работе по сбору мусора.Major GCилиFull GC. Однако, согласно народным или общепринятым правилам, разница между ними заключается в следующем:
- Major GC: Сборка мусора для старого поколения.
- Full GC: Сборка мусора всей кучи -- включая молодое и старое поколения.
Фактически,GCПроцесс очень сложный, многиеMajor GCвсе поMinor GCСработало, поэтому должно быть строго разделеноMajor GCилиMinor GCпочти невозможно. С другой стороны, теперь алгоритмы сборки мусора вродеG1Алгоритм сбора предоставляет возможности частичной сборки мусора, дополнительные примечания иТип ГК нельзя разделить просто по тому, какая площадь собирается.
Некоторые из приведенных выше теорий или данных указывают на то, что:Вместо того, чтобы обсуждать или беспокоиться о том, является ли сборщик мусора основным или вспомогательным, лучше уделить больше внимания тому, приведет ли процесс сборки мусора к приостановке потока приложения или может ли процесс сборки мусора выполняться одновременно с потоком приложения. ..
Общие алгоритмы GC
Давайте проанализируем текущийHotspot VMБолее распространенный алгоритм GC в , поскольку алгоритм G1 относительно сложен, здесь нет возможности его анализировать.
Назначение алгоритма GC
GCАлгоритм преследует две основные цели:
- Найдите все уцелевшие предметы и отметьте их.
- Удалите все бесполезные предметы.
Поиск уцелевших объектов в основном основан наGC RootsАлгоритм достижимости , есть несколько вещей, которые следует отметить на этапе маркировки:
- Марка фазы остановится все потоки приложения (то есть,Stop The World), поток приложения временно приостанавливается, чтобы сохранить информацию в точке восстановления (Safepoint)середина.
- Продолжительность фазы маркировки зависит не от общего количества объектов в куче или от размера кучи, а от общего количества живых объектов, поэтому увеличение размера кучи не оказывает существенного влияния на продолжительность кучи. этап маркировки.
Следующим этапом после завершения этапа маркировки является удаление всех бесполезных объектов, которые делятся на три общих алгоритма по методу обработки:
-
Sweep-- убираться, т.
Mark and Sweep, разметка-очистка. -
Compact-- Сжатие, т.
Mark-Sweep-Compact, пометить-очистить-сжать. -
Copy-- копировать, т.
Mark and Copy, пометить-копировать.
Алгоритм маркировки-развертки
Mark-Sweepалгоритм, то естьчистыйалгоритм, который является алгоритмом косвенной переработки (Indirect Collection), он не обнаруживает непосредственно сам объект мусора, а сначала определяет все уцелевшие объекты, а затем судит, что другие объекты в свою очередь являются объектами мусора. Он в основном включает два этапа маркировки и очистки.Это самый простой и базовый алгоритм сбора.В основном он включает два этапа:
- Первый этап - отслеживание (trace) стадия: сборщик начинается с
GC RootsНачните обход всех доступных объектов и отметьте эти уцелевшие объекты (mark). - Второй этап - зачистка(sweep) фаза: Сборщик очищает и перерабатывает все немаркированные объекты.
Алгоритм Mark-Sweep-Compact
Фрагментация памяти — одна из проблем, которую не может решить алгоритм неподвижной коллекции: хотя в куче есть доступное пространство, диспетчер памяти не может найти непрерывный блок памяти, чтобы удовлетворить потребности в распределении больших объектов, или это занимает много времени. время, чтобы найти соответствующее свободное место в памяти.
Mark-Sweep-Compactалгоритм, то естьпометить-очистить-сжатьалгоритм, который также является алгоритмом косвенной переработки (Indirect Collection), который в основном включает три этапа:
- Фаза маркировки: сборщик из
GC RootsНачните обход всех доступных объектов и отметьте те уцелевшие объекты. - Фаза очистки: сборщик очищает и перерабатывает все немаркированные объекты.
- Фаза уплотнения: сборщик перемещает все активные объекты в начало памяти кучи, а затем очищает пространство памяти за пределами конечной границы.
Сжатие и дефрагментация динамической памяти может эффективно уменьшить внешнюю фрагментацию памяти (External Fragmentation) проблема, этопометить-очистить-сжатьОдно преимущество алгоритма.
Алгоритм маркировки-копирования
Mark-Copyалгоритм, то естьотметка-копияАлгоритм очень похож на алгоритм пометки-очистки-уплотнения с одним важным отличием: после завершения алгоритма пометки-и-очистки все уцелевшие объекты копируются в другую область памяти — оставшееся пространство. В основном включает три этапа:
- Фаза маркировки: сборщик из
GC RootsНачните обход всех доступных объектов и отметьте те уцелевшие объекты. - Этап очистки: сборщик очищает и перерабатывает все немаркированные объекты ---На самом деле этого шага может и не быть, потому что после копирования указателя уцелевшего объекта местоположение исходного указателя уже может быть перераспределено с новым объектом, поэтому очищать его не нужно..
- Этап копирования: скопируйте все уцелевшие объекты вSurvivor Spacesв определенном пространстве.
Алгоритм пометки-копии позволяет избежать проблемы фрагментации памяти, но его стоимость относительно высока, поскольку используется копирование и восстановление половинной области, а доступная память области составляет половину исходной.
резюме
JVMа такжеGCдаJavaЗнаний, которыми должны овладеть разработчики, на самом деле довольно много, в этой статье лишь кратко представлены некоторые основные понятия:
- Поколенческая гипотеза.
-
Minor GC,Major GCа такжеFull GC. -
JVMВ пулах памяти. - общий
GCалгоритм.
позже проанализируюGCколлекционное словосочетание иGCпросмотр журнала,JVMпредоставленный инструмент и т.
Использованная литература:
- "Углубленное понимание виртуальной машины Java-3rd"
- «Справочник по сбору мусора»
- Знай - RednaxelaFX часть ответа
-
OpenJDK HotSpot VMЧасть исходного кода
(Конец этой статьи e-a-20190609 r-a-20200720)