Hi, eine Frage: Prozess hat Speicherbereich a->b Prozess endet, also a->b ist frei Wozu brauch ich jetzt einen Garbage Collecter ? Gruß Sam
Wenn du mit Prozessen komplette Programminstanzen und deren Prozesse meinst ist das soweit richtig, der komplette Speicherbereich der Anwendung wird geleert nach dem beenden. Anders sieht es aus wenn das Programm noch läuft, hier spart dir ein Garbage Collector (GC) die Arbeit Speicherplatz freizugeben aber was noch wichtiger ist, er hilft dir keinen Speicherplatz zu vergessen. Bei großen Projekten wo man 1000mal eine Variable per Pointer weitergibt weiss nachher eh keiner mehr wer die jetzt freigeben darf oder ob noch irgendwo anders einer den Wert hinter dem Pointer braucht. Wird zu früh aufgeräumt crasht das Programm, räumt es zu spät bis gar nicht auf, so blät es sich auf und setzt schlimmstenfalls das System außer Gefecht.
Sam schrieb: > Wozu brauch ich jetzt einen Garbage Collecter ? Gar nicht. Das Betriebssystem sollte die vom Prozess belegten Resourcen am Ende wieder freigeben. Ausnahmen gibts: AmigaOS hatte kein Resource Tracking, d.h. der Programmierer war dafür verantwortlich, vor dem Programmende alles wieder sauber freizugeben. Garbage erzeugen nur Java-Programmierer, weil diese nur neue Objekte konstruieren, aber nicht wieder manuell zerstören können sollen. Für die Müllbeseitigung ist dort die Runtime gedacht. fchk
Christian Hunke schrieb: > Bei > großen Projekten wo man 1000mal eine Variable per Pointer weitergibt > weiss nachher eh keiner mehr wer die jetzt freigeben darf oder ob noch > irgendwo anders einer den Wert hinter dem Pointer braucht. Was wiederum einen der wichtigsten Kritikpunkte um GC bildet: Sollte ein Programm nicht in der Art strukturiert sein, dass zu keinem Zeitpunkt Zweifel existieren, wer welchen Speicherbereich besitzt und freizugeben hat? Ein Schelm, wer jetzt an faule Programmierer denkt.
P.S. (leider zu spät): Für kleine Tools ist ein GC was feines, es spart Arbeit und der Overhead ist heute meist selbst auf Handys relativ egal ;) Kritisch sind Projekte in Echtzeit, klassischerweise Spiele. Wenn man in jedem von z.B. 60 Bildern pro Sekunde Sachen für den GC erzeugt darf man sich nicht wundern wenn nachher 1 Kern des neuen Multicore Rechners für den GC draufgeht ;)
Sam schrieb: > Prozess hat Speicherbereich a->b jetzt muss ich mal blöd fragen, aber was willst Du damit sagen?
Frank K. schrieb: > Garbage erzeugen nur Java-Programmierer, weil diese nur neue Objekte > konstruieren, aber nicht wieder manuell zerstören können sollen. Für die > Müllbeseitigung ist dort die Runtime gedacht. Das gilt allerdings nur für den Speicher, nicht für andere Ressourcen. Das ist der große Haken am Garbage Collector. Bei C++ kann man z.B. das Handling aller Ressourcen automatisieren (Stichwort "RAII"), aber man muß das eben selbst ausprogrammieren. In Java dagegen wird der Speicher grundätzlich vom GC verwaltet, der Rest muß dann zwangsweise immer manuell verwaltet werden, da einem da die Destruktoren fehlen.
Hi,
noch eins ist unklar
In C:
class Hi
{
int zahl=5;
public:
void ausgabe()
{
cout << zahl";
}
~Hi(){};
In Java gibt es zwei Methoden, die eine
Finalize()
soll schlecht sein, weil der GC eingreift,
Dispose()
soll direkt arbeiten.
Verstehe ich nicht - warum Finalize() benutzen ? Warum gibt es die
Funktion überhaupt ?
... sorry in Java bin ich nicht fit ;)
Gruß
Sam schrieb: > In Java gibt es zwei Methoden, die eine > > > Finalize() > > soll schlecht sein, weil der GC eingreift, Was ist daran schlecht, hinter sich aufzuräumen? Finalize ist genau die Methode, die vom GC noch aufgerufen wird, ehe dann das Objekt den großen Bitabfluss hinuntergeht. Das ist der Zeitpunkt andem ein Objekt noch eine letzte Chance hat hinter sich aufzuräumen (Files zu schliessen, falls das Objekt noch eines in Beschlag hat. Den Drucker wieder freigeben. Handles zu GUI Objekten wieder zurückgeben. etc ....) > Dispose() > soll direkt arbeiten. dispose ist eine Methode aus einem GUI Framework und macht im Grunde dasselbe: Resourcen freigeben. > Verstehe ich nicht - warum Finalize() benutzen ? Weil der Benutzer deiner Library vergessen haben könnte, auf einem Objekt dispose aufzurufe. Beispielsweise. Du vergleichst hier Äpfel mit Birnen. Beide Funktionalitäten machen zwar im Grunde dasselbe, aber zu verschiedenen Anlässen und aus unterschiedlichen Gründen. Dazu kommt, dass sie von verschiedenen Quellen aus aufgerufen werden. Finalize wird vom GC aus aufgerufen, dispose vom Usercode. Der Zweck von Finalize ist es´, dem Objekt eine letzte Chance zu geben, wenn der Usercode dispose nicht aufgerufen hat. Allerdings solltest du jetzt schön langsam in ein Java Forum überwechseln.
Sam schrieb: > Finalize() > > > > soll schlecht sein, weil der GC eingreift, Es kann vor allem nicht garantiert werden, dass die finalize() Methode vom GC überhaupt aufgerufen wird. Auch kann nichts darüber gesagt werden wann der Aufruf erfolgt. Joshua Bloch rät auch aufgrund einiger anderer Probleme mit Finalizers in "Effective Java" dazu finalize() wenn es vermeidbar ist besser nicht zu verwenden ...
klaus schrieb: > Es kann vor allem nicht garantiert werden, dass die finalize() Methode > vom GC überhaupt aufgerufen wird. Doch, der Garbage Collector ruft immer finalize() auf. Es kann aber per default nicht garantiert werden, dass beim Programmende wirklich alle dann noch existierenden Objekte explizit aufgeräumt werden, weshalb ggf. einige Finalizer nicht mehr aufgerufen werden. Entgegenwirken kann man dem mit
1 | System.runFinalizersOnExit(true); |
> Auch kann nichts darüber gesagt werden > wann der Aufruf erfolgt. Das ist der entscheidende Punkt. In vielen Fällen will man externe Ressourcen kontrolliert an bestimmten Stellen im Programm freigeben, z.B. sollen die 5 GB an temporären Dateien sofort gelöscht werden und nicht erst drei Wochen später, wenn die Runtime sich irgendwann mal bequemt den Garbage Collector laufen zu lassen. Letzteres ist nur mit einer explizit aufzurufenden Cleanup-Methode zu erreichen. Andreas
> Entgegenwirken kann man dem mit System.runFinalizersOnExit(true);
"The only methods that claim to guarantee finalization are
System.runFinalizersOnExit and its evil twin,
Runtime.runFinalizersOnExit. These methods are fatally flawed and have
been deprecated" [Effective Java]
"This method is inherently unsafe. It may result in finalizers being
called on live objects while other threads are concurrently manipulating
those objects, resulting in erratic behavior or deadlock. [Java SDK]
=> besser nicht verwenden
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.