Ich verwende den MAT, um zwei Heap-Dumps zu vergleichen. Ich nehme jeden Tag einen Haufen Müll und es wächst jeden Tag um etwa 200 MB. Ich denke, dass das Leck mit java.util.zip wegen der Tabelle verbunden ist, und weil wir kürzlich einen neuen Prozess hinzugefügt haben, der viele Dateien zippt und entpackt. (siehe Bild)
An diesem Punkt öffne ich den Dominator und filtere nach. Inflater . Das erzeugte eine große Liste von java.util.zip.Inflater. Jetzt möchte ich sehen, was diese offen hält, also wählte ich einen aus und führte den Pfad zur GC-Wurzel, wobei schwache und weiche Referenzen ausgeschlossen wurden (siehe Bild).
Es sieht so aus, als ob das mit der Inflation des Glases zu tun hat und nichts mit meinem Prozess zu tun hat. An diesem Punkt bin ich fest und brauche einige Vorschläge.
EDIT 1
Sean fragte nach den ThreadLocals. Wenn Sie den dominator_tree ohne Filter betrachten, sehen Sie, dass java.lang.ApplicationShutdownHooks 58% des Heapspeichers ist. Wenn ich einige dieser Einträge erweitere, sieht man, dass sie sich in der ThreadLocalMap befinden. Wie würde ich finden, was sie dorthin gebracht hat?
EDIT 2
Seans Kommentar hat mich auf die richtige Spur gebracht. Ich verwende Glassfish v 2.0 und es hat einen Speicherverlust . Es erstellt ständig neue LogManager und fügt sie der ApplicationShutdownHooks-Sammlung hinzu.
Ich habe das Problem gelöst, indem ich die ApplicationShutdownHooks geöffnet und die Objekte manuell aus der Sammlung entfernt habe.
Seans Kommentar hat mich auf die richtige Spur gebracht. Ich benutze Glassfish v 2.0 und es hat ein Speicherleck. Es erstellt ständig neue LogManager und fügt sie der ApplicationShutdownHooks-Sammlung hinzu.
Ich habe das Problem gelöst, indem ich die ApplicationShutdownHooks geöffnet und die Objekte manuell aus der Sammlung entfernt habe.
Tags und Links java memory-leaks