it-swarm.com.de

Was passiert WIRKLICH, wenn Sie nach dem Malloc nicht befreien?

Das hat mich schon seit Ewigkeiten gestört.

Wir werden alle in der Schule unterrichtet (zumindest war ich es), dass Sie jeden Zeiger freigeben MÜSSEN, der zugewiesen wird. Ich bin allerdings ein bisschen neugierig, was die Kosten angeht, wenn man keinen Speicher freigibt. In einigen offensichtlichen Fällen, beispielsweise wenn malloc innerhalb einer Schleife oder eines Teils einer Thread-Ausführung aufgerufen wird, ist es sehr wichtig, sie freizugeben, damit keine Speicherverluste entstehen. Beachten Sie jedoch die folgenden zwei Beispiele:

Erstens, wenn ich Code habe, ist das ungefähr so:

int main()
{
    char *a = malloc(1024);
    /* Do some arbitrary stuff with 'a' (no alloc functions) */
    return 0;
}

Was ist das eigentliche Ergebnis hier? Ich denke, dass der Prozess stirbt und der Heap-Raum dann ohnehin verschwunden ist, sodass es nicht schaden kann, den Aufruf von free zu verpassen. Bin ich in diesem Denken richtig?

Zweitens, ich habe ein Programm, das sich ein bisschen wie eine Shell verhält. Benutzer können Variablen wie aaa = 123 deklarieren. Diese werden in einer dynamischen Datenstruktur zur späteren Verwendung gespeichert. Es liegt auf der Hand, dass Sie eine Lösung verwenden, die eine * Allocation-Funktion (Hashmap, verknüpfte Liste usw.) aufruft. Für diese Art von Programm ist es nicht sinnvoll, jemals nach dem Aufruf von malloc frei zu gehen, da diese Variablen zu jeder Zeit während der Programmausführung vorhanden sein müssen und es keinen guten Weg gibt (was ich sehen kann), der dies mit statisch zugewiesenem Speicherplatz implementiert. Ist es ein schlechtes Design, eine Menge Speicher zu haben, der zugewiesen, aber nur als Teil des Prozesses freigegeben wird? Wenn ja, was ist die Alternative?

470
Scott

Nahezu jedes moderne Betriebssystem stellt den zugewiesenen Speicherplatz wieder her, nachdem ein Programm beendet wurde. Die einzige Ausnahme, die ich mir vorstellen kann, ist etwas wie Palm OS, bei dem der statische Speicher und der Laufzeitspeicher des Programms fast identisch sind. Wenn Sie das Programm nicht freigeben, kann dies dazu führen, dass das Programm mehr Speicherplatz beansprucht. (Ich spekuliere hier nur.)

Im Allgemeinen gibt es keinen Schaden, außer den Laufzeitkosten, wenn mehr Speicherplatz benötigt wird, als Sie benötigen. In dem von Ihnen gegebenen Beispiel möchten Sie sicherlich den Speicher für eine Variable behalten, die verwendet werden kann, bis sie gelöscht wird.

Es gilt jedoch als guter Stil, Speicherplatz freizugeben, sobald Sie ihn nicht mehr benötigen, und alles, was Sie beim Programmende noch haben, freizugeben. Es ist eher eine Übung, zu wissen, welches Gedächtnis Sie verwenden, und darüber nachzudenken, ob Sie es noch brauchen. Wenn Sie nicht den Überblick behalten, haben Sie möglicherweise Speicherlecks.

Auf der anderen Seite hat die ähnliche Mahnung, Ihre Dateien beim Beenden zu schließen, ein viel konkreteres Ergebnis - wenn Sie dies nicht tun, werden die Daten, die Sie geschrieben haben, möglicherweise nicht gelöscht, oder wenn es sich um eine temporäre Datei handelt, sind sie möglicherweise nicht werden gelöscht, wenn Sie fertig sind. Auch für Datenbank-Handles sollten die Transaktionen festgeschrieben und dann geschlossen werden, wenn Sie damit fertig sind. Wenn Sie eine objektorientierte Sprache wie C++ oder Objective C verwenden, bedeutet dies nicht, dass der Destruktor nie aufgerufen wird, wenn ein Objekt nicht freigegeben wird, wenn Sie damit fertig sind. Ressourcen, für die die Klasse verantwortlich ist, werden möglicherweise nicht bereinigt.

328
Paul Tomblin

