Speicherverlust fallen in der Java-Standard-API

, Welche Klassen des Java-Standard-API können zu Speicherverlusten, wenn in einer (nicht offensichtlich) falschen Weg? Und wie können diese Speicherverluste werden vermieden/behoben?

Beispiel: ObjectInputStream und ObjectOutputStream halten Referenzen auf alle Objekte, die Sie gesehen haben, um zu senden, spätere vorkommen des gleichen Objekts als Referenzen statt Kopien (und damit befassen sich mit zirkulären Referenzen). Dies verursacht einen Speicherverlust, wenn Sie halten wie einen stream öffnen auf unbestimmte Zeit (z.B. wenn es um die Kommunikation über das Netzwerk).

Update: Rufen Sie reset (), die periodisch oder nach jeder top-level-Objekt.

  • vielleicht bewegen Sie Ihr Beispiel, um eine Antwort von sich selbst?
InformationsquelleAutor Michael Borgwardt | 2009-08-15
  1. 48

    Groß ist, dass immer Teilstrings von Java-strings bezieht sich auf die ursprüngliche Zeichenfolge.

    Beispiel: Sie Lesen in einem 3000-Zeichen-record und erhalten eine Teilfolge von 12 Zeichen, zurück an den Aufrufer (innerhalb der gleichen JVM). Auch wenn Sie nicht direkt einen Verweis auf die ursprüngliche-Zeichenfolge, die 12-stellige Zeichenfolge ist immer noch mit 3000 Zeichen im Speicher.

    Für Systeme, die empfangen und dann analysieren eine Vielzahl von Nachrichten, kann dies ein echtes problem sein.

    Haben Sie ein paar Möglichkeiten, dies zu vermeiden:

    String sub = new String(str.substring(6,12));

    oder

    String sub = str.substring(6,12).intern();

    Den ersten mehr abgeholzt. Die zweite hat das andere Auswirkungen, weil Sie mit der PermGen space. Überstrapaziert Sie laufen konnte, es sei denn, Sie geben Ihre VM genug.

    Denken Sie daran dies ist nur relevant, wenn Sie sind in kleinen Teilfolgen und dann werfen Sie die original-string und Sie tun dies eine Menge.

    • Wie über die Erwähnung eine einfache Lösung, wie das anlegen eines neues String-Objekt explizit?
    • Nicht zu stoßen, ein sehr Alter thread, aber, was ist der Grund dafür? Warum sollte diese Zeile "str = str.substring(6,12)" Abfall-ein Raum der 3k-Zeichen, anstelle von nur 6?
    • stoßen ein Alter Kommentar: weil es intern bezieht sich auf die gleiche char-array als die ursprüngliche Zeichenfolge ist, nur mit einem anderen offset und Länge. Wenn Sie eine Menge von überlappenden Teilstrings, es tatsächlich spart Speicher.
    • Vielen Dank Michael, es ist jetzt klar.
    • +1: ich würde sagen, dies ist einer der größten "fallen" zu fallen, in die in der JDK... nahm mich Weg zu lang, um festzustellen, es war der Grund, warum meine webcrawler war undicht, die gesamte HTML-Quellcode von jeder Seite, die es sah. Im ernst, Sun/Oracle... wenn du gehst, um eine "Optimierung" Nebenwirkung dieses ernste, sagen Sie wenigstens etwas darüber in Dokumentation
    • Oh, und es ist sogar noch schlimmer, es trifft dich immer dann, wenn Sie andere API, die basiert auf substring() intern, wie das Zeug in java.util.regex.
    • Ich überprüfte den Quellcode von String#substring, es wird eine neue Zeichenfolge und kopieren Sie eine Reihe von internen char[]. Ich bin mit jdk7, vielleicht ist das behoben?
    • Ja: stackoverflow.com/a/16123681/452775

    InformationsquelleAutor cletus
  2. 8

    Alles, was Sie sich als Empfänger einer Veranstaltung, z.B. in GUI-frameworks,
    kann nicht sein, Müll gesammelt, solange es registriert ist und die Quelle
    ist lebendig.

    Diese einführen können Speicherlecks, wenn ein Entwickler nicht bewusst, dass
    starke Referenz von der Quelle zu den Ereignis-Abonnenten.

    • Es ist eine gute Idee, um die Verwendung schwacher Referenzen für Hörer, die erwartet wird, länger zu Leben als das, was es hört.
    • Dies ist fast das standard-Beispiel für ein memory leak, weil es offensichtlich ist, aber dennoch einfach zu vergessen.
    InformationsquelleAutor Black
  3. 7

    Alle nicht-statischen inneren Klassen, die Sie machen, halten Sie äußere Klassen. So, dass unschuldig aussehende innere Klasse zu halten, kann auf eine riesige Objekt graph. Legen Sie die Instanz in einer statischen oder Anwendung-große Sammlung irgendwo, und Sie sind mit einem viel von Speicher, den Sie sind eigentlich nicht zu verwenden.

    InformationsquelleAutor krosenvold
  4. 5

    Jede Instanziierung eines Threads reserviert Speicher für einen Stapel (Standard 512k, abstimmbar über -Xss). Es ist nicht ein Leck als solche, aber naive Versuch, stark multi-thread einer Anwendung resultiert in einem beträchtlichen nicht-offensichtliche Verbrauch von Arbeitsspeicher.

    • Tatsächlich, kann es zu einem völligen Auslaufen, wenn Sie erstellen, Thread-Objekte und nie Aufruf der start() - der stack-Speicher ist dann nicht zurückgefordert, wenn ich mich Recht erinnere.
    • Interessant. Wusste nicht, dass.
    • Borgwardt: ich glaube nicht, dass das der Fall ist, haben Sie eine Quelle? [edit]: es sieht aus wie es sich möglicherweise um einen bug in älteren Versionen von JVM, sollte aber behoben werden in Java 5.
    InformationsquelleAutor Brian Agnew
  5. 4

    Jede Klasse mit der dispose () - Methode?

    Beispielsweise java.das awt.Fenster#entsorgen:

    public void entsorgen()

    Versionen aller nativen Bildschirm-Ressourcen verwendet, die von diesem Fenster seiner Unterkomponenten, und all seinen Besitz Kinder. Das heißt, die Ressourcen für diese Komponenten zerstört werden wird, jede Erinnerung, die Sie verbrauchen, wird an das Betriebssystem zurückgegeben, und Sie wird als solche gekennzeichnet werden undisplayable.

    InformationsquelleAutor dfa
  6. 3

    Verwendung von starken Referenzen, wenn schwache Referenzen ausreichend gewesen wäre. Anwendung und APIs, führen Sie Ihren eigenen Staat-und Ressourcen-management sind die üblichen Schuldigen hier.

    Dann, es ist die Verwendung des Observer-Musters, was dazu führen könnte, memory leaks - wenn der Beobachter delists sich aus dem Gegenstand, der Speicher kann nicht zurückgefordert werden, es sei denn, das Thema löst auch der Verweis auf die Betrachter/Hörer. Dies wurde bereits darauf hingewiesen, früher, aber nicht viele Menschen wissen, dass sogar Holzfäller sind Beobachter.

    Darüber hinaus dort ist die Wahrscheinlichkeit von Klassen, deren Objekte bei der instanziert werden automatisch in eine statische member. Einige dieser Klassen haben noch nicht einmal ein release() oder dispose () - Methode, so die Referenzen, die weiterhin gehalten werden durch die static-member. Diese Sorte von Speicher-Lecks resultiert schließlich in einer OutOfMemory-Fehler mit einem PermGen space Ausgabe berichtet, als die Ursache, so dass es schwieriger zu diagnostizieren.

    InformationsquelleAutor Vineet Reynolds
Schreibe einen Kommentar