Dlaczego JVM full GC musi zatrzymać świat?
Zadano mi to pytanie i odpowiedziałem "ponieważ JVM musi przenosić obiekty", ale później Wygooglowałem i wydaje się, że nie mogłem znaleźć żadnej sensownej odpowiedzi.
4 answers
Po Pierwsze, artykuł o zbieraniu śmieci w Wikipedii to naprawdę dobra lektura.
A propos.
Ogólnie GC nie wymaga stop-the-World pause. Istnieją implementacje JVM, które są (prawie) wolne od pauzy (np. Azul Zing JVM). Ilekroć JVM wymaga od STW zbierania śmieci, zależy to od używanego algorytmu.
Mark Sweep Compact (MSC) jest popularnym algorytmem używanym domyślnie w hotspocie. Jest realizowany w modzie STW i posiada 3 fazy:
- MARK-przemierzanie wykresu obiektów na żywo, aby zaznaczyć obiekty osiągalne
- SWEEP-skanuje pamięć, aby znaleźć nieoznakowaną pamięć
- COMPACT-przenoszenie zaznaczonych obiektów w celu defragmentacji wolnej pamięci
Podczas relokacji obiektów w stercie, JVM powinien skorygować wszystkie odniesienia do tego obiektu. Podczas procesu relokacji Wykres obiektowy jest niespójny, dlatego wymagana jest pauza STW.
Concurrent Mark Sweep (CMS) to kolejny algorytm w hotspocie JVM, który nie wykorzystuje pauzy STW dla starej kolekcji przestrzeni (nie dokładnie to samo co pełna kolekcja).
CMS wykorzystuje barierę zapisu (wyzwalanie działania za każdym razem, gdy piszesz odwołanie w Java heap) do implementacji współbieżnej wersji MARK i nie używa COMPACT. Brak zagęszczenia może spowodować fragmentację, a jeśli pobieranie śmieci w tle nie jest wystarczająco szybkie, aplikacja może być nadal blokowana. W tych przypadkach CMS będzie fallback do STW mark-sweep-compact kolekcja.
Istnieje również G1, która jest przyrostową odmianą MSC. Więcej o algorytmach GC można przeczytać w hotspocie JVM na moim blogu.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-07-25 17:28:22
Używając przepustowości GC, JVM potrzebuje pauz STW, aby być wolnym jak najwięcej pamięci. Stosuje tylko takie pauzy, że jest najskuteczniejszy.
Używając modułu low-pauses collector (CMS), czyścisz jednocześnie starą generację, bez zatrzymywania aplikacji. Wadą jest to, że stare pokolenie staje się rozdrobnione. Jeśli jest zbyt rozdrobniony i wymaga zagęszczenia, następuje pełne GC (STW). Jednak zawsze możesz dostroić swoją aplikację, aby nie uzyskać pełnego GC.
G1 GC jest szczególnym przypadkiem. Jego obecnym głównym celem jest niska fragmentacja na stercie, a jednocześnie równoczesne (jak CMS). Gdy nie może osiągnąć tego celu, JVM powraca również do pauzy STW, dzięki czemu sterta jest całkowicie oczyszczona i zagęszczona.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-05-26 13:28:17
Stop-the-world gwarantuje, że nowe obiekty nie zostaną przydzielone i Obiekty nie staną się nagle nieosiągalne podczas pracy kolektora.
Zaletą jest to, że jest zarówno prostszy w implementacji, jak i szybszy niż przyrostowe usuwanie śmieci.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-05-22 15:56:46
Krótka faza stop-the-world jest potrzebna do skanowania referencji na stosie w prawie każdym schemacie zbierania śmieci, nawet w większości schematów, które minimalizują przerwy. Bardzo szczegółowe wyjaśnienie w Tej odpowiedzi . algorytmy przyrostowe i współbieżne ciężko pracują, aby zminimalizować te przerwy do minimum, ale nadal mają je w większości przypadków.
Istnieją nawet metody przemieszczania / zagęszczania, które nie muszą zatrzymywać świata podczas przesuwania obiektów (Staccato przychodzi mi na myśl)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:17:55