Häufige Java-Speicher-/Referenzleckmuster?

Question

Das vielleicht typischste Beispiel ist das JDBC-Schließen auf die falsche Art und Weise und die nicht korrekte Behandlung der möglichen Ausnahmen. Ich bin sehr neugierig auf andere Beispiele, die Sie gesehen haben - vorzugsweise im Zusammenhang mit Webanwendungen.

Gibt es also häufige Leckmuster in Java?

Answer 1

Meiner Erfahrung nach sind die beiden wichtigsten "effektiven Leck"-Muster:

• Statik und Singularität, die mit der Zeit wachsen. Dazu könnten Caches, schlecht implementierte und genutzte Verbindungspools, Wörterbücher mit "allen Benutzern, die wir seit dem Start gesehen haben" usw. gehören.
• Referenzen von langlebigen Objekten auf Objekte, die beabsichtigt kurzlebig zu sein. In C# kann dies mit Ereignissen geschehen, und das äquivalente Beobachtermuster könnte den gleichen Effekt in Java haben. Wenn man ein Objekt (den Beobachter) bittet, ein anderes (die Quelle) zu beobachten, erhält man in der Regel eine Referenz von die Quelle zu den Beobachter. Das kann am Ende die einzige "lebendige" Referenz sein, aber sie bleibt so lange bestehen wie die Quelle.
• Permgen wird undicht, wenn Sie ständig neuen Code dynamisch erzeugen. Ich befinde mich hier auf felsigerem Boden, aber ich bin mir ziemlich sicher, dass ich auf diese Weise Probleme bekommen habe. Es ist möglich, dass dies teilweise aufgrund von JRE-Fehlern, die inzwischen behoben wurden - es ist zu lange her, seit es passiert ist, für mich zu erinnern, für sicher.
• Unit-Tests, die einen Zustand beibehalten, können länger dauern, als Sie vielleicht erwarten, weil JUnit die Testfallinstanzen beibehält. Auch hier kann ich mich nicht mehr an die Details erinnern, aber manchmal lohnt es sich, im Teardown explizites "Variable Nulling" zu haben, so anachronistisch das auch aussieht.

Ich kann allerdings nicht behaupten, dass ich Speicherlecks in Java (oder .NET) regelmäßig als Problem empfunden habe.

Answer 2

Ich würde nicht sagen, dass es häufig vorkommt - Lecks sind in Java sehr selten - aber ich habe schon ein Leck gesehen, das darauf zurückzuführen war, dass ein Verweis auf eine nicht statische innere Klasse gehalten wurde, die die äußere Instanz nicht verwendete, aber trotzdem einen Verweis darauf hielt.

Answer 3

PermGen-Lecks können entstehen durch:

• Daemon-Threads, die am Leben bleiben, nachdem Ihre Anwendung nicht mehr bereitgestellt wird.
• Mit der JVM registrierte Shutdown-Hooks
• ThreadLocal-Variablen, deren Wert einen Verweis auf eine von Ihrem Klassenlader geladene Klasse enthält

Diese sind alle mit Webanwendungen verbunden. Sie kommen in normalen Java-Anwendungen nicht vor.