Garbage manuell loswerden

[micbur]

Hallo,

ich bekomme bei einem Programm momentan nur noch Speicherfehlermeldungen, dass nicht genügend Speicherplatz vorhanden wäre. Ich kann mir auch vorstellen, dass hier relativ viel Speicher flöten geht. Ich arbeite mit Dateien, in denen etwa 80.000 Zeilen sind, mit je maximal 2 kB Daten.

Davon kommen nicht alle Zeilen in den Speicher. Ich schätze, dass maximal 60.000 Zeilen im Speicher bleiben. Allerdings muss ich mit den Zeilen arbeiten und füge dann einen kleinen Teil in TreeMaps ein.

Zwischendurch gebe ich eine Menge Objekte wieder frei, indem ich die Variablen auf null setze. Ich bin mir aber nicht sicher, ob der Garbage Collector sie dann wirklich entfernt. Mein Programm ist so gestrickt, dass es zwei Phasen gibt, erst wird Speicher verlangt und dann nur noch frei gegeben. Mit den Daten, die nicht freigegeben sind, wird gearbeitet.

Wie kann ich den GC im Programm manuell starten?

Ciao, micbur

 

[Eldaron]

Aufruf von:

System.gc();

 

[lhein]

Wann und ob eine Garbage Collection stattfindet entscheidet die Virtual Machine.
Ein Aufruf von System.gc() kann was bringen, aber es ist imho nix anderes wie eine "Bitte" an die VM, mal den Speicher aufzuräumen. Die VM kann der Bitte nachkommen, muss aber nicht.

Grundsätzlich Abhilfe kann man schaffen, wenn man die VM mit mehr Speicher zugewiesen startet (über -X... Parameter). In der Anwendung Dinge auf null zu setzen ist ne nette Geste von Dir, wird aber je nachdem wie es gemacht ist nicht wirklich viel bringen.
Ein absoluter Memorykiller ist z.B. die JTextArea. Beim Einlesen eines 1 MB Files wird der Verbrauch ca. 2-3 MB sein....wenn das mal reicht

Grüße
lr

 

[AlArenal]

Entweder mehr Speicher zuweisen, oder sich mal in Ruhe ein paar gute Artikel im Netz zum Thema Interaktion mit dem GC durchlesen, auch in Hinsicht auf Soft und Weak References...

 

[Eldaron]

Also nach
http://java.sun.com/docs/books/tutorial/essential/system/garbage.html
kann es Sinn machen, den GC so direkt aufzurufen, und er wird dann auch laufen. Obs wirklich die Probleme in der Anwendung löst, sei dahingestellt.

 

[lhein]

You can ask the garbage collector to run at any time by calling System's gc method:

System.gc();

ask ==> fragen und nicht etwa befehlen

lr

 

[Larouso]

Wann und ob eine Garbage Collection stattfindet entscheidet die Virtual Machine.
Ein Aufruf von System.gc() kann was bringen, aber es ist imho nix anderes wie eine "Bitte" an die VM, mal den Speicher aufzuräumen. Die VM kann der Bitte nachkommen, muss aber nicht.


Grüße
lr

also kann dir da den Rat noch mitgeben den ich aus insider kreisen hab *G* - ja bevor gleich alle auf mich einknüppeln - das kommt wirklich von schlauen köpfen die sich damit beschäftigen ...

es macht wohl einen unterschied, ob du den garbage collector einmal aufrufst, oder ob du ihn bsp. 20 mal hintereinander in einer Schleife aufrufst... er soll in 2tem Fall zu hoher wahrscheinlichkeit dann wirklich ausgeführt werden.

Gruß

 

[lhein]

:bahnhof:

for (int i=0; i<20000; i++)
{
    System.gc();
}

Es heisst zwar der Zweck heiligt die Mittel, aber irgendwo hörts dann glaub doch auf

 

[AlArenal]

Darf ich jetzt auf dich einknüppeln?

