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, което означава, че обектите, посочени от object1 и object2, вече не могат да бъдат достъпени, но тъй като се отнасят един към друг, техните референтни броячи не са 0, така че събирачът на боклук никога няма да ги рециклира.
2. Алгоритъм за проследяване на колектор или маркиране и почистване
2.1 Алгоритъм за търсене на корени
![]()
Алгоритъмът за търсене на корени е въведен от теорията на графите в дискретната математика; програмата разглежда всички референтни връзки като граф, започвайки от възел GC ROOT, търсейки съответния референтен възел, след като намери този възел, продължавайки да търси референтния възел на този възел, когато всички референтни възли бъдат претърсени, останалите възли се считат за нереферирани възли, тоест безполезни възли.
java, която може да се използва като GC Root
1. Обекти, реферирани в стека на виртуалната машина (таблица с локални променливи)
2. Обектът, рефериран от статичния атрибут в областта на метода
3. Обектът, рефериран от константата в областта на метода
4. Реферирани обекти в локалния стек на методите (Native Objects)
2.2 Схематична диаграма на алгоритъма за проследяване
![]()
2.3 Анализ на алгоритъма за изчистване на маркери
Алгоритъмът за изчистване на тагове сканира от кореновата колекция, маркира оцелелите обекти и след това сканира цялото пространство за рециклиране на немаркирани обекти, както е показано на горната фигура. Алгоритъмът за изчистване на тагове не е необходимо да мести обекти и обработва само неоцелели обекти, което е изключително ефективно, когато има много оцелели обекти, но тъй като алгоритъмът за почистване на тагове директно рециклира неоцелели обекти, това ще причини фрагментация на паметта.
3. Алгоритъм за компактиране или алгоритъм за завършване на етикети
![]()
Алгоритъмът tag-finish използва същия метод като алгоритъма за изчистване на тагове за етикетиране на обекти, но е различно при изчистване, след като се възстанови пространството, заето от несъществуващи обекти, всички оцелели обекти се преместват в свободното пространство в левия край и се актуализира съответният указател. Алгоритъмът за завършване на тагова е базиран на алгоритъма за изчистване на тагове и премества обекти, затова е по-скъп, но решава проблема с фрагментацията на паметта. При реализацията на колектори, базирани на алгоритъма за компактиране, обикновено се добавят таблици с handles и handles.
4. Алгоритъм за копиране (компактиращ колектор)
![]()
Алгоритъмът е предложен да преодолее натоварването на дръжката и да реши събирането на отпадъци от купчина. Когато обектът е пълен, събирането на боклук, базирано на алгоритъма за копиране, сканира активния обект от кореновото множество и копира всеки активен обект на свободното лице (така че да няма свободни дупки между паметта, заета от активния обект), така че свободната повърхност да стане лицето на обекта, оригиналното лице на обекта – свободното лице, а програмата да разпределя паметта в новото лице на обекта. Типично събиране на боклук, базирано на алгоритъма за копиране, е алгоритъмът за спиране и копиране, който разделя купчината на обектни лица и свободни площи, а програмата спира изпълнението по време на превключване между обектни лица и свободни области.
5. Колекционер на поколенията
![]()
Поколенческата стратегия за рециклиране на отпадъци се основава на факта, чеЖизненият цикъл на различните обекти е различен。 Затова обекти с различен жизнен цикъл могат да използват различни алгоритми за рециклиране, за да подобрят ефективността на рециклирането.
Младо поколение
1. Всички новогенерирани обекти се поставят първо в по-младото поколение. Целта на по-младото поколение е да събира тези предмети с кратък жизнен цикъл възможно най-бързо.
2. Паметта от новото поколение е разделена на един регион Едем и две зони за оцелели (оцелели0, оцелял1) според съотношението 8:1:1. Една зона на Едем, две зони за оцеляване (като цяло). Повечето обекти се появяват в района на Едем. Когато зоната на survivor0 също е пълна, областта на Eden и областта на survivor 0 се копират в друга област на survivor1, след което областта на Eden и Survivor0 се изпразват, след което зоната на survivor0 остава празна, след което областта Survivor0 и Survivor1 се разменят. Тоест, оставете зоната на Survivor1 празна и така нататък.
3. Когато зоната на Survivor 1 не е достатъчна, за да съхранява оцелелите предмети от Eden и Survivor0, оцелелите обекти се съхраняват директно в старата епоха. Ако старостта също е пълна, това ще задейства пълен ГК, тоест новото поколение, а старото поколение ще бъде рециклирано
4. ГК от новото поколение се нарича още Малка ГК, а честотата на МинорГГ е сравнително висока (не е задължително да се задейства, когато районът на Едем е пълен)
Старо поколение
1. Обекти, които са все още живи след преживяване на рециклиране на отпадъци с азот в по-младото поколение, ще бъдат поставени в по-старото поколение. Следователно може да се счита, че старото поколение се съхранява в някои обекти с дълъг жизнен цикъл.
2. Паметта е също много по-голяма от тази на новото поколение (приблизителното съотношение е 1:2), когато паметта за старостта е пълна, се задейства Major GC, тоест Full GC, честотата на Full GC е сравнително ниска, времето за оцеляване на обекта в старостта е сравнително дълго, а процентът на оцеляване е висок.
Постоянно поколение
Използва се за съхранение на статични файлове, като Java класове, методи и др. Постоянните поколения нямат значително влияние върху събирането на отпадъци, но някои приложения могат динамично да генерират или извикват някои класове, като Hibernate и др., и в този случай трябва да се зададе сравнително голямо постоянно пространство за генериране, за да съхранява тези нови класове по време на изпълнение.
3. GC (Събирач на боклук)Колекционери, използвани от новото поколение колекционери: Serial, PraNew, Parallel Scavenge
Колекционери, използвани от колекционери на стари възрасти: Serial Old, Parallel Old, CMS
![]()
Сериен колектор (алгоритъм за репликация)
Новото поколение еднорезови колектори, маркиране и почистване, са еднорезбови, с предимството да са прости и ефективни.
Сериен стар колектор (алгоритъм за етикетно покритие)
Колекционер с единична нишка за възрастни години, версия на серийния колекционер.
ParNew колектор (алгоритъм за спиране на копиране)
Новото поколение колектор може да се счита за многопоточна версия на серийния колектор, който има по-добра производителност от Serial в многоядрена CPU среда.
Паралелен събирач на събиране на отпадъци (Алгоритъм за спиране-копиране)
Паралелни колектори за висока пропускателна способност и ефективно използване на процесора. Пропускателната способност обикновено е 99%, а пропускателната способност = потребителско време на нишка / (потребителско време на нишка + време за GC нишка). Подходящо е за ситуации като фонови приложения, които не изискват съответно високо взаимодействие.
Паралелен стар колектор (алгоритъм за спиране-копиране)
По-стара версия на Parallel Scavenge колектор, паралелен колектор, с приоритет на пропускателната способност
CMS (Concurrent Mark Sweep) колектор (алгоритъм Mark-Clean)
Висока паралелност, ниска пауза, преследване на най-кратко време за пауза за възстановяване на GC, висока употреба на процесора, бързо време за реакция, кратко време за пауза и многоядрен процесор с високо време за реакция
4. Механизъм за прилагане на GCТъй като обектът е обработван в различни поколения, площта и времето на събиране на боклука също са различни. Има два вида GC: Scavenge GC и Full GC.
Scavenge GC
Обикновено, когато се генерира нов обект и не кандидатства за място в Едем, се задейства Scavenge GC, който GC на Едем зоната, изчиства нецелелите обекти и премества оцелелите в зоната за оцелели. След това определете двете зони на Survivor. ГК по този начин се извършва в района на Едем за по-младото поколение и не засяга по-старото поколение. Тъй като повечето обекти започват от района на Едем, а районът Идем не е разпределен много, GC на района Идем се извършва често. Затова обикновено е необходимо да се използват бързи и ефективни алгоритми, за да се направи Едем свободен възможно най-скоро.
Пълен GC
Организирайте цялата купчина, включително Young, Tenured и Perm. Пълният GC е по-бавен от Scavenge GC, защото изисква рециклиране на цялата купчина, така че броят на пълните GC трябва да се намали колкото е възможно. Голяма част от процеса на настройка на JVM е настройката на FullGC. Пълният GC може да бъде причинен от следните причини:
1. Постоянен договор се пише изцяло
2. Перм се изписва изцяло
3. System.gc() се показва като повикване
4. Стратегията за разпределение на домейни в Heap се променя динамично след последната GC
5. Java с GC също ще има проблеми с изтичане на памет1. Използването на класове за статична колекция като HashMap, Vector и др. е най-податливо на изтичане на памет, а жизненият цикъл на тези статични променливи е същият като на приложението, и всички обекти не могат да бъдат освободени, защото винаги ще бъдат приложени от Vector и други.
Статичен вектор v = нов вектор(); за (int i = 1; i<100; i++) { Обект o = нов Обект(); v.add(o); o = null; }
В този пример има референция v за векторния обект и референция o за обекта Object в стека с код. В цикъла For продължаваме да генерираме нови обекти, след което ги добавяме към обекта Vector и след това неутрализираме o референцията. Въпросът е, когато o референцията е анулирана, ако възникне GC, може ли обектът Object, който сме създали, да бъде рециклиран от GC? Отговорът е не. Защото когато GC проследява препратки в стека с код, намира v референции, и ако продължиш да проследяваш надолу, ще откриеш, че има препратки към обектни обекти в паметта, към която са посочени v референции. Това означава, че въпреки че o референцията е изпразнена, все още има други препратки към обекта Object, които могат да бъдат достъпени, така че GC не може да ги освободи. Ако след този цикъл обектът Object няма ефект върху програмата, тогава приемаме, че Java програмата има изтичане на памет.
2. Различни връзки, бази данни, мрежови връзки, входни връзки и др. не показват разговора близо до затваряне и не се рециклират от GC, което води до изтичане на памет.
3. Използването на слушатели може също да причини изтичане на памет, когато слушателят не се изтрива при освобождаването на обекта.
|
Публикувано в 4.12.2017 г. 20:26:51 ч.
|
|
|
