Dlaczego moduł usuwania śmieci Java wydaje się wykonywać agresywny przebieg krótko po wykonaniu mniej agresywnego?

Question

Podczas monitorowania programu java za pomocą VisualVM, zauważyłem interesujący wzorzec w zachowaniu śmieciarza. Wydaje się, że bardzo często, zaraz po przeprowadzeniu "normalnego" cyklu zbierania śmieci, GC wykonuje drugi, o wiele bardziej intensywny proces cpu, który wydaje się nie mieć żadnego dodatkowego efektu (Stosowana kupa po bardziej agresywnym przebiegu jest mniej więcej taka sama jak to jest po lżejszym uruchomieniu).

Wskazałem na wyjściu VisualVM, gdzie można zobaczyć, jak działa sortownik śmieci i odpowiednie zmiany wykorzystania sterty.

Moje pytanie jest w zasadzie to, co jest garbage collector tu robi i dlaczego? Co powoduje próbę wykonywania naprawdę intensywnych cpu, gdy jest dużo wolnej pamięci i nie ma zauważalnych korzyści w porównaniu z lżejszymi przebiegami? Czy źle interpretuję wykres?

Wydajność programu nie jest tak naprawdę zmieniona, jestem po prostu ciekawa.

Answer 1

Patrząc na wykresy, warto przejrzeć przebiegi GC, ale jeśli chcesz dowiedzieć się, dlaczego GC działa w danym momencie, , musisz zagłębić się w logach GC.

Włącz pełne rejestrowanie GC, zacznij także kolekcjonować jstat. Skoncentruj się na tych czasach, w których widzisz niespodziewane cykle GC i śledź je w dziennikach. Co tam widzisz? Spróbuj zobaczyć:

• czy jest to pełny czy mniejszy GC?
• czym są zawody eden, perm, oldGen, przestrzenie ocalałe, itp?
• jakie są stawki przydziału, rozmiar zestawu danych na żywo, stawki promocyjne w tych odstępach czasu?
• itp

Odpowiedź na te pytania może prowadzić do problemu, dlaczego GC jest uruchomiony.

AKTUALIZACJA: można znaleźć szczegóły techniczne dotyczące regulacji GC, np. w: Is there a cookbook guide for GC problems?