Wie immer eine ausführliche Problembeschreibung.

Wir testen gerade unser Produkt auf Stresstests - und stehen nun vor einem seltsamen Problem. Nach ein bis zwei Stunden wächst der Heap-Speicherplatz, die Anwendung stirbt einige Zeit später.

Beim Profilieren der Anwendung wird eine sehr große Anzahl von Finalizer-Objekten angezeigt, die den Heap füllen. Nun, wir dachten, das Problem "könnte der seltsame Finalizer-Thread zum Verlangsamen sein" und überprüften, ob die Anzahl der Objekte, die finalisiert werden müssen, reduziert werden kann (in diesem Fall JNA-native Handles). Trotzdem gute Idee und tausende neue Objekte reduziert ...

Die nächsten Tests zeigten dasselbe Muster, nur eine Stunde später und nicht so steil. Diesmal stammten die Finalizer aus den FileInput- und FileOutput-Streams, die im Testbed häufig verwendet werden. Alle Ressourcen sind geschlossen, aber die Finalizer werden nicht mehr aufgeräumt.

Ich habe keine Ahnung, warum der FinalizerThread nach 1 oder 2 Stunden (ausnahmslos) plötzlich nicht mehr funktioniert. Wenn wir in einigen unserer Threads System.runFinalization () von Hand erzwingen, zeigt der Profiler, dass die Finalizer bereinigt sind. Die sofortige Wiederaufnahme des Tests führt zu einer neuen Heap-Zuordnung für die Finalizer.

Der FinalizerThread ist immer noch da und fragt jConsole, ob er WARTET.

BEARBEITEN

Zunächst ergab die Überprüfung des Heaps mit HeapAnalyzer nichts Neues / Seltsames. HeapAnalyzer hat einige nette Funktionen, aber ich hatte zuerst meine Schwierigkeiten. Ich benutze jProfiler, der mit netten Werkzeugen zur Haufeninspektion geliefert wird und dabei bleibt.

Vielleicht fehlen mir einige Killer-Features in HeapAnalyzer?

Zweitens haben wir heute die Tests mit einer Debug-Verbindung anstelle des Profilers eingerichtet - das System ist jetzt fast 5 Stunden stabil. Dies scheint eine sehr merkwürdige Kombination aus zu vielen Finalizern (die in der ersten Überprüfung reduziert wurden), dem Profiler und den VM GC-Strategien zu sein. Da im Moment alles gut läuft, gibt es keine wirklichen Einsichten ...

Vielen Dank für die bisherige Eingabe - vielleicht bleiben Sie dran und interessiert (jetzt, wo Sie vielleicht mehr Grund zu der Annahme haben, dass wir nicht über einen einfachen Programmierfehler sprechen).