JVM Garbage Collection Basics

Garbage Collectors Algoritmi

Garbage Collectors au de obicei următoarele obiective (mai ușor de spus decât de făcut)

  • Mult scurte „opriți pauzele lumii” cu o țintă de câteva milisecunde
  • Timpurile de pauză nu cresc cu un heap, live-set, sau root-set size
  • Pentru a face față unor dimensiuni de heap variind de la câțiva MB până la mulți TB
  • Concurență ridicată – Toată munca de ridicare a greutăților se face în timp ce firele Java continuă să se execute
  • Trasmitere ridicată
  • .

  • Facil de reglat

Garbage Collectors

Datele din heap sunt împărțite în mai multe regiuni de alocare (sau generații) care sunt păstrate separat în funcție de vârsta obiectului (i.adică numărul de iterații GC supraviețuite). În timp ce unii colectori sunt uni-generationali, ceilalți folosesc două generații: (1) Generația tânără (împărțită în continuare în Eden și două regiuni de supraviețuire) și (2) Generația veche (sau de durată).
Sursa: Blogul lui Ionuț Balosin

Colectoare cu două generații:

GCG serial – Algoritmul utilizează un singur fir pentru a efectua toate lucrările de colectare a gunoiului, ceea ce îl face relativ eficient deoarece nu există costuri de comunicare între fire. Este cel mai bine adaptat pentru mașinile cu un singur procesor, deoarece nu poate profita de hardware-ul multiprocesor.

GCG de randament (paralel) – Acest algoritm utilizează mark-copy în generația tânără și mark-sweep-compact în generația veche. Atât colecțiile Young cât și Old collection declanșează evenimente de tip stop-the-world, oprind toate firele aplicației pentru a efectua colectarea gunoiului. Ambele colectori execută fazele de marcare și copiere/compactare folosind mai multe fire de execuție, de unde și numele „Parallel”.

Parallel Garbage Collector este potrivit pentru mașinile cu mai multe nuclee în cazurile în care obiectivul principal este de a crește randamentul. Un randament mai mare se obține datorită utilizării mai eficiente a resurselor sistemului:

  • în timpul colectării, toate nucleele curăță gunoiul în paralel, ceea ce duce la pauze mai scurte
  • între ciclurile de colectare a gunoiului niciunul dintre colectori nu consumă resurse

Garbage First (G1) GC – Acest colector este un colector de gunoi de tip server, destinat mașinilor cu mai multe procesoare cu memorii mari. Acesta îndeplinește obiectivele de timp de pauză pentru colectarea gunoiului (GC) cu o probabilitate ridicată, atingând în același timp un randament ridicat.

  • Colectorul G1 are o abordare diferită în ceea ce privește modelul de memorie heap. Heap-ul este împărțit într-un set de regiuni heap de dimensiuni egale, fiecare fiind un interval contiguu de memorie virtuală.
  • Cerințelor seturi de regiuni le sunt atribuite aceleași roluri (eden, survivor, old) ca în colectorii mai vechi, dar nu există o dimensiune fixă pentru acestea.
  • Dimensiunea regiunii este aleasă de JVM la pornire. JVM țintește în general în jur de 2000 de regiuni care variază ca mărime de la 1 la 32Mb. Colectorul G1 are o abordare diferită

Pentru mai multe detalii, consultați Getting Started with the G1 GC

G1 Heap Allocation

Colectori generaționali Uni:

Shenandoah GC – Shenandoah este colectorul de gunoi cu timp de pauză redus care reduce timpii de pauză GC prin efectuarea mai multor activități de colectare a gunoiului concomitent cu programul Java în curs de execuție. Shenandoah efectuează cea mai mare parte a activității GC în mod simultan, inclusiv compactarea simultană, ceea ce înseamnă că timpii săi de pauză nu mai sunt direct proporționali cu dimensiunea heap-ului. Colectarea gunoiului dintr-un heap de 200 GB sau un heap de 2 GB ar trebui să aibă un comportament de pauză scăzut similar.

Pentru mai multe detalii, vă rugăm să consultați Detalii de implementare în Wiki

Z GC – ZGC este un colector de compactare concurent, de o singură generație, bazat pe regiuni, conștient de NUMA. Fazele stop-the-world sunt limitate la scanarea rădăcinii, astfel încât timpii de pauză GC nu cresc odată cu dimensiunea heap-ului sau a setului live.

Pentru mai multe detalii, vă rugăm să consultați Session on ZGC de Per Liden pe YouTube

În sfârșit,

Epsilon GC (experimental)- Un GC care se ocupă de alocarea memoriei, dar nu implementează niciun mecanism real de recuperare a memoriei. Odată ce heap-ul Java disponibil este epuizat, JVM-ul se va închide. Proiectat pentru testarea internă a JDK, dar poate fi conceput ca fiind util în două situații

  • Programe cu durată de viață foarte scurtă
  • Programele sunt scrise cu grijă pentru a reutiliza memoria și nu efectuează niciodată alocări noi

.

Lasă un răspuns

Adresa ta de email nu va fi publicată.