Im Ernst:
Von vielen wird ein GC als Vorteil gegenüber der in C/C++ nötigen händischen Speicherverwaltung empfunden. So lange man aber nicht versteht, wie der GC funktioniert, kann man ihn auch nicht ordentlich nutzen. Ihn einer Schleife zigmal die VM zu bitten den GC laufen zu lassen, um evtl. vielleicht die Chance zu erhöhen, dass sie dies tut, kann in der Praxis auch nicht helfen, denn "evtl. vielleicht" ist kein definierter Zustand.

Je nachdem wie "geschickt" man programmiert, kann man den GC auch eine Million Mal um Hilfe bitten und es wird dennoch nichts bringen, weil irgendwo noch irgendwas Referenzen irgendwohin hat. Darum nochmal: Google anwerfen und nachlesen, wie der GC funktioniert, wie man so codet, dass er ordentlich funktionieren kann und wann man wie und wozu Weak, Soft und Phantom References nutzen sollte.

Erst letzte oder vorletzte Woche las ich amüsiert einen Blog-Eintrag eines Entwicklers, dessen Firma Jobs ausgeschrieben hatte und wo nur einer von zehn Bewerbern trotz jahrelanger Java-Erfahrung überhaupt wusste, dass es Soft, Weak und Phantom References gibt, geschweige denn wie man diese nutzt.

 

[Onkel Hatti]

Darf ich jetzt auf dich einknüppeln?

Im Ernst:
Von vielen wird ein GC als Vorteil gegenüber der in C/C++ nötigen händischen Speicherverwaltung empfunden. So lange man aber nicht versteht, wie der GC funktioniert, kann man ihn auch nicht ordentlich nutzen. Ihn einer Schleife zigmal die VM zu bitten den GC laufen zu lassen, um evtl. vielleicht die Chance zu erhöhen, dass sie dies tut, kann in der Praxis auch nicht helfen, denn "evtl. vielleicht" ist kein definierter Zustand.

Je nachdem wie "geschickt" man programmiert, kann man den GC auch eine Million Mal um Hilfe bitten und es wird dennoch nichts bringen, weil irgendwo noch irgendwas Referenzen irgendwohin hat. Darum nochmal: Google anwerfen und nachlesen, wie der GC funktioniert, wie man so codet, dass er ordentlich funktionieren kann und wann man wie und wozu Weak, Soft und Phantom References nutzen sollte.

Erst letzte oder vorletzte Woche las ich amüsiert einen Blog-Eintrag eines Entwicklers, dessen Firma Jobs ausgeschrieben hatte und wo nur einer von zehn Bewerbern trotz jahrelanger Java-Erfahrung überhaupt wusste, dass es Soft, Weak und Phantom References gibt, geschweige denn wie man diese nutzt.

Ähhh, ich weiss es auch nicht...

Kannst du hier bitte kurz erklären, was das ist?

Danke
Hatti

 

[AlArenal]

Understanding Weak References

Reference Objects and Garbage Collection

Java theory and practice: Plugging memory leaks with weak references

Java reference objects make caching easy

Java Tip 79: Interact with garbage collector to avoid memory leaks - Use reference objects to prevent memory leaks in applications built on the MVC pattern

 

[micbur]

... wo nur einer von zehn Bewerbern trotz jahrelanger Java-Erfahrung überhaupt wusste, dass es Soft, Weak und Phantom References gibt, geschweige denn wie man diese nutzt.

Ich dachte, dafür wäre ein Garbage Collector da, damit man halt nichts über Speichermanagement zu wissen braucht. ;-) Nein aber im ernst, wenn man nicht wirklich Endlosprogramme schreibt (Server, ...). I.d.R. sehe ich keine Heapsize-Blabla-Fehlermeldungen. Ist aber halt doof, wenn man gerade mit Dateien arbeitet, die so groß sind.

Ciao, micbur

 

[Leroy42]

es macht wohl einen unterschied, ob du den garbage collector einmal aufrufst, oder ob du ihn bsp. 20 mal hintereinander in einer Schleife aufrufst