Ja, Sie haben recht, Ihr Beispiel schadet nicht (zumindest bei den meisten modernen Betriebssystemen). Der gesamte von Ihrem Prozess zugewiesene Speicher wird vom Betriebssystem wiederhergestellt, sobald der Prozess abgeschlossen ist. 

Quelle: Allocation und GC Myths (PostScript-Warnung!)

Allocation Myth 4: Nicht mit Müll gesammelte Programme sollte immer den gesamten Speicher freigeben sie vergeben 

Die Wahrheit: Ausgelassen Ausbuchungen in häufig ausgeführten Code verursacht wachsende Lecks. Sie sind selten akzeptabel aber Programme, die behalten den meisten zugewiesenen Speicher bis Das Beenden von Programmen ist häufig besser ohne dazwischenliegende Freigabestellen . Malloc ist viel einfacher zu implementieren, wenn es gibt kein freies.

In den meisten Fällen ist Speicher freigeben Kurz vor dem Programmende ist es sinnlos. Das Betriebssystem wird es trotzdem zurückfordern. Kostenlos wird berühren und in den Toten blättern Gegenstände; das OS wird nicht.

Konsequenz: Seien Sie vorsichtig mit "Leck Detektoren", die die Zuordnungen zählen . Einige "Lecks" sind gut!

Das heißt, Sie sollten wirklich versuchen, alle Speicherlecks zu vermeiden! 

Zweite Frage: Ihr Design ist in Ordnung. Wenn Sie etwas speichern müssen, bis Ihre Anwendung beendet ist, können Sie dies mit dynamischer Speicherzuweisung tun. Wenn Sie die erforderliche Größe nicht kennen, können Sie keinen statisch zugewiesenen Speicher verwenden.

100
compie

=== Was ist mit Future Proofing und Wiederverwendung von Code? ===

Wenn Sie not den Code schreiben, um die Objekte freizugeben, beschränken Sie den Code darauf, nur sicher verwendet zu werden, wenn Sie sich darauf verlassen können, dass der Speicher durch den Prozess, der gerade geschlossen wird, freigegeben wird Einmalprojekte oder "Wegwerfen"[1] Projekte) ... wo Sie wissen, wann der Prozess endet.

Wenn Sie do den Code schreiben, der all Ihren dynamisch zugewiesenen Speicher freigibt, werden Sie den Code in der Zukunft prüfen und von anderen Benutzern in einem größeren Projekt verwenden lassen.


[1] über "wegwerfende" Projekte. Code, der in "Wegwerf" -Projekten verwendet wird, kann nicht weggeworfen werden. Als nächstes wissen Sie, dass zehn Jahre vergangen sind und Ihr Wegwerfcode noch immer verwendet wird.

Ich habe eine Geschichte über einen Typen gehört, der nur aus Spaß Code geschrieben hat, damit seine Hardware besser funktioniert. Er sagte " nur ein Hobby, wird nicht groß und professionell sein ". Jahre später benutzen viele Leute seinen "Hobby" -Code.

52

Sie haben Recht, es wird kein Schaden angerichtet und es ist schneller, einfach zu beenden

Dafür gibt es verschiedene Gründe:

  • Alle Desktop- und Server-Umgebungen geben beim Beenden einfach den gesamten Speicherplatz frei (). Sie kennen keine programminternen Datenstrukturen wie Heaps.

  • Fast alle free()-Implementierungen nicht immer geben den Speicher trotzdem an das Betriebssystem zurück.

  • Noch wichtiger ist, es ist Zeitverschwendung, wenn es direkt vor dem Beenden ausgeführt wird (). Beim Beenden werden Speicherseiten und Auslagerungsbereiche einfach freigegeben. Im Gegensatz dazu brennt eine Reihe von Free () - Aufrufen die CPU-Zeit und kann zu Auslagerungsvorgängen auf der Festplatte, Cache-Fehlern und Zwangsräumungen führen.

In Bezug auf die Möglichkeit der zukünftigen Wiederverwendung von Code, die die Gewissheit von sinnlosen Ops rechtfertigt: Dies ist eine Überlegung, aber es ist wohl nicht die Agile - Methode. YAGNI!

46
DigitalRoss

Ich gebe normalerweise jeden zugewiesenen Block frei, sobald ich sicher bin, dass ich damit fertig bin. Heute könnte der Einstiegspunkt meines Programms main(int argc, char *argv[]) sein, aber morgen könnte es foo_entry_point(char **args, struct foo *f) sein und als Funktionszeiger eingegeben werden.

