Java zużywająca znacznie więcej pamięci niż rozmiar sterty (lub rozmiar poprawnie dokowanego limitu pamięci)

[32]}Pamięć wirtualna używana przez proces Java wykracza daleko poza samą stertę Javy. JVM zawiera wiele podsytemów: Garbage Collector, Class Loading, JIT compilers itp., a wszystkie te podsystemy wymagają pewnej ilości pamięci RAM do działania.

Więc co zajmuje pamięć w procesie Javy?

1. Java Heap

Najbardziej oczywistą częścią. Tutaj żyją Obiekty Javy. Sterta zajmuje do -Xmx ilość pamięci.

1. Garbage Collector

Struktury i algorytmy GC wymagają dodatkowej pamięci do zarządzania stertą. Struktury te to Mark Bitmap, Mark Stack (do przechodzenia grafu obiektowego), Zapamiętane Zestawy (do zapisu odniesień międzyregionalnych) i inne. Niektóre z nich są bezpośrednio przestrajalne, np. -XX:MarkStackSizeMax, inne zależą od układu sterty, np. większe są regionami G1 (-XX:G1HeapRegionSize), mniejsze są zapamiętanymi zbiorami.

Nadmiarowość pamięci GC różni się w zależności od algorytmów GC. -XX:+UseSerialGC i -XX:+UseShenandoahGC mają najmniejsze nad głową. G1 lub CMS mogą z łatwością wykorzystywać około 10% całkowitego rozmiaru stosu.

1. Code Cache

Zawiera dynamicznie generowany kod: JIT-metody skompilowane, interpreter i stubów. Jego rozmiar jest ograniczony przez -XX:ReservedCodeCacheSize (domyślnie 240M). Wyłącz -XX:-TieredCompilation, aby zmniejszyć ilość skompilowanego kodu, a tym samym użycie pamięci podręcznej kodu.

1. kompilator

Sam kompilator JIT również wymaga pamięci do wykonywania swojej pracy. Można to ponownie zmniejszyć poprzez wyłączenie kompilacji warstwowej lub poprzez zmniejszenie liczby wątków kompilatora: -XX:CICompilerCount.

1. Class loading

Metadane klasy (bajty metod, symbole, stałe pule, adnotacje itd.) jest przechowywany w obszarze off-heap o nazwie Metaspace. Im więcej klas jest ładowanych - tym więcej metaspace jest używane. Całkowite użycie może być ograniczone przez -XX:MaxMetaspaceSize (domyślnie nieograniczone) i -XX:CompressedClassSpaceSize (domyślnie 1G).

1. Tablice symboli

Dwa główne Hashtable JVM: tabela symboli zawiera nazwy, podpisy, identyfikatory itp. a tabela łańcuchów zawiera odniesienia do internowanych łańcuchów. Jeśli natywne śledzenie pamięci wskazuje na znaczące wykorzystanie pamięci przez tabelę łańcuchową, prawdopodobnie oznacza, że aplikacja nadmiernie wywołuje String.intern.

1. wątki

Stosy wątków są również odpowiedzialne za pobieranie pamięci RAM. Wielkość stosu jest kontrolowana przez -Xss. Domyślnie jest 1M na wątek, ale na szczęście rzeczy nie są takie złe. OS przydziela strony pamięci leniwie, tzn. przy pierwszym użyciu, więc rzeczywiste zużycie pamięci będzie znacznie niższe (zazwyczaj 80-200 KB na stos wątków). Napisałem skrypt aby oszacować ile RSS należy do wątku Java stosy.

Istnieją inne części JVM, które przydzielają pamięć natywną, ale zwykle nie odgrywają one dużej roli w całkowitym zużyciu pamięci.

Bufory bezpośrednie

Aplikacja może jawnie zażądać pamięci off-heap przez wywołanie ByteBuffer.allocateDirect. Domyślny limit off-heap jest równy -Xmx, ale może być nadpisany przez -XX:MaxDirectMemorySize. Bezpośrednie bufory bajtów są zawarte w Other sekcji wyjścia NMT (lub Internal przed JDK 11).

Ilość użytej pamięci bezpośredniej jest widoczna przez JMX, np. w JConsole lub Java Mission Control:

Oprócz bezpośrednich buforów bajtowych mogą być MappedByteBuffers - pliki mapowane do pamięci wirtualnej procesu. NMT ich nie śledzi, jednak Mappedbytebuffery mogą również pobierać pamięć fizyczną. I nie ma prostego sposobu, aby ograniczyć, ile mogą wziąć. Można po prostu zobaczyć rzeczywiste użycie, patrząc na mapę pamięci procesu: pmap -x <pid>

Address           Kbytes    RSS    Dirty Mode  Mapping
...
00007f2b3e557000   39592   32956       0 r--s- some-file-17405-Index.db
00007f2b40c01000   39600   33092       0 r--s- some-file-17404-Index.db
                           ^^^^^               ^^^^^^^^^^^^^^^^^^^^^^^^

Biblioteki natywne

Kod JNI załadowany przez {[21] } może przydzielić jako dużo pamięci poza stertą, jak chce, bez kontroli od strony JVM. Dotyczy to również standardowej biblioteki klas Java. W szczególności niezamknięte zasoby Javy mogą stać się źródłem natywnego wycieku pamięci. Typowe przykłady to ZipInputStream lub DirectoryStream.

Jvmti agentów, w szczególności jdwp debugging agent-może również powodować nadmierne zużycie pamięci.

Ta odpowiedź opisuje jak profilować natywne alokacje pamięci za pomocą async-profiler.

Alokator zagadnienia

Proces zwykle żąda pamięci natywnej bezpośrednio z systemu operacyjnego (wywołaniem systemowym mmap) lub przy użyciu standardowego alokatora libc malloc. Z kolei malloc żąda dużych kawałków pamięci od systemu operacyjnego za pomocą mmap, a następnie zarządza tymi kawałkami według własnego algorytmu alokacji. Problem w tym, że algorytm ten może prowadzić do fragmentacji i nadmiernego wykorzystania pamięci wirtualnej.

jemalloc, alternatywny alokator, często wydaje się mądrzejszy niż zwykły libc malloc, więc przejście na jemalloc może spowodować zmniejszenie rozmiaru footprintu za darmo.

Podsumowanie

Nie ma gwarantowanego sposobu oszacowania pełnego wykorzystania pamięci procesu Java, ponieważ jest zbyt wiele czynników, które należy wziąć pod uwagę.

Total memory = Heap + Code Cache + Metaspace + Symbol tables +
               Other JVM structures + Thread stacks +
               Direct buffers + Mapped files +
               Native Libraries + Malloc overhead + ...

Jednym z możliwych sposobów ustawiania limitów dokera byłoby obserwowanie rzeczywistego zużycia pamięci w "normalny" stan procesu. Istnieją narzędzia i techniki do badania problemów z zużyciem pamięci Java: Native Memory Tracking, pmap, jemalloc, async-profiler .

Update

Oto zapis mojej prezentacji ślad pamięci procesu Java .

W tym filmie omawiam, co może zużywać pamięć w procesie Java, jak monitorować i ograniczać rozmiar niektórych obszarów pamięci oraz jak profil natywne wycieki pamięci w aplikacji Java.