JFrame entfernen

[Michael Schyroky]

Hallo,

ich habe das Problem, dass ich ein mit "dispose()" geschlossenes Fenster nicht mehr aus dem Speicher der VM entfernen kann.

Zuvor habe ich alle Referenzen der sich auf dem JFrame befindlichen Komponenten entfernt ,die Komponenten auf "null" gesetzt und den "GarbageCollector" mehrfach aufgerufen.
Die Komponenten wurden hierbei "entsorgt" nur das "JFrame" nicht.

Auch der zu Beginn gesetzte Aufruf von "setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE) ;" bringt nicht das gewünscht Ergebnis.

Hat jemand eine Idee, was ich noch tun kann?

Danke und Grüsse

Michael Schyroky

[Stefan W. Wagner]

a) Wieso möchtest Du überhaupt den JFrame aus dem Speicher entfernen?

b) Die Komponenten zu entfernen ist m.E. der falsche Weg. Eine Liste kann ich auch nicht dadurch aus dem Speicher entfernen, in dem ich alle Objekte aus der Liste lösche.
Selbst wenn die Objekte noch benutzt werden wird die Liste zur GC freigegeben, wenn es keine erreichbare Referenz auf die Liste mehr gibt.

c) Den Garbage-Collector selbst aufzurufen ist auch seltenst eine sinnvolle Beschäftigung

d) Wenn der WindowListener noch eine Referenz auf den JFrame hat (und so sieht es ja aus), dann wäre es falsch, den JFrame aus dem Speicher zu entfernen. Wir wollen ja keine NullpointerException

[Michael Schyroky]

Hallo Stefan,

dank' Dir für Deine Antwort.

Zu a) Das JFrame möchte ich aus dem Speicher entfernen, da ich eine Anwendung mit etlichen JFrames habe. Habe ich z.B. 20 JFrames geöffnet, benötigen diese alle neuen Speicher und es kommt dann irgendwann zu der geliebten OutOfMemoryException.
Deshalb möchte ich direkt nach dem Schliessen einer Maske diese auch wieder aus dem Speicher entfernen.

Zu b) Warum der falsche Weg? Wenn die Komponenten entfernt und auf NULL gesetzt werden, werden sie beim nächsten Lauf des GC eingesammelt und deren Speicherplatz wieder freigegeben - genau das, was ich möchte.

Zu c) Funktioniert aber. Somit habe ich ein wenig Einfluss auf das Aufräumen des GC. Es soll nicht erst dann aufräumt werden, wenn der GC aufgrund der OutOfMemoryException gestartet wird, sondern wenn ein JFrame geschlossen wird.

Zu d) Würde das JFrame aus dem Speicher entfernt, wenn ich alle Listener (inkl. des WindowListeners) des JFrames "remove" und dann das JFrame auf NULL setze?

Gruss

Michae

[Stefan Gawlick]

Hallo Michael,

ich bin mir ziemlich sicher, daß es kein Problem von Swing oder AWT (speziell des JFrame) ist, sondern daß Du ungewollt ein Speicher-Leck in Deinem Programm eingebaut hast.

Ich vermute, irgendwo in Deinem Programm werden noch Referenzen auf Deine Fenster gehalten, obwohl sie bereits geschlossen und irrelevant geworden sind. Das JFrame-Objekt wird dann im Speicher gehalten und kann von der Garbage Collection nicht weggeräumt werden.
Vielleicht ist bei Dir die Implementierung der View-Controller-Beziehungen nicht ganz sauber (Vieleicht Listener, die "tote" Fenster beobachten?).

Übrigens:
- Wenn es zu einer OutOfMemoryException kommt, ist es bereits zu spät, die Garbage Collection kommt dann gar nicht mehr zum Zug.
- Du kannst den Garbage Collector nicht wirklich selbst starten; Du kannst nur "den Wunsch äußern, daß er möglichst bald gestartet wird"
- In aller Regel sollte man den Garbage Collector nicht selbst aufrufen. Wenn man Speicherprobleme hat, kann das zwei Ursachen haben: Zum einen kann es sein, daß man schlicht und einfach sehr viele Objekte gleichzeitig im Speicher benötigt. Dann muß man der VM über ihren Startparameter entsprechend viel Speicher zur Verfügung stellen. Zum anderen kann es sein, daß man Objekte hält, die man eigentlich gar nicht mehr braucht (Speicher-Leck). Dann kommt man eh nicht drum herum, den Code zu bereinigen, da alles anderes nur den Zeitpunkt der OutOfMemoryException hinauszögern würde (oder man ihr nur mit Glück selbst mit dem unsauberen Code entkommt).

In der Hoffnung, geholfen zu haben,
Stefa

[Michael Schyroky]

Hallo Stefan,

erst einmal danke für Deine Antwort.

So wie es aussieht, werde ich wohl nicht drum herum kommen den unsauberen Code zu bereinigen und die Speicher-Lecks zu beheben. Wird wohl 'ne Menge Arbeit.

Gruss

Michae