Serial GC
Ang pagkolekta ng basura ay nagpapabuti sa kahusayan ng memorya sa Java sa pamamagitan ng pag-alis ng mga hindi na-reference na bagay mula sa heap at paggawa ng puwang para sa mga bagong likhang bagay.
Ang Java virtual machine ay may walong uri ng mga basurero. Isaalang-alang natin ang bawat isa sa kanila nang detalyado.
Ang Serial GC ay ang pinakasimpleng pagpapatupad ng GC. Ito ay inilaan para sa maliliit na application na tumatakbo sa mga single-threaded na kapaligiran. Ang lahat ng mga kaganapan sa pangongolekta ng basura ay isinasagawa nang sunud-sunod sa parehong thread. Ginagawa ang compaction pagkatapos ng bawat koleksyon ng basura.
Ang pagpapatakbo sa collector ay nagreresulta sa isang "world stop" na kaganapan, kung saan ang buong aplikasyon ay nasuspinde. Dahil ang buong application ay nagyelo sa panahon ng pagkolekta ng basura, hindi mo dapat gamitin ito sa totoong buhay kung gusto mong panatilihing mababa ang mga pagkaantala hangga't maaari.
Ang argumento ng JVM para gamitin ang serial garbage collector ay -XX:+UseSerialGC .
Parallel GC
Ang parallel garbage collector ay idinisenyo para sa mga application na may medium hanggang malalaking data set na tumatakbo sa multithreaded o multiprocessor hardware. Ito ang default na pagpapatupad ng GC at kilala rin bilang throughput collector.
Maraming mga thread ang nakalaan para sa maliit na koleksyon ng basura sa mga batang henerasyon. Ang tanging thread ay abala sa pangunahing koleksyon ng basura sa mas lumang henerasyon.
Ang pagpapatakbo ng isang parallel na GC ay nagiging sanhi din ng mundo na "huminto" at ang application ay nag-hang. Ang pag-uugali na ito ay mas angkop para sa isang multi-threaded na kapaligiran kung saan maraming mga gawain ang kailangang tapusin at ang mahabang pag-pause ay katanggap-tanggap, gaya ng kapag nagpapatakbo ng isang batch na trabaho.
Ang argumento ng JVM para magamit ang parallel na kolektor ng basura ay -XX:+UseParallelGC .
CMS GC
Kilala rin sa amin bilang low rest parallel picker .
Dito, para sa isang maliit na koleksyon ng basura, maraming mga thread ang kasangkot, ito ay nangyayari sa pamamagitan ng parehong algorithm tulad ng sa parallel collector. Ang pangunahing koleksyon ng basura ay multi-threaded, tulad ng lumang parallel na GC, ngunit ang CMS ay tumatakbo nang sabay-sabay sa mga proseso ng aplikasyon upang mabawasan ang mga kaganapang "world stop".
Dahil dito, ang CMS collector ay gumagamit ng mas maraming CPU kaysa sa iba pang collectors. Kung mayroon kang kakayahang maglaan ng mas maraming CPU upang mapabuti ang pagganap, kung gayon ang isang CMS ay mas mainam kaysa sa isang simpleng parallel collector. Ang CMS GC ay hindi siksik.
Ang argumento ng JVM para magamit ang parallel mark-sweep garbage collector ay -XX:+UseConcMarkSweepGC .
G1 (Basura muna) GC
Ang G1GC ay naisip bilang kapalit ng CMS at binuo para sa mga multi-threaded na application na nailalarawan sa malalaking sukat ng heap (mas malaki sa 4 GB). Ito ay parallel at mapagkumpitensya tulad ng isang CMS, ngunit sa ilalim ng hood ito ay gumagana nang napaka-iba kaysa sa mga lumang basurero.
Bagama't gumagana rin ang G1 sa isang henerasyong batayan, wala itong magkahiwalay na espasyo para sa mas bata at mas matatandang henerasyon. Sa halip, ang bawat henerasyon ay isang hanay ng mga rehiyon, na nagbibigay-daan sa kakayahang umangkop sa pagbabago ng laki ng nakababatang henerasyon.
Hinahati ng G1 ang heap sa isang hanay ng mga rehiyon na may pantay na laki (depende sa laki ng heap) at ini-scan ang mga ito sa maraming thread. Ang lugar sa panahon ng pagpapatupad ng programa ay maaaring paulit-ulit na maging matanda at bata.
Pagkatapos makumpleto ang markup phase, alam ng G1 kung aling mga lugar ang naglalaman ng pinakamaraming junk. Kung interesado ang user na bawasan ang mga pag-pause, makakapili lang ang G1 ng ilang lugar. Kung hindi mahalaga sa user ang oras ng pag-pause, o kung nakatakda sa mataas ang limitasyon sa oras ng pag-pause, dadaan ang G1 sa higit pang mga lugar.
Dahil tinutukoy ng G1 GC ang mga rehiyon na may pinakamaraming basura at nagsasagawa muna ng pangongolekta ng basura sa mga rehiyong iyon, tinawag itong "Basura Una".
Bilang karagdagan sa mga lugar ng Eden, Survivors at Old Memory, may dalawa pang uri sa G1GC.
- Humongous (Malaki) - para sa mga bagay na may malalaking sukat (higit sa 50% ng laki ng tambak).
- Available - Hindi nagamit o hindi nakalaang espasyo.
Ang argumento ng JVM para gamitin ang G1 garbage collector ay -XX:+UseG1GC .
Shenandoah (Shandara)
Ang Shenandoah ay isang bagong GC na inilabas bilang bahagi ng JDK 12. Ang pangunahing bentahe ng Shenandoah sa G1 ay ang karamihan sa cycle ng pangongolekta ng basura ay ginagawa kasabay ng mga application thread. Maaari lang lumikas ang G1 sa mga heap area kapag nasuspinde ang aplikasyon, habang inililipat ni Shenandoah ang mga bagay kasabay ng aplikasyon.
Ang Shenandoah ay maaaring mag-compact ng mga live na bagay, maglinis ng basura, at magbakante ng RAM halos sa sandaling mahanap ang libreng memorya. Dahil ang lahat ng ito ay nangyayari sa parehong oras, nang hindi sinuspinde ang application, ang Shenandoah ay mas masinsinang CPU.
ZGC
Ang ZGC ay isa pang GC na inilabas bilang bahagi ng JDK 11 at pinahusay sa JDK 12.
Ito ay inilaan para sa mga application na nangangailangan ng bilis at mababang latency (pause na mas mababa sa 10 ms) at/o gumamit ng napakalaking heap (ilang terabytes).
Ang mga pangunahing layunin ng ZGC ay mababang latency, scalability, at kadalian ng paggamit. Upang gawin ito, pinapayagan nito ang Java application na magpatuloy sa pagtakbo sa kabila ng katotohanan na ang mga operasyon sa pangongolekta ng basura ay isinasagawa. Bilang default, ang ZGC ay naglalabas ng hindi nagamit na memorya at ibinabalik ito sa operating system.
Kaya, ang ZGC ay nagdudulot ng makabuluhang pagpapabuti sa iba pang tradisyonal na mga GC sa pamamagitan ng pagbibigay ng napakababang oras ng patay (karaniwang sa loob ng 2ms).
Ang argumento ng JVM para gamitin ang ZGC garbage collector ay -XX:+UnlockExperimentalVMOptions -XX:+UseZGC .
GO TO FULL VERSION