Wenn das passiert, habe ich jetzt ein Leck. 

In Bezug auf Ihre zweite Frage würde ich, wenn mein Programm Eingaben wie a = 5 entnahm, Platz für a zuweisen oder denselben Platz für ein nachfolgendes a = "foo" erneut zuweisen. Dies würde zugeteilt bleiben bis:

  1. Der Benutzer hat "unset a" eingegeben.
  2. Meine Bereinigungsfunktion wurde eingegeben, entweder ein Signal bedienend oder der Benutzer gab "Quit" ein.

Ich kann mir kein modernes OS vorstellen, das nach dem Beenden eines Prozesses keinen Speicherplatz mehr beansprucht. Andererseits ist free () billig, warum nicht aufräumen? Wie andere schon gesagt haben, sind Werkzeuge wie valgrind hervorragend zum Erkennen von Lecks, um die Sie sich wirklich sorgen müssen. Obwohl die Blöcke, die Sie beispielsweise verwenden, als "noch erreichbar" gekennzeichnet werden, ist dies nur ein zusätzliches Rauschen in der Ausgabe, wenn Sie sicherstellen möchten, dass Sie keine Lecks haben.

Ein anderer Mythos ist " Wenn es in main () ist, muss ich es nicht freigeben ", das ist falsch. Folgendes berücksichtigen:

char *t;

for (i=0; i < 255; i++) {
    t = strdup(foo->name);
    let_strtok_eat_away_at(t);
}

Wenn dies vor dem Forking/Daemonizing (und theoretisch für immer ausgeführt) erfolgte, hat Ihr Programm gerade eine unbestimmte Größe von t 255-mal durchgesickert.

Ein gutes, gut geschriebenes Programm sollte immer hinter sich aufräumen. Speicherplatz freigeben, alle Dateien leeren, alle Deskriptoren schließen, alle temporären Dateien aufheben usw. Diese Bereinigungsfunktion sollte bei normaler Beendigung oder beim Empfang verschiedener Arten von schwerwiegenden Signalen erreicht werden, es sei denn, Sie möchten einige Dateien so herumliegen lassen, dass Sie es können einen Absturz erkennen und fortsetzen.

Sei wirklich nett zu der armen Seele, die dein Zeug aufrechterhalten muss, wenn du zu anderen Dingen übergehst. Gib es ihnen 'valgrind clean' :)

22
Tim Post

Ich bin überhaupt nicht einverstanden mit jedem, der sagt, dass OP korrekt ist oder dass es keinen Schaden gibt.

Jeder spricht von einem modernen und/oder älteren Betriebssystem.

Aber was ist, wenn ich in einer Umgebung bin, in der ich einfach kein Betriebssystem habe? ... Wo gibt es nichts?

Stellen Sie sich vor, Sie verwenden Interrupts im Thread-Stil und weisen Speicher zu .. In der C-Norm ISO/IEC: 9899 wird die Lebensdauer des Speichers folgendermaßen angegeben:

7.20.3 Speicherverwaltungsfunktionen

1 Die Reihenfolge und Zusammenstellung des Speichers, der durch aufeinanderfolgende Aufrufe des Aufrufs zugewiesen wird, Malloc- und Realloc-Funktionen sind nicht spezifiziert. Der Zeiger wird zurückgegeben, wenn die Zuweisung Der Befehl follows ist in geeigneter Weise so ausgerichtet, dass er einem Zeiger auf einen beliebigen Objekttyp zugewiesen werden kann und dann verwendet werden, um auf ein solches Objekt oder ein Array solcher Objekte in dem zugewiesenen Bereich zuzugreifen. (bis der Speicherplatz explizit freigegeben wird). Die Lebensdauer eines zugeordneten Objekts verlängert sich Von der Zuteilung bis zur Freigabe. [...]

Es muss also nicht angegeben werden, dass die Umgebung die Freigabe für Sie erledigt. Andernfalls wird der letzte Satz hinzugefügt: "Oder bis das Programm beendet wird."

Mit anderen Worten also: Speicherfreigabe ist keine schlechte Praxis. Es erzeugt nicht portablen und nicht C-konformen Code ..__, der zumindest als "richtig" angesehen werden kann, wenn Folgendes gilt: [...] wird von der Umgebung unterstützt.

In Fällen, in denen Sie überhaupt kein Betriebssystem haben, erledigt niemand die Aufgabe für Sie. (Ich weiß, dass Sie normalerweise Speicher auf eingebetteten Systemen nicht zuweisen und neu zuweisen.), Aber es gibt Fälle, in denen Sie dies möchten .)

Im Allgemeinen also einfach C (als das das OP markiert ist), dies erzeugt einfach fehlerhaften und nicht portablen Code.

19
dhein

Es ist vollkommen in Ordnung, wenn Sie beim Beenden den Speicher frei lassen. malloc () ordnet den Speicher aus dem Speicherbereich "Heap" zu und der gesamte Heap eines Prozesses wird freigegeben, wenn der Prozess beendet wird.

Ein Grund, warum die Leute dennoch darauf bestehen, dass es gut ist, vor dem Beenden alles freizugeben, ist, dass Speicher-Debugger (z. B. valgrind unter Linux) die nicht freigegebenen Blöcke als Speicherverluste erkennen schwieriger zu erkennen, wenn Sie am Ende auch "falsche" Ergebnisse erhalten.

12
Antti Huima

Dieser Code funktioniert in der Regel gut, bedenken Sie jedoch das Problem der Wiederverwendung von Code.

Möglicherweise haben Sie ein Code-Snippet geschrieben, das den zugewiesenen Speicher nicht freigibt. Es wird so ausgeführt, dass der Speicher automatisch wieder freigegeben wird. Scheint in Ordnung.

Dann kopiert jemand anderes Ihr Snippet so in sein Projekt, dass es tausend Mal pro Sekunde ausgeführt wird. Diese Person hat jetzt ein großes Speicherleck in seinem Programm. Im Allgemeinen nicht sehr gut, normalerweise fatal für eine Serveranwendung.

Die Wiederverwendung von Code ist in Unternehmen typisch. Normalerweise besitzt das Unternehmen den gesamten Code, den seine Mitarbeiter erstellen, und jede Abteilung kann das, was das Unternehmen besitzt, wiederverwenden. Indem Sie einen solchen "unschuldig aussehenden" Code schreiben, verursachen Sie anderen Menschen möglicherweise Kopfschmerzen. Dies kann Sie entlassen.

11
sharptooth

Wenn Sie den zugewiesenen Speicher verwenden, machen Sie nichts falsch. Es wird zu einem Problem, wenn Sie andere Funktionen als main schreiben, die Speicher zuweisen, ohne ihn freizugeben, und ohne ihn für den Rest Ihres Programms verfügbar zu machen. Dann läuft Ihr Programm mit dem zugewiesenen Speicher weiter, jedoch ohne Verwendung. Ihr Programm und andere laufende Programme werden um diesen Speicher beraubt.

Edit: Es ist nicht 100% ig genau zu sagen, dass anderen laufenden Programmen dieser Speicher entzogen wird. Das Betriebssystem kann sie immer auf Kosten des Auslagerns Ihres Programms in den virtuellen Speicher (</handwaving>) verwenden. Der Punkt ist jedoch, dass, wenn Ihr Programm Speicher freigibt, den es nicht verwendet, ein Austausch von virtuellem Speicher weniger wahrscheinlich ist.

11
Bill the Lizard

Es gibt tatsächlich einen Abschnitt im OSTEP Online-Lehrbuch für ein Grundstudium in Betriebssystemen, in dem genau Ihre Frage behandelt wird.

Der relevante Abschnitt ist "Vergessen, Speicher freizugeben" im Kapitel Speicher-API auf Seite 6, der die folgende Erklärung enthält:

In einigen Fällen scheint es vernünftig zu sein, nicht kostenlos () anzurufen. Beispielsweise ist Ihr Programm von kurzer Dauer und wird bald beendet. In diesem Fall bereinigt das Betriebssystem beim Beenden des Vorgangs alle zugewiesenen Seiten, sodass per se kein Speicherverlust auftritt. Während dies sicherlich „funktioniert“ (siehe Seite 7), ist es wahrscheinlich eine schlechte Angewohnheit, sich zu entwickeln. Seien Sie also vorsichtig, wenn Sie sich für eine solche Strategie entscheiden

Dieser Auszug steht im Zusammenhang mit der Einführung des Konzepts des virtuellen Speichers. Grundsätzlich erklären die Autoren an dieser Stelle des Buches, dass eines der Ziele eines Betriebssystems darin besteht, "Speicher zu virtualisieren", dh jedem Programm den Eindruck zu vermitteln, dass es Zugriff auf einen sehr großen Adressraum hat.

Hinter den Kulissen übersetzt das Betriebssystem "virtuelle Adressen", die der Benutzer sieht, in tatsächliche Adressen, die auf den physischen Speicher verweisen.

Um Ressourcen wie den physischen Speicher gemeinsam zu nutzen, muss das Betriebssystem jedoch nachverfolgen, welche Prozesse ihn verwenden. Wenn ein Prozess beendet wird, liegt es im Rahmen der Funktionen und der Entwurfsziele des Betriebssystems, den Prozessspeicher zurückzugewinnen, sodass er den Speicher neu verteilen und mit anderen Prozessen gemeinsam nutzen kann.


EDIT: Die im Auszug erwähnte Seite wird unten kopiert.

AUSSERHALB: WARUM KEIN SPEICHER IS LEAKED, WENN IHR PROZESS BEENDET

Wenn Sie ein kurzlebiges Programm schreiben, können Sie mithilfe von malloc() Speicherplatz zuweisen. Das Programm wird ausgeführt und steht kurz vor dem Abschluss: Muss free() einige Male kurz vor dem Beenden aufgerufen werden? Während es falsch erscheint, dies nicht zu tun, geht keine Erinnerung im eigentlichen Sinne "verloren". Der Grund ist einfach: Es gibt wirklich zwei Ebenen der Speicherverwaltung im System. Die erste Ebene der Speicherverwaltung wird vom Betriebssystem ausgeführt, das den Prozessen beim Ausführen Speicher zur Verfügung stellt und diesen zurücknimmt, wenn die Prozesse beendet werden (oder auf andere Weise abstürzen). Die zweite Verwaltungsebene befindet sich in jedem Prozess, z. B. im Heap, wenn Sie malloc() und free() aufrufen. Selbst wenn Sie free() nicht aufrufen (und damit den Speicher im Heap verlieren), greift das Betriebssystem auf den gesamten Speicher des Prozesses zurück (einschließlich der Seiten für Code, Stack und, wie hier relevant, Heap) ), wenn das Programm beendet ist. Unabhängig vom Status Ihres Heapspeichers in Ihrem Adressraum nimmt das Betriebssystem alle diese Seiten zurück, wenn der Vorgang beendet wird, und stellt so sicher, dass kein Speicher verloren geht, obwohl Sie ihn nicht freigegeben haben.

Daher verursacht ein Speicherverlust bei kurzlebigen Programmen häufig keine Betriebsprobleme (obwohl dies als schlechte Form angesehen werden kann). Wenn Sie einen Server mit langer Laufzeit schreiben (z. B. einen Webserver oder ein Datenbankverwaltungssystem, das niemals beendet wird), ist ein Speicherleck ein viel größeres Problem, das schließlich zu einem Absturz führt, wenn der Arbeitsspeicher der Anwendung ausgeht. Und natürlich ist ein Speicherverlust ein noch größeres Problem in einem bestimmten Programm: dem Betriebssystem selbst. Zeigen Sie uns noch einmal: Diejenigen, die den Kernel-Code schreiben, haben den härtesten Job von allen ...

ab Seite 7 von Memory API Kapitel von

Betriebssysteme: Drei einfache Teile
Remzi H. Arpaci-Dusseau und Andrea C. Arpaci-Dusseau Arpaci-Dusseau Bücher März 2015 (Version 0.90)

5
spenceryue

Was ist das eigentliche Ergebnis hier?

Ihr Programm hat den Speicher durchgesickert. Abhängig von Ihrem Betriebssystem wurde möglicherweise wiederhergestellt.

Die meisten modernen desktop operating systems do stellen den durchgesickerten Speicher nach Beendigung des Prozesses wieder her. Daher ist es leider üblich, das Problem zu ignorieren, wie viele andere Antworten hier zeigen.)

Sie verlassen sich jedoch auf eine Sicherheitsfunktion, auf die Sie sich nicht verlassen sollten, und Ihr Programm (oder Ihre Funktion) wird möglicherweise auf einem System ausgeführt, in dem dieses Verhalten do zu einem "harten" Speicherverlust führt. next Zeit.

Sie arbeiten möglicherweise im Kernel-Modus oder auf Vintage-/Embedded-Betriebssystemen, die keinen Speicherschutz als Kompromiss verwenden. (MMUs beanspruchen den Speicherplatz, der Speicherschutz erfordert zusätzliche CPU-Zyklen und es ist nicht zu viel, von einem Programmierer nach dem Aufräumen zu fragen).

Sie können den Speicher auf beliebige Weise verwenden und wiederverwenden. Stellen Sie jedoch sicher, dass Sie alle Ressourcen freigegeben haben, bevor Sie den Vorgang beenden.

5
DevSolar

Es gibt kein wirkliches danger, wenn Sie Ihre Variablen nicht freigeben. Wenn Sie jedoch einem anderen Speicherblock einen Zeiger auf einen anderen Speicherblock zuweisen, ohne den ersten Block freizugeben, ist der erste Block nicht mehr zugänglich, beansprucht jedoch noch Platz. Dies wird als Speicherverlust bezeichnet. Wenn Sie dies regelmäßig tun, wird Ihr Prozess damit beginnen, mehr und mehr Speicherplatz zu beanspruchen, wodurch Systemressourcen von anderen Prozessen genommen werden.

Wenn der Prozess nur von kurzer Dauer ist, können Sie dies häufig tun, da der gesamte zugewiesene Speicher nach Beendigung des Prozesses vom Betriebssystem zurückgefordert wird. Ich würde jedoch empfehlen, den gesamten Speicher freizugeben, für den Sie keinen weiteren Gebrauch machen.

3
Kyle Cronin

Sie haben diesbezüglich absolut recht. In kleinen trivialen Programmen, bei denen eine Variable bis zum Tod des Programms vorhanden sein muss, hat die Aufhebung der Speicherzuweisung keinen wirklichen Nutzen.

Tatsächlich war ich einmal an einem Projekt beteiligt, bei dem jede Ausführung des Programms sehr komplex, aber relativ kurzlebig war. Die Entscheidung bestand darin, nur Speicher zu reservieren und das Projekt nicht durch Fehler zu destabilisieren. 

Dies ist jedoch in den meisten Programmen nicht wirklich eine Option, oder es kann dazu führen, dass nicht genügend Speicherplatz zur Verfügung steht. 

3
Uri

Sie sind korrekt, der Speicher wird automatisch freigegeben, wenn der Prozess beendet wird. Einige Leute bemühen sich, keine umfangreiche Bereinigung durchzuführen, wenn der Prozess beendet wird, da dies alles dem Betriebssystem überlassen wird. Während das Programm ausgeführt wird, sollten Sie jedoch nicht verwendeten Speicher freigeben. Wenn Sie dies nicht tun, kann es sein, dass Sie möglicherweise ausgehen oder übermäßiges Paging verursachen, wenn Ihr Arbeitssatz zu groß wird.

2
Michael

Wenn Sie eine Anwendung von Grund auf entwickeln, können Sie fundierte Entscheidungen darüber treffen, wann Sie kostenlos anrufen müssen. Ihr Beispielprogramm ist in Ordnung: Es weist Speicher zu, es kann sein, dass es einige Sekunden funktioniert und dann geschlossen wird, wodurch alle Ressourcen freigegeben werden, die es beansprucht.

Wenn Sie jedoch etwas anderes schreiben - einen Server/eine langlebige Anwendung oder eine Bibliothek, die von einer anderen Person verwendet werden soll, sollten Sie davon ausgehen, dass Sie bei allem, was Sie malloc nennen, einen kostenlosen Anruf tätigen.

Wenn Sie die pragmatische Seite für eine Sekunde ignorieren, ist es viel sicherer, der strengeren Herangehensweise zu folgen und sich zu zwingen, alles zu befreien, was Sie wollen. Wenn Sie nicht die Gewohnheit haben, beim Codieren auf Speicherlecks zu achten, können Sie leicht ein paar Lecks aufspringen. In anderen Worten, ja - Sie können ohne es wegkommen; aber sei bitte vorsichtig.

2
ojrac

Wenn ein Programm vergisst, einige Megabytes zu löschen, bevor es beendet wird, werden sie vom Betriebssystem freigegeben. Wenn Ihr Programm jedoch wochenlang ausgeführt wird und eine Schleife innerhalb des Programms vergisst, bei jeder Iteration ein paar Bytes freizugeben, haben Sie ein mächtiges Speicherverlust, das den gesamten verfügbaren Speicher Ihres Computers belegt, es sei denn, Sie starten es regelmäßig basis => selbst kleine Speicherverluste sind möglicherweise schlecht, wenn das Programm für eine sehr große Aufgabe verwendet wird, selbst wenn es ursprünglich nicht für eine Aufgabe konzipiert wurde.

0