Оптимизация JVM — графическая сборка мусора

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

Перед настройкой мы должны понять принцип его работы.Сборщик мусора в Java Garbage Collection обычно называется "GC".Он родился в языке MIT Lisp в 1960. Спустя более полувека, он сейчас очень зрелый. Поэтому в этой статье основное внимание уделяется этим трем аспектам:

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

1. Счетчик программы

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

2. Стек виртуальных машин

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

3. Стек локальных методов

Стек собственных методов, аналогичный стеку виртуальной машины, вызывает собственные методы.

4. Куча

Куча — это самая большая часть управляемой памяти в JVM. Он является общим и содержит экземпляры объектов. Также известен как «куча gc». Основная зона управления сбором мусора

5. Область метода

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

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

Зная, кто должен управлять памятью и этими областями, мне также нужно знать, когда производить сборку мусора в этих областях.

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

Добавьте счетчик ссылок к объекту.Всякий раз, когда есть место для ссылки на него, счетчик равен +1, а когда ссылка недействительна, счетчик равен -1.Объект, счетчик которого в любое время равен 0, невозможно используется снова.

Через ряд объектов, называемых «GC Roots» в качестве отправной точки, поиск начинается с этих узлов, а путь, пройденный поиском, называется цепочкой ссылок.Когда объект не связан с GCRoots какой-либо цепочкой ссылок, он доказано, что этот Объект недоступен.

Например, объект справа становится недостижимым, когда он достигает GCRoot, и может быть определен как объект, пригодный для повторного использования.

В Java вы можете использовать объекты gcroot, включая следующие:

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

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

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

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

1. Object1 вновь создан и родился в районе Эдена нового поколения.

2. Минорный GC, object1 все еще жив и перемещен в пространство Fromsuvivor, которое на данный момент все еще находится в новом поколении.

3. Незначительный GC, объект1 еще жив, в это время объект1 будет перемещен в зону ToSuv через алгоритм репликации, а возраст объекта1 в это время +1.

4. Незначительный GC, объект1 еще жив.В это время объекты того же возраста, что и объект1 в выжившем, не достигают половины выжившего.Поэтому области fromSuv и Tosuv обмениваются через алгоритм репликации в это время, а уцелевшие объекты перемещаются в Тосув.

5. Малый GC, объект 1 все еще жив.В это время объекты того же возраста, что и объект 1 в выжившем, достигли более половины выжившего (область toSuv заполнена), а объект 1 перемещен в область старости .

6. После того, как объект 1 выживает в течение определенного периода времени, обнаруживается, что объект 1 не может достичь GcRoots в это время, и коэффициент пространства старого возраста превысил пороговое значение в это время, вызывая основной GC (его также можно рассматривать как полный GC , но для контакта требуется сборщик мусора), в это время объект1 был переработан. fullGC вызовет остановку мира.

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

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

Метод пометки и очистки является идеологической основой алгоритма сборки мусора. Алгоритм маркировки и очистки делит мусор на две фазы: фазу маркировки и фазу очистки.

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

На этапе очистки удаляются все неотмеченные объекты.

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

Алгоритм сжатия токенов — это устаревший алгоритм повторного использования.

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

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

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

Преимущества и недостатки различных комбинаций:

Вышеуказанные преимущества и недостатки обусловлены:www.importnew.com/23752.html

Уделяйте внимание исследованиям и разработкам игр и стремитесь продвигать прогресс внутреннего игрового сообщества Добро пожаловать, чтобы обратить внимание на мой публичный аккаунт: Да Ма Хоу (cool_wier)