Szeregowy GC
Wyrzucanie elementów bezużytecznych poprawia wydajność pamięci w Javie, usuwając ze sterty obiekty, do których nie ma odwołań, i robiąc miejsce dla nowo utworzonych obiektów.
Wirtualna maszyna Java ma osiem typów śmieciarek. Rozważmy każdy z nich szczegółowo.
Serial GC to najprostsza implementacja GC. Jest przeznaczony dla małych aplikacji działających w środowiskach jednowątkowych. Wszystkie zdarzenia wyrzucania elementów bezużytecznych są wykonywane sekwencyjnie w tym samym wątku. Zagęszczanie jest wykonywane po każdym wyrzuceniu śmieci.
![Szeregowy GC](https://cdn.codegym.cc/images/article/3cbe67b6-3553-40cf-90a8-6df5080f300f/1024.jpeg)
Uruchomienie modułu zbierającego powoduje zdarzenie „zatrzymania świata”, w wyniku którego cała aplikacja zostaje zawieszona. Ponieważ cała aplikacja jest zamrożona podczas wyrzucania elementów bezużytecznych, nie powinieneś uciekać się do tego w prawdziwym życiu, jeśli chcesz, aby opóźnienia były jak najniższe.
Argument JVM do użycia szeregowego modułu wyrzucania elementów bezużytecznych to -XX:+UseSerialGC .
Równoległe GC
Równoległy moduł wyrzucania elementów bezużytecznych jest przeznaczony dla aplikacji ze średnimi i dużymi zestawami danych, które działają na sprzęcie wielowątkowym lub wieloprocesorowym. Jest to domyślna implementacja GC, znana również jako kolektor przepływności.
Kilka wątków jest przeznaczonych do małej zbiórki śmieci w młodym pokoleniu. Jedyny wątek jest zajęty głównym wyrzucaniem elementów bezużytecznych w starszej generacji.
![Równoległe GC](https://cdn.codegym.cc/images/article/9253feb3-a0e1-4ef0-9696-25926c18df42/1024.jpeg)
Uruchomienie równoległego GC powoduje również „zatrzymanie” świata i zawieszenie aplikacji. To zachowanie jest bardziej odpowiednie w środowisku wielowątkowym, w którym należy wykonać wiele zadań i akceptowane są długie przerwy, na przykład podczas uruchamiania zadania wsadowego.
Argument JVM do użycia równoległego modułu wyrzucania elementów bezużytecznych to -XX:+UseParallelGC .
CMS GC
Znany nam również jako zbieracz równoległy z niskim oparciem .
Tutaj, w przypadku małego wyrzucania elementów bezużytecznych, zaangażowanych jest kilka wątków, dzieje się to za pomocą tego samego algorytmu, co w kolektorze równoległym. Główne wyrzucanie elementów bezużytecznych jest wielowątkowe, podobnie jak stary równoległy GC, ale CMS działa równolegle z procesami aplikacji, aby zminimalizować zdarzenia „zatrzymania świata”.
![CMS GC](https://cdn.codegym.cc/images/article/ba41fb23-bd47-4051-8264-a95a9c9849ad/1024.jpeg)
Z tego powodu kolektor CMS zużywa więcej procesora niż inne kolektory. Jeśli masz możliwość przydzielenia większej liczby procesorów w celu poprawy wydajności, CMS jest lepszy od prostego kolektora równoległego. CMS GC nie kompaktuje.
Argumentem maszyny JVM do użycia równoległego wyrzucania elementów bezużytecznych z wymiataniem znaczników jest -XX:+UseConcMarkSweepGC .
G1 (najpierw śmieci) GC
G1GC został pomyślany jako zamiennik CMS i został opracowany dla aplikacji wielowątkowych, które charakteryzują się dużymi rozmiarami sterty (powyżej 4 GB). Jest równoległy i konkurencyjny jak CMS, ale pod maską działa zupełnie inaczej niż stare śmieciarki.
Choć G1 również działa na zasadzie pokoleniowej, nie ma wydzielonych przestrzeni dla młodszego i starszego pokolenia. Zamiast tego każde pokolenie jest zbiorem regionów, co pozwala na elastyczność w zmianie wielkości młodszego pokolenia.
G1 dzieli stertę na zestaw regionów o równej wielkości (w zależności od wielkości sterty) i skanuje je na wiele wątków. Obszar podczas realizacji programu może wielokrotnie stawać się zarówno stary, jak i młody.
Po zakończeniu fazy znaczników G1 wie, które obszary zawierają najwięcej śmieci. Jeśli użytkownik jest zainteresowany zminimalizowaniem przerw, G1 może wybrać tylko kilka obszarów. Jeśli czas pauzy nie jest ważny dla użytkownika lub jeśli limit czasu pauzy jest ustawiony na wysoki, G1 przejdzie przez więcej obszarów.
Ponieważ G1 GC identyfikuje regiony z największą ilością śmieci i najpierw usuwa śmieci w tych regionach, nazywa się to „Garbage First”.
![](https://cdn.codegym.cc/images/article/a2c26fd4-2e6b-4d2c-a646-473db59d44a6/800.jpeg)
Oprócz obszarów Eden, Survivors i Old Memory, w G1GC istnieją dwa inne typy.
- Humongous (Huge) - dla obiektów o dużych rozmiarach (ponad 50% wielkości sterty).
- Dostępne — nieużywane lub nieprzydzielone miejsce.
Argument JVM do użycia modułu wyrzucania elementów bezużytecznych G1 to -XX:+UseG1GC .
Shenandoah (Shandara)
Shenandoah to nowy GC wydany jako część JDK 12. Kluczową przewagą Shenandoah nad G1 jest to, że większość cyklu wyrzucania elementów bezużytecznych jest wykonywana równolegle z wątkami aplikacji. G1 może ewakuować obszary sterty tylko wtedy, gdy aplikacja jest zawieszona, podczas gdy Shenandoah przesuwa obiekty w tym samym czasie co aplikacja.
Shenandoah może kompaktować żywe obiekty, usuwać śmieci i zwalniać pamięć RAM niemal natychmiast po znalezieniu wolnej pamięci. Ponieważ wszystko to dzieje się w tym samym czasie, bez zawieszania aplikacji, Shenandoah bardziej obciąża procesor.
ZGC
ZGC to kolejny GC wydany jako część JDK 11 i ulepszony w JDK 12.
Jest przeznaczony do aplikacji, które wymagają szybkości i małych opóźnień (pauzy poniżej 10 ms) i/lub używają bardzo dużej sterty (kilka terabajtów).
Głównymi celami ZGC są niskie opóźnienia, skalowalność i łatwość użytkowania. Aby to zrobić, pozwala aplikacji Java na dalsze działanie pomimo faktu, że trwają operacje wyrzucania elementów bezużytecznych. Domyślnie ZGC zwalnia nieużywaną pamięć i zwraca ją do systemu operacyjnego.
W ten sposób ZGC zapewnia znaczną poprawę w stosunku do innych tradycyjnych GC, zapewniając wyjątkowo krótkie czasy martwe (zwykle w granicach 2 ms).
![Główne cele ZGC](https://cdn.codegym.cc/images/article/3ca77686-5b92-46ad-ab67-f8623caa9c71/512.jpeg)
Argumentem JVM do użycia modułu wyrzucania elementów bezużytecznych ZGC jest -XX:+UnlockExperimentalVMOptions -XX:+UseZGC .
GO TO FULL VERSION