Announcement

Collapse
No announcement yet.

JM06.06 Leben und sterben lassen

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • JM06.06 Leben und sterben lassen

    Hallo,
    im Artikel "Leben und sterben lassen" des JM 06.06 steht auf Seite 18:

    "Gut, man kann immer noch Speicherlecks produzieren, indem man z.B. nicht
    mehr benötigte Objekte in irgendwelchen Collections vergisst oder...."

    Mir ist nicht ganz klar, wie das zu verstehen ist? Angenommen ich lege ein
    JMenuBar an und hänge dort viele JMenu ein. Später lösche ich die JMenuBar,
    habe ich dann durch die darin eingehängten JMenu Speicherlecks produziert, weil
    ich diese JMenu vorher nicht explizit gelöscht und auf Null gesetzt habe?
    Und macht es einen Unterschied, ob ich eine Liste mit irgendwelchen Objekten
    befülle und dann die Liste lösche. Habe ich dann auch Speicherlecks produziert,
    weil ich deren Inhaltsobjekte nicht direkt gelöscht habe? Sprich muss ich beim
    Löschen von Listen da immer zuerst durchiterieren, bzw. ein "clear()" aufrufen,
    damit ich keine Speicherlecks produziere?
    Kann mir als Anfänger das mal jemand erklären?
    Besten Dank schon mal...
    Gruß Piet

  • #2
    Nein, mußt Du nicht. Wenn Du die Liste "löscht" (d.h. wenn sie nicht mehr refenziert wird) und die Objekte in der Liste nicht noch von woanders referenziert werden, dann ist die Liste inklusive Inhalt ein Kandidat für den Garbage Collector.

    Ohne den Artikel gelesen zu haben, Memory Leaks in Java treten v.a. in globalen Collections auf. D.h. die Collection wird nie gelöscht, man kann aber nach Belieben Objekte reinstopfen und wieder löschen (das löschen wird oft vergessen). Beispiele sind der ServletContext in einer Webanwendung oder ein statischer Cache. Sehr beliebt ist auch das "lapsed listener"-Problem in GUI-Anwendungen (siehe z.b. http://www.ibm.com/developerworks/java/library/j-jtp07265/index.html ).

    Memory leaks treten auch gerne in Verbindung mit Classloadern auf. Z.b. wird in Applikationsservern für eine Anwendung ein extra Classloader erzeugt. Wird nun die Anwendung undeployed, so wird der Classloader gelöscht. Existiert noch irgendwo eine Referenz auf irgendeine Klasse die von diesem Classloader geladen wurde (z.b. in einem globalen JDBC DriverManager o.ä.), dann kann der Classloader inklusive aller von ihm geladenen Klassen nicht garbage collected werden.

    Gruß, Alwi

    Comment


    • #3
      hi alwin,

      dein link geht bei mir nicht. stimmt der

      Comment


      • #4
        Ja stimmt, habs eben probiert

        Comment

        Working...
        X