:shock:
Ein tolles Verhalten! Soll ich jetzt zur Sicherheit nur noch so proggen?

...
int tries = 0;
do {
  solution = 42;
  tries++;
} while (solution != 42 && tries < 1000000);
if (solution != 42)
  throw new IchGebsAufException("Interpreter will heut' nicht");
...

Dazu fällt mir die Beschreibung einer dieser esoterischen Sprachen ein,
bei denen die Ausführung jeder Anweisung nur mit einer gewissen
Wahrscheinlichkeit das gewünschte Ergebnis bewirkt. Komme jetzt
nicht drauf wie die heißt...

 

[Leroy42]

Understanding Weak References
Reference Objects and Garbage Collection
Java theory and practice: Plugging memory leaks with weak references
Java reference objects make caching easy
Java Tip 79: Interact with garbage collector to avoid memory leaks - Use reference objects to prevent memory leaks in applications built on the MVC pattern

Respekt, daß du das alles gelesen hast und auch auf Anhieb darauf verweisen kannst.
Aber könntest du dir vielleicht ein paar Zeilen abringen, um uns faules Pack zumindest
eine Idee zu geben, warum das

Ich dachte, dafür wäre ein Garbage Collector da, damit man halt nichts über Speichermanagement zu wissen braucht.

scheinbar nicht zutrifft. :shock:

Zumindest hatten die GCs der Lisp-Implementierungen nie sowas wie soft-, weak-, meak- oder gar
Phantom-Referenzen gebraucht.

Wenn ich, anhand ein paar Stichwörtern, erspüren kann, daß es tatsächlich
Situationen geben kann, bei denen ein GC alleine überfordert ist, kämpfe ich mich
auch gerne durch deine Links. :###
Ich schwöre, Alter! :meld:

 

[clemson]

[OT]

Dazu fällt mir die Beschreibung einer dieser esoterischen Sprachen ein, bei denen die Ausführung jeder Anweisung nur mit einer gewissen Wahrscheinlichkeit das gewünschte Ergebnis bewirkt. Komme jetzt nicht drauf wie die heißt...

meinst du vielleicht Java2K???
[/OT]

 

[Leroy42]

Genau die war's

Manchmal frage ich mich wirklich, ob die Natur, bei unseren
Nachfolgern, wenigstens aus ihren Fehlern lernt. :?

 

[AlArenal]

Ehrlich gesagt muss ich den Kram mitunter auch öfter lesen. Ich versuche nach Möglichkeit auch aus Fehlern anderer zu lernen, kann aber nicht immer direkt allen bereits vorhandenen Code verbessern. D.h. ich komme vielleicht bei einem neuen Projekt auf solche Artikel zurück, um dort von Beginn an besser zu arbeiten..

Zu dem Beispiel:
Der letzte Link (Tip 79) bgeinnt direkt mit einem praktischen Beispiel aus der Welt des Swing MVC mit einer Anwendung, die irgendwann mal einen zusätzlichen JFrame aufmacht, in dem eine Swing MVC Komponente hockt:

When you close the frame, its dispose method is called. In this example, you could easily remove the VectorListFrame from the data model's listeners list. All you need to do is keep a reference to the VectorModel. Then you could call the model's removeListener method from within the view's dispose method (see the code that has been commented out for the implementation).

However, things might not be this simple in a real-world application. The view that is listening to the data model might be deeply nested in a containment hierarchy. To remove it from the model's listeners list, the top-level frame would need to keep a reference to both the model and its view. This is a very error-prone business tactic, and makes for ugly, difficult-to-maintain code. If you forget just one model/view pair, you create a lapsed listener and memory will be leaked. You therefore want a data model that removes lapsed listeners automatically.

 

[Gelöschtes Mitglied 5909]

kann man des net auch mit finallize() machen?
oder halt einfach die referenz null setzen...
hab mich mim gc auch noch net so beschäftigt sein, aber sollte doch einigermaßen reichen...

 

[lhein]

Die finalize() methode wird beim Aufräumen des Objects aufgerufen und das ist genau dann, wenn es vom GC gelöscht wird. Das ganze sollte nur dann verwendet werden, wenn man spezielle Aufräumarbeiten erledigen muss.

lr

 

[Leroy42]

...

Dazu eine Frage der Art:

Jetzt stellen wer uns mal janz blöd; Dett is een schwarzer Kasten...

Ist das dann nicht schlichtweg ein Designfehler der Klassen?

Immerhin beläßt der JVM-GC nur die Objekte, die nicht von einer der Basis-Objekte
erreicht werden können. Damit fliegen auch schonmal alle isolierten, zirkulär
referenzierten Objekte raus.

Ohne in Details zu gehen, kann es also keine Lücken im System geben
(== kann es nicht sein, daß Lücken nicht zu vermeiden sind).

 

[Larouso]

Darf ich jetzt auf dich einknüppeln?

Im Ernst:
Ihn einer Schleife zigmal die VM zu bitten den GC laufen zu lassen, um evtl. vielleicht die Chance zu erhöhen, dass sie dies tut, kann in der Praxis auch nicht helfen, denn "evtl. vielleicht" ist kein definierter Zustand.

ich sagte auch nie dass das ein sicherer Weg wäre... nur wurde mir von den leuten eben berichtet... die nebenbei Hochschulprofessoren sind und sich gerade mit dem Problem beschäftigten... und in deren studien kam eben raus dass sich die wahrscheinlichkeit extrem erhöht das der gc anläuft wenn du in ner schleife drüber gehst, wie wenn dus einmal aufrufst, dass das dann wirklich kommt... kann das auch nicht garantieren, aber ne höhere wahrscheinlichkeit ist schon mal besser wie nichts oder?

 

[Leroy42]

als :x :x :x

 

[AlArenal]

Ist das dann nicht schlichtweg ein Designfehler der Klassen?

Wenn du mit Designfehler meinst, dass die Leute sich zu wenig mit gem GC beschäftigen und damit ihre Anwendungen ggf. unnötig in Schwierigkeiten bringen: ja.

Unkenntnis führt nunmal zu Fehlern.

ich sagte auch nie dass das ein sicherer Weg wäre... nur wurde mir von den leuten eben berichtet... die nebenbei Hochschulprofessoren sind und sich gerade mit dem Problem beschäftigten... und in deren studien kam eben raus dass sich die wahrscheinlichkeit extrem erhöht das der gc anläuft wenn du in ner schleife drüber gehst, wie wenn dus einmal aufrufst, dass das dann wirklich kommt...

Dafür hätte es keine Studien gebraucht. Dass sich die Wahrscheinlichkeit mal wegen überhöhter Geschwindigkeit geblitzt zu werden erhöht, wenn man eben öfter und mehr fährt, sollte analog dazu auch einleuchten.

kann das auch nicht garantieren, aber ne höhere wahrscheinlichkeit ist schon mal besser wie nichts oder?

Nicht wirklich. Ich kann Kunden bei Problemen mit unserer Software nämlich schlecht weismachen, dass sie nunmal einfach nur gerade Pech hatten, weil ich irgendwas in der Software eingebaut habe, das häufiger mal funktioniert, aber leider nicht vorhersagbar ist... Ich hoffe die Entwickler bei meiner Bank sehen das ähnlich, nicht dass irgendwann meine Kohle flöten ist, weil irgendwo ne "relativ unwahrscheinliche" OutOfMemoryException geworfen wurde.

Obwohl es nicht schlehct wäre, wenn das ganze viele Minusgeld mal weg wäre..

 

[Leroy42]

Oder eingehämmert, damit es hängen bleibt:

Meine Tochter ist älter wie ich :shock:
Richtig? Falsch?
Falsch: Es muß heißen:
Unsere Stubeneintagsfliege ist jehr jung: Meine Tochter ist älter, wie ich :shock:
Jetzt alles klar?

 

[micbur]

Definitiv emfinde ich meine Frage als 'beantwortet', auch wenn ich jetzt den Button zum Markieren nicht finde.

Danke & Ciao @ all, micbur

 

[Leroy42]

Dass sich die Wahrscheinlichkeit ...erhöht, wenn man eben öfter...

Genau! Aus diesem Grund, nehm ich bei Flugreisen auch immer eine Bombe mit.

Die Wahrscheinlichkeit, daß im Flugzeug ein Terrorist mit Bombe mitfliegt ist zwar
sehr gering. Aber die Wahrscheinlichkeit, daß in ein- und demselben Flugzeug
gleich 2 Bomben sind ist nur noch verschwindend.

Da fühle ich mich schon viel sicherer

Ok, der ist uralt. Aber paßte g'rad so schön

 

[lhein]

Jau, und wenn man mehr Lottoscheine abgibt, erhöht sich theoretisch auch die Gewinnchance
Schon nicht übel, was so ein Professor alles rausbekommt. Im Bundestag hätte man dafür wahrscheinlich erstmal ne Arbeitsgruppe eingerichtet. Die Profs kriegen das auch so hin

lr

 

[Leroy42]

Jau, und wenn man mehr Lottoscheine abgibt, erhöht sich theoretisch auch die Gewinnchance

Ähmm, theoretisch ???:L

Die erhöht sich tatsächlich. Ich verstehe nicht ganz den Zusammenhang zu
meinem Bomben-Beispiel (Geht um den Unterschied zwischen absoluter
und bedingter Wahrscheinlichkeit, der im Alltagsbauchgefühl schnell verwischt)

 

[Novanic]

Hm, mich würde ja mal interessieren, wie das bei solchen Programmen wie IntelliJ IDEA, SQurielL und ich glaub eclipse hat sowas auch, läuft.
Da gibt es so eine kleine Speicheranzeige (wieviel Speicher das Programm gerade verwendet) und daneben ein kleines Mülleimer-Symbol, mit dem man per Mausklick den Garbage-Collector anstößt. Den Effekt kann man dann direkt in der Speicheranzeige beobachten.

Wie stoßen die denn den Garbage-Collector intern an? Und gibt es so ein Teil schon fertig (Framework, Tutorial oder so) oder muss man sich sowas selber proggen?

Gruß Nova

 

[Larouso]

Jaja ... macht euch nur lustig ich bin euch da nicht böse *G* - nur hilft die Aussage dass es n Designfehler ist... usw. nun leider auch nicht mehr, wenn das Kind schon im Bunnen liegt. Das man von vorn herein so designen soll, dass das Problem nicht auftritt, ist mir schon selber klar...

Zu der erwähnten Studie: lol also es ging wohl kaum nur um die Berechnung der erhöhten wahrscheinlichkeit bei neim Schleifen-Call des GC, als vielmehr um die Speicherverwaltung allgemein - aber ich will euch ja euren Spaß nicht verderben Ich selbst würd mein Geld auch gern mit solchen Sachen verdienen können, anstatt mich mit DAU-Chefs rumzuschlagen, und bin desswegen euren Frotzeleien ja gar nicht so abgeneigt.

Aber falls da jmd ne Antwort zu der obigen Frage hat, würd mich ebenfalls sehr interessieren ...

. Dass sich die Wahrscheinlichkeit mal wegen überhöhter Geschwindigkeit geblitzt zu werden erhöht, wenn man eben öfter und mehr fährt, sollte analog dazu auch einleuchten. icon_wink.gif

Ja logisch leuchtet das ein, leuchtet aber auch ein dass es keinen unterschied im Ergebnis macht, ode? Nur dass ich eben nahezu jeden Blitzer mitnehme der auf der strecke steht, anstatt vielleicht nur einen Also wo ist das Problem, nochmals ich sage nicht dass das das vorgehen ist, dass man wählen soll, aber bevor du komplett redesignst, wenns gar keine kritische Anwendung ist...