RCP Application, mit der Zeit JavaOutOfMemoryException

[Koringar]

Hi,

ich habe eine Anwendung die permanent Daten aus einer Tabelle ausliest (in bestimmten Intervalen). Wenn man die Anwendung nun über Nacht oder länger laufen lässt bekommt man irgend wann unwillkürlich auf eine JavaOutOfMemoryException.

Die Daten werden als Datenobject in einer java.util.List gehalten. Ein dispose gibt es bei dennen Klassen ja nicht, das remove eines Objectes entfernt nur die Reference zum Object. Und ein explizites setzen auf null des Objectes in der Liste bringt auch nicht viel.

Deshalb meine Frage kann ich die Datenmenge von Hand bereinigen oder gibt es da schon irgend welche funktionen, damit das nicht mehr auf tritt (also sowas wie der GarbageCollector)?

Würde mich sehr um Antwort freuen, da die Antwendung wirklich am Ende ununterbrochen laufen wird.

MfG Koringar

 

[Kaffeebohn]

Wenn du ein Objekt entfernst und dieses somit nicht mehr referenziert ist, sollte der GarbageCollector es mit der Zeit doch entfernen? Kann es sein dass es noch an anderer Stelle referenziert ist?

 

[Koringar]

Hi,

also eine andere Referenz auf das Objekt gibt es eigentlich nicht, zumindest weis ich nichts davon.
Ich habe es auch einfach mal als Test über Nacht laufen und es ist immer das selber Ergebeniss das der Speicher (der Anwendung) merklich größer ist als am Anfang.

 

[Gast2]

Java 6(JDK) hat einen Profiler damit kannst du schauen was alles im Speicher gehalten wird.

 

[Koringar]

Hi SirWayne,

welchen Profiler meinste du? Ich habe jetzt mit der JConsole und Jvisualvm mir das Programm an geschaut und übernacht auch laufen lassen. Und ich sehe damit nur das der Speicher wirklich voll läuft und das an der Stelle wie ich das Vermude.

Vielleicht kann mir da einer Helfen, entweder wie man die Objekte frei gibt, denn der GarbageCollector macht es nicht wirklich(oder da sind noch irgend welche Refencen auf die Objekte).

Also hier mal die Grundsätzliche vorgehensweise:

1. Der GUI Thread wird Intialisiert und erzeugt eine View mit einem ListViewer und eine java.util.List für die Datenhaltung.
2. Die List wird an einen Job gegeben der sie mit Daten füllt und dann den GUI Thread informiert (über JobChangeListener) das er fertig ist.
3. Der GUI Thread macht ein Refresh auf den Viewer und zeigt den Inhalt der Liste an.

Bei aktualisieren wird vorher der Inhalt der Liste removed (ein explizietes Setzten des Inhalten auf Null, führt auch zum Speicher überlauf) und dann eben neu gefüllt vom Job.


Gibt es da vielleicht noch irgend was, was ich nicht beachtet habe (was eventuell die Reference hält) z.B. dem Viewer sagen das er die Reference wegschmeißen soll oder sowas in der Richtung. Ich habe da wirklich keine Ahnung und würde gern das Problem beheben.

MfG Koringar

 

[Gonzo17]

Ich kenne mich da recht wenig aus, aber vielleicht hilft es den zugewiesenen Arbeitsspeicher zu erhöhen. Zumindest um mal zu schauen, ob es ins "unendliche" läuft oder irgendwann sowieso nicht mehr steigt. Für ne RCP Anwendung kannst du das in deinem Product unter "Launching" in den VM Arguments:

-Xms40m
-Xmx512m

 

[Gast2]

Hi SirWayne,

welchen Profiler meinste du? Ich habe jetzt mit der JConsole und Jvisualvm mir das Programm an geschaut und übernacht auch laufen lassen. Und ich sehe damit nur das der Speicher wirklich voll läuft und das an der Stelle wie ich das Vermude.

Vielleicht kann mir da einer Helfen, entweder wie man die Objekte frei gibt, denn der GarbageCollector macht es nicht wirklich(oder da sind noch irgend welche Refencen auf die Objekte).

Also hier mal die Grundsätzliche vorgehensweise:

1. Der GUI Thread wird Intialisiert und erzeugt eine View mit einem ListViewer und eine java.util.List für die Datenhaltung.
2. Die List wird an einen Job gegeben der sie mit Daten füllt und dann den GUI Thread informiert (über JobChangeListener) das er fertig ist.
3. Der GUI Thread macht ein Refresh auf den Viewer und zeigt den Inhalt der Liste an.

Bei aktualisieren wird vorher der Inhalt der Liste removed (ein explizietes Setzten des Inhalten auf Null, führt auch zum Speicher überlauf) und dann eben neu gefüllt vom Job.


Gibt es da vielleicht noch irgend was, was ich nicht beachtet habe (was eventuell die Reference hält) z.B. dem Viewer sagen das er die Reference wegschmeißen soll oder sowas in der Richtung. Ich habe da wirklich keine Ahnung und würde gern das Problem beheben.

MfG Koringar

Ich hab mit dem JProfiler noch nicht viel gemacht. Musst halt mal bissl googlen. Aber ich denke du siehst bestimmt worauf deine Objekte noch Refernzen haben. Auf irgendwas müssen sie es ja haben sonst würde der GC sie schon bereinigen.

 

[Koringar]

Hi,

also ich habe die VM jetzt mit den Argumenten

-Xms40m
-Xmx512m

gestartet. Jedoch war der Speicher fresser wo anders, der ListViewer war die Schuld. Beim neu setzten des Inhalten hat er anscheinend immer irgend was hinterlassen, ka was. Ich habe das jetzt etwas anders gemacht bei neusetzen des Inhaltes, ich lass mir jetzt die Liste geben und rufe vor dem neusetzen explizit List.clearAll() und schubs der CB bereinigt jetzt wirklich alles.

Ich habe mir auch mal den Code des ListViewer angeschaut und so wie ich den Code verstanden habe sollte er beim Refresh eigentlich das selbe mache, aber wie gesagt irgend was scheint er zurück zulassen.

MfG Koringar