Сериен GC
Събирането на боклук подобрява ефективността на паметта в Java, като премахва нереферирани обекти от купчината и освобождава място за новосъздадени обекти.
Виртуалната машина на Java има осем вида събирачи на отпадъци. Нека разгледаме всеки от тях подробно.
Серийният GC е най-простата реализация на GC. Предназначен е за малки applications, работещи в еднонишкови среди. Всички събития за събиране на отпадъци се изпълняват последователно в една и съща нишка. Уплътняването се извършва след всяко сметоизвозване.
Стартирането на колектора води до събитие "световно спиране", при което цялото приложение е спряно. Тъй като цялото приложение е замразено по време на събирането на боклука, не трябва да прибягвате до това в реалния живот, ако искате да запазите забавянията възможно най-ниски.
Аргументът на JVM за използване на серийния събирач на отпадъци е -XX:+UseSerialGC .
Паралелен GC
Паралелният събирач на отпадъци е предназначен за applications със средни до големи набори от данни, които работят на многонишков or многопроцесорен хардуер. Това е изпълнението на GC по подразбиране и е известно също като колектор на пропускателна способност.
Няколко нишки са предназначени за събиране на малки боклуци в младото поколение. Единствената нишка е заета с основното събиране на боклука в по-старото поколение.
Изпълнението на паралелен GC също кара света да „спира“ и приложението виси. Това поведение е по-подходящо за многонишкова среда, където трябва да бъдат изпълнени много задачи и са допустими дълги паузи, като например при изпълнение на пакетно задание.
Аргументът на JVM за използване на паралелния събирач на отпадъци е -XX:+UseParallelGC .
CMS GC
Известен ни също като паралелен пикер с ниска почивка .
Тук за малко събиране на боклук участват няколко нишки, това се случва чрез същия алгоритъм като в паралелния колектор. Основното събиране на боклук е многонишково, точно като стария паралелен GC, но CMS работи едновременно с процесите на приложението, за да минимизира събитията „спиране на света“.
Поради това CMS колекторът консумира повече CPU от другите колектори. Ако имате възможност да разпределите повече CPU за подобряване на производителността, тогава CMS е за предпочитане пред обикновен паралелен колектор. CMS GC не се уплътнява.
Аргументът на JVM за използване на колектора за боклук с паралелно маркиране и почистване е -XX:+UseConcMarkSweepGC .
G1 (Първо боклук) GC
G1GC е замислен като заместител на CMS и е разработен за многонишкови applications, които се характеризират с големи размери на купчина (повече от 4 GB). Той е паралелен и конкурентен като CMS, но под капака работи много по-различно от старите събирачи на отпадъци.
Въпреки че G1 също работи на база поколения, той няма отделни пространства за по-младите и по-възрастните поколения. Вместо това всяко поколение е набор от региони, което позволява гъвкавост при промяна на размера на по-младото поколение.
G1 разделя купчината на набор от региони с еднакъв размер (в зависимост от размера на купчината) и ги сканира в множество нишки. Районът по време на изпълнение на програмата може многократно да стане Howто стар, така и млад.
След като фазата на маркиране приключи, G1 знае кои области съдържат най-много боклуци. Ако потребителят се интересува от минимизиране на паузите, G1 може да избере само няколко области. Ако времето за пауза не е важно за потребителя or ако ограничението за време за пауза е настроено на високо, G1 ще премине през повече области.
Тъй като G1 GC идентифицира регионите с най-много боклук и първо извършва събиране на боклук в тези региони, той се нарича „Garbage First“.
В допълнение към областите Eden, Survivors и Old Memory, в G1GC има още два типа.
- Humongous (Huge) - за обекти с големи размери (повече от 50% от размера на купчината).
- Налично - неизползвано or неразпределено пространство.
Аргументът на JVM за използване на G1 събирача на отпадъци е -XX:+UseG1GC .
Шенандоа (Шандара)
Shenandoah е нов GC, пуснат като част от JDK 12. Ключовото предимство на Shenandoah пред G1 е, че по-голямата част от цикъла на събиране на отпадъци се извършва едновременно с нишките на приложението. G1 може да евакуира области на купчина само когато приложението е спряно, докато Shenandoah премества обекти едновременно с приложението.
Shenandoah може да компактира живи обекти, да почиства боклука и да освобождава RAM почти веднага щом се намери свободна памет. Тъй като всичко това се случва по едно и също време, без да спира приложението, Shenandoah е по-интензивен на процесора.
ZGC
ZGC е друг GC, издаден като част от JDK 11 и подобрен в JDK 12.
Предназначен е за applications, които изискват скорост и ниска латентност (паузи под 10 ms) и/or използват много голяма купчина (няколко тераbyteа).
Основните цели на ZGC са ниска латентност, мащабируемост и лекота на използване. За да направи това, той позволява на приложението Java да продължи да работи въпреки факта, че се извършват операции по събиране на боклук. По подразбиране ZGC освобождава неизползваната памет и я връща на операционната система.
По този начин ZGC носи значително подобрение в сравнение с други традиционни GC, като осигурява изключително ниски мъртви времена (обикновено в рамките на 2 ms).
Аргументът на JVM за използване на ZGC събирача на отпадъци е -XX:+UnlockExperimentalVMOptions -XX:+UseZGC .