1. Значение механизма переработки мусора
Примечательной особенностью языка Java является внедрение механизма сбора мусора, который решает самую сложную задачу управления памятью для программистов C++, так что программистам Java больше не нужно учитывать управление памятью при написании программ. Из-за механизма сбора мусора объекты в Java больше не имеют понятия «область объёма», только ссылка на объект имеет «область действия».Сборка мусора эффективно предотвращает утечку памяти и эффективно использует свободную память.
ps:内存泄露是指该内存空间使用完毕之后未回收，在不涉及复杂数据结构的一般情况下，Java 的内存泄露表现为一个内存对象的生命周期超出了程序需要它的时间长度，我们有时也将其称为“对象游离”。
2. Алгоритмы в механизмах сбора мусора
Спецификация языка Java явно не указывает, какой алгоритм сбора мусора использовать в JVM, но любой алгоритм сбора мусора обычно должен выполнять две основные задачи: (1) находить бесполезные информационные объекты; (2) Вернуть пространство памяти, занятое бесполезными объектами, чтобы программа могла использовать это пространство снова.
1. Сборщик счёта справок
1.1 Анализ алгоритмов
Подсчёт ссылок — одна из первых стратегий в сборщиках мусора. В этом подходе для каждого экземпляра объекта в куче существует счёт ссылок. Когда объект создан и экземпляр объекта назначен переменной, количество переменных устанавливается равным 1. Когда любая другая переменная назначается в качестве ссылки на этот объект, счётчик добавляется на 1 (a = b, тогда счётчик объекта, на который ссылается b, равен +1), но если ссылка на экземпляр объекта превысила свой срок службы или установлена на новое значение, счётчик объекта вычитается на 1. Любой экземпляр объекта с счётчиком отсылок 0 может быть собран как мусор. Когда экземпляр объекта — это сбор мусора, счётчик ссылок любого объекта, на который он ссылается, равен минус 1.
1.2 Преимущества и недостатки
Заслуга:
Сборник ссылочного количества можно очень быстро запустить, интегрируя его в работу программы. Это преимущество для сред реального времени, где программы не требуют длительного прерывания.
Недостаток:
Круговые ссылки не обнаружились. *Если родительский объект имеет ссылку на дочерний объект, дочерний объект, в свою очередь, ссылается на родительский объект. Таким образом, их количество цитат никогда не может быть равным 0.
1.3 Алгоритм подсчёта ссылок не может решить задачу кругового счёта, например:
/** * Java学习交流QQ群：589809992 我们一起学Java！ */public class Main { public static void main(String[] args) { MyObject object1 = new MyObject(); MyObject object2 = new MyObject(); object1.object = object2; object2.object = object1; object1 = null; object2 = null; }}
Последние два предложения присваивают объекты 1 и объект 2 в null, что означает, что объекты, на которые указывают объекты 1 и объект 2, больше недоступны, но поскольку они ссылаются друг на друга, их счётчики ссылок не равны 0, поэтому сборщик мусора никогда не будет их перерабатывать.
2. Алгоритм трассирующего сборника или маркировки и очистки
2.1 Алгоритм поиска по корням
![]()
Алгоритм корневой поиска введён из теории графов в дискретной математике: программа рассматривает все опорные отношения как граф, начиная с узла GC ROOT, ища соответствующий опорный узел, после нахождения этого узла, продолжая поиск опорного узла этого узла, при поиске всех опорных узлов остальные узлы считаются нереферентными, то есть бесполезными узлами.
java, который можно использовать как GC Root
1. Объекты, на которые ссылаются в стеке виртуальной машины (таблица локальных переменных)
2. Объект, на который ссылается статический атрибут в области метода
3. Объект, на который ссылается константа в области метода
4. Ссылки на объекты в локальном стеке методов (нативные объекты)
2.2 Схематическая диаграмма алгоритма трассировки
![]()
2.3 Анализ алгоритма очистки маркеров
Алгоритм очистки тегов сканирует корневую коллекцию, отмечает сохранившиеся объекты, а затем сканирует всё пространство в поисках неотмеченных объектов для переработки, как показано на рисунке выше. Алгоритм очистки тегов не требует перемещения объектов и обрабатывает только невыжившие объекты, что чрезвычайно эффективно при большом количестве сохранившихся объектов, но поскольку алгоритм очистки тегов напрямую перерабатывает невыжившие объекты, это приводит к фрагментации памяти.
3. Алгоритм компактирования или алгоритма завершения меток
![]()
Алгоритм завершения тегов использует тот же метод, что и алгоритм очистки тегов, для маркировки объектов, но при очистке он отличается: после восстановления пространства, занятого нежившими объектами, все выжившие объекты перемещаются в свободное пространство на левом конце и обновляются соответствующие указатели. Алгоритм finish tag-finish основан на алгоритме очистки тегов и перемещает объекты, поэтому он дороже, но решает проблему фрагментации памяти. В реализации коллекторов на основе алгоритма компактирования обычно добавляются таблицы handles и handles.
4. Алгоритм копирования (компактирующий коллектор)
![]()
Алгоритм предлагается для преодоления накладных расходов ручки и решения проблемы с сбором мусора из кучи. Когда объект заполнен, сборка мусора, основанная на алгоритме копирования, сканирует активный объект из корневого множества и копирует каждый активный объект на свободную грань (чтобы между памятью, занятой активным объектом, не было свободных дыр), так что свободная поверхность становится гранью объекта, исходная грань объекта — свободной, а программа выделяет память в новой грани объекта. Типичный сборник мусора, основанный на алгоритме копирования, — это алгоритм stop-and-copy, который делит кучу на грани объектов и свободные области, а выполнение программы останавливают при переключении между гранями объектов и свободными областями.
5. Поколенческий коллекционер
![]()
Поколенческая стратегия переработки мусора основана на том, чтоЖизненный цикл разных объектов отличается。 Таким образом, объекты с разным жизненным циклом могут использовать разные алгоритмы переработки для повышения эффективности переработки.
Молодое поколение
1. Все новые объекты сначала помещаются в молодое поколение. Цель молодого поколения — как можно быстрее собирать предметы с коротким жизненным циклом.
2. Память нового поколения разделена на один регион Эдем и две зоны выживших (выживший0, выживший1) по соотношению 8:1:1. Одна зона Эдема, две зоны выживших (в целом). Большинство объектов появляются в районе Эдема. Когда область выжившего0 тоже заполнена, область Эдема и область выжившего 0 копируются в другую область выжившего1, затем Эдем и Выжившее0 опустошаются, затем область Выжившего0 опустошается, а затем Выжившая0 и Survivor1 меняются. То есть оставлять область Survivor1 пустой и так далее.
3. Когда область Выжившего 1 недостаточно для хранения сохранившихся объектов Эдема и Выжившего0, оставшиеся объекты хранятся напрямую в старую эпоху. Если старость тоже наполнена, это вызовет полный ГК, то есть новое поколение, и старое поколение будет перерабатываться
4. ГК нового поколения также называется Малым ГК, и частота Малого ГК относительно высока (она не обязательно активируется, когда район Эдем заполнен)
Старое поколение
1. Объекты, которые остались живы после пережития переработки мусора азота у молодого поколения, будут относиться к старшему. Поэтому можно считать, что старое поколение хранится в некоторых объектах с длительным жизненным циклом.
2. Память также значительно больше, чем у нового поколения (приблизительное соотношение 1:2), когда память старости заполнена, активируется Major GC, то есть Full GC, частота Full GC относительно низкая, время выживания объекта старости относительно долгое, а уровень выживаемости высок.
Постоянное поколение
Используется для хранения статических файлов, таких как классы Java, методы и т. д. Постоянные генерации не оказывают значительного влияния на сбор мусора, но некоторые приложения могут динамически генерировать или вызывать классы, такие как Hibernate и т.д., и в этом случае необходимо настроить относительно большое пространство для хранения этих новых классов во время выполнения.
3. ГК (мусорщик)Коллекционеры, используемые коллекционерами нового поколения: Serial, PraNew, Parallel Scavenge
Коллекционеры, используемые коллекционерами старости: Serial Old, Parallel Old, CMS
![]()
Серийный коллектор (алгоритм репликации)
Новое поколение однопоточных коллекторов, маркировки и очистки являются однопоточными, с преимуществом простоты и эффективности.
Serial Old Collector (алгоритм отделки этикетки)
Старинный коллекционер с одной нитью, старинная версия серийного коллекционера.
Коллектор ParNew (алгоритм стоп-копирования)
Новое поколение коллектора можно считать многопоточной версией Serial Collector, которая обладает лучшей производительностью, чем Serial в многоядерной среде процессора.
Parallel Scavenge Collector (алгоритм стоп-копирования)
Параллельные коллекторы для высокой пропускной способности и эффективного использования процессора. Пропускная способность обычно составляет 99%, а пропускная способность = пользовательское время потока / (пользовательское время потока + время потока GC). Он подходит для сценариев, таких как фоновые приложения, не требующие соответственно высокого взаимодействия.
Параллельный старый коллектор (алгоритм стоп-копирования)
Старая версия коллектора Parallel Scavenge — параллельный коллектор с приоритетом пропускной способности
Коллектор CMS (Concurrent Mark Sweep) (алгоритм очистки маркировки)
Высокая параллельность, низкая пауза, стремление к самому короткому времени паузы восстановления GC, высокого использования процессора, быстрого отклика, короткого времени паузы и многоядерных процессоров с высоким временем отклика
4. Механизм реализации ГКПоскольку объект обрабатывался в разных поколениях, площадь и время сбора мусора также различаются. Существует два типа GC: Scavenge GC и Full GC.
Сборщик ГК
Обычно, когда генерируется новый объект и он не подаёт заявку на место в Эдеме, срабатывает GC Scavenge GC, который обрабатывает область Эдема, очищает невыжившие объекты и перемещает оставшиеся объекты в область выживших. Затем разберите две зоны Survivor. Таким образом ГК проводится в районе Эдем для молодого поколения и не влияет на старшее поколение. Поскольку большинство объектов начинаются из района Эдема, а зона Эдема выделяется немного, ГК района Эдем проводится часто. Поэтому здесь обычно необходимо использовать быстрые и эффективные алгоритмы, чтобы сделать Эдем свободным как можно скорее.
Полный GC
Организуйте всю стопку, включая Young, Tenured и Perm. Full GC медленнее Scavenge GC, потому что требует переработки всей кучи, поэтому количество Full GC следует сократить как можно больше. Большая часть процесса настройки JVM — это настройка FullGC. Полный ГК может быть вызван по следующим причинам:
1. Tenured написано полностью
2. Перм пишется полностью
3. System.gc() отображается как вызов
4. Стратегия распределения доменов в куче динамически меняется после последнего GC
5. Java с GC также будет иметь проблемы с утечкой памяти1. Использование статических классов коллекций, таких как HashMap, Vector и др., наиболее подвержено утечке памяти, и жизненный цикл этих статических переменных совпадает с жизненным циклом приложения, и все объекты не могут быть освобождены, поскольку они всегда будут применяться Vector и другими.
Статический вектор v = новый вектор(); для (int i = 1; i<100; i++) { Объект o = новый объект(); v.add(o); o = null; }
В этом примере есть ссылка v для объекта вектора и ссылка o для объекта объекта в стеке кода. В цикле For мы продолжаем генерировать новые объекты, затем добавляем их к объекту Vector и затем аннулируем ссылку на o. Вопрос в том, когда ссылка на o аннулируется, если возникает GC, может ли созданный нами объект объекта быть повторно использован GC? Мой ответ – нет. Потому что когда GC отслеживает ссылки в стеке кода, он находит v ссылки, и если продолжать трассировку, вы обнаружите, что в памяти, на которое указывают v ссылки, есть ссылки на объекты объектов. Это означает, что даже несмотря на то, что ссылка o была опустошена, существуют другие ссылки на объект объекта, к которым можно получить доступ, поэтому GC не может их освободить. Если после этого цикла объект Object не влияет на программу, то предполагается, что в Java-программе произошла утечка памяти.
2. Различные соединения, базы данных, сетевые соединения, ввод-выводы и т.д. не отображают вызов близко к закрытию и не перерабатываются GC, что приводит к утечке памяти.
3. Использование слушателей также может привести к утечке памяти, если слушатель не удаляется при выпуске объекта.
|
Опубликовано 04.12.2017 20:26:51
|
|
|
