Mögliche Memory leak in der Anzahl der Geladenen Klassen in der Java-Anwendung
Ich fing vor kurzem an, profiling einer osgi-java-Anwendung, die ich Schreibe, mit VisualVM. Eine Sache, die ich bemerkt habe, ist, dass, wenn die Anwendung beginnt mit dem senden der Daten an einen client (über JMS), die Anzahl der geladenen Klassen beginnt, steigen stetig an. Die Heap-Größe und die PermGen-Größe konstant bleibt, jedoch. Die Anzahl der Klassen sinkt nie, sogar nach dem es Stoppt das senden von Daten. Ist das ein memory-leak? Ich denke, es ist, weil die geladenen Klassen müssen irgendwo gespeichert werden, aber die heap-und die permgen sich nicht erhöhen, auch nachdem ich die Anwendung ausführen, für mehrere Stunden.
Für den screenshot von meinem profiling-Anwendung gehen hier
Du musst angemeldet sein, um einen Kommentar abzugeben.
Vielen Dank für Ihre Hilfe. Ich habe herausgefunden, was das problem ist. In einer meiner Klassen war ich mit Jaxb ein XML-string. Dabei JAXB ueses Reflexion zum erstellen einer neuen Klasse.
So, obwohl die JAXBContext nicht zu sagen, um in den Haufen, werden die Klassen geladen worden wäre.
Habe ich mein Programm wieder, und ich sehe einen normalen plateau als ich erwarten würde.
Ich bin bereit zu Wetten, dass ein problem in Bezug auf bytecode-Generierung.
Viele Bibliotheken verwenden CGLib, BCEL, Javasist oder Janino generiert bytecode für die neuen Klassen zur Laufzeit, und dann laden Sie Sie aus kontrolliert-classloader. Der einzige Weg, um die überführung dieser Klassen ist zu release werden alle Referenzen auf den classloader.
Da der classloader ist gehalten, die von jeder Klasse, das bedeutet auch, dass Sie, sollten Sie nicht lassen Sie die Verweise auf alle Klassen [1]. Sie können fangen Sie diese mit einem anständigen profiler (ich benutze Yourkit - Suche für mehrere classloader-Instanzen mit der gleichen Größe beibehalten)
Einem Haken ist, dass die JVM nicht entladen Klassen standardmäßig (der Grund dafür ist die Abwärtskompatibilität, dass Menschen übernehmen (fälschlicherweise), dass statische Initialisierungen würde nur einmal ausgeführt werden. Die Wahrheit ist, dass Sie jedes mal ausgeführt, wenn eine Klasse geladen wird.) Aktivieren entladen, sollten Sie einige passieren die folgenden Optionen verwenden:
(getestet mit JDK 1.5)
Selbst dann, übermäßige bytecode-Erzeugung ist nicht eine gute Idee, so schlage ich vor, schauen Sie in Ihrem code, den Schuldigen zu finden und den cache der generierten Klassen. Häufige Täter sind scripting-Sprachen, dynamische proxies (einschließlich der durch Sie erzeugten application Server) oder riesige Hibernate Modell (in diesem Fall können Sie einfach erhöhen Ihre permgen).
Siehe auch:
Finden Sie vielleicht einige hotspot-flags zu nutzen, verstehen dieses Verhalten wie:
Dies ist eine gute Referenz:
http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
Sofern ich nicht falsch verstehen, wir suchen hier bei geladenen Klassen nicht Instanzen.
Wenn der code zuerst eine Klasse referenziert, die JVM hat der ClassLoader gehen aus und Holen sich die Informationen über die Klasse aus .Klasse-Datei oder ähnliches.
Ich bin mir nicht sicher unter welchen Bedingungen es würde entladen einer Klasse. Sicherlich sollte es nie entladen jede Klasse mit statischen Informationen.
Also ich würde erwarten, dass ein Muster in etwa wie das Ihre, wo als Ihr Antrag läuft, es geht in Bereiche und Verweise neuen Klassen, so dass die Anzahl der geladenen Klassen gehen würden, und.
Jedoch zwei Dinge, scheint mir seltsam:
Ich würde erwarten, dass es im trend nach oben, aber in eine wacklige Linie, und dann Kegel aus auf die Steigerung, da die JVM bereits geladen, die meisten Klassen Ihr Programm verweisen. Ich meine, es gibt eine endliche Anzahl von Klassen verwiesen, die in den meisten Anwendungen.
Sind Sie dynamisch erstellen neuer Klassen on the fly irgendwie?
Ich würde vorschlagen, läuft ein einfacher test-app über die gleichen debugger zu erhalten, ein baseline-Fall. Dann könnten Sie überlegen, ob die Umsetzung Ihrer eigenen ClassLoader, dass spuckt einige debug-Informationen, oder vielleicht gibt es ein tool, um darüber zu berichten.
Müssen Sie herausfinden, was diese Klassen, die geladen werden.
Ja, es ist in der Regel ein memory leak (da wir nicht wirklich viel mit Speicher direkt, es ist mehr eine Instanz der Klasse leak). Ich habe diesen Prozess Durchlaufen, bevor und es ist in der Regel einige listener Hinzugefügt, um eine alte toolkit nicht entfernen Sie es selbst.
In älteren code, der Eine Hörer-Beziehung bewirkt, dass die "Hörer" - Objekt bleiben um. Ich würde schauen bei älteren toolkits oder diejenigen, die noch nicht durch die vielen umdrehungen. Jede lange bestehende Bibliothek läuft auf eine spätere JDK würde wissen über Referenz-Objekte, die entfernt die Anforderung für "Remove Listener".
Auch, rufen Sie dispose auf Ihrem windows, wenn Sie Sie neu erstellen jedes mal. Ich glaube nicht, dass Sie jemals Weg gehen, wenn Sie nicht (Eigentlich gibt es auch eine dispose on close-Einstellung).
Mach dir keine sorgen über Swing oder JDK Zuhörern, Sie sollten alle Referenzen verwenden, so sollten Sie in Ordnung sein.
Verwenden Sie die Eclipse Memory Analyzer zu überprüfen, für duplizierte Klassen-und Speicherverluste. Es kann passieren, dass die gleiche Klasse geladen wird, mehr als einmal.
Grüße,
Markus