Używam MAT do porównania dwóch zrzutów sterty. Codziennie robię kupę sterty i rośnie ona o około 200 megawatów dziennie. Myślę, że wyciek jest związany z java.util.zip z powodu tego, co pokazuje tabela, a także dlatego, że ostatnio dodaliśmy nowy proces, który zipuje i rozpakowuje wiele plików. (Patrz rysunek)Potrzebuję pomocy w znalezieniu wycieku pamięci przy użyciu MAT
W tym momencie otwarcia dominator i odfiltrowuje. Inflater. W ten sposób powstała duża lista java.util.zip.Inflater. Teraz chcę zobaczyć, co trzyma te otwarte, więc wybrałem jeden i uruchomiłem ścieżkę do katalogu głównego GC z wyłączeniem słabych i miękkich odniesień (patrz obrazek).
Wygląda to ma do czynienia z inflacją słoika i nie ma nic wspólnego z moim procesie. W tym momencie utknąłem i potrzebuję sugestii.
EDYTOWANIE 1
Sean zadał pytanie o wątkuLokalne. Jeśli spojrzysz na dominator_tree bez filtra, zobaczysz, że java.lang.ApplicationShutdownHooks to 58% sterty. Jeśli rozwinąć niektóre z tych wpisów, widać, że wydają się być w ThreadLocalMap. Jak znaleźć to, co je tam umieściło?
EDIT 2
komentarz Seana umieścić mnie na właściwe tory. Używam Glassfish v 2.0 i ma memory leak. Ciągle tworzy nowe LogManagers i dodaje je do kolekcji ApplicationShutdownHooks.
Rozwiązałem problem przez złamanie aplikacji ApplicationShutdownHook i ręczne usunięcie obiektów z kolekcji.
Czy wszystkie ścieżki instancji do głównego katalogu GC wyglądają tak? Może to nie być reprezentatywna próbka. –
Jest 16k wystąpień, więc możliwe, że niektóre są różne. Spojrzałem na kilku i ich to samo. Czy ktoś wie, dlaczego moje obrazy nie są wyświetlane? – Preston
Pokazują mi się dobrze. –