Ist es jemals in Ordnung, free() für zugewiesenen Speicher *nicht* zu verwenden?

Ich studiere Informatik und habe einige Elektronikkurse. Ich habe von zwei meiner Professoren (dieser Kurse) gehört, dass es möglich ist, die Verwendung von zu vermeiden free() Funktion (nach malloc(), calloc()usw.), da die zugewiesenen Speicherplätze wahrscheinlich nicht erneut verwendet werden, um anderen Speicher zuzuweisen. Das heißt, wenn Sie beispielsweise 4 Bytes zuweisen und dann freigeben, haben Sie 4 Bytes Speicherplatz, die wahrscheinlich nicht erneut zugewiesen werden: Sie haben a Loch.

Ich finde das verrückt: Du kannst keine haben Nicht-Spielzeug-Programm wo Sie Speicher auf dem Heap zuweisen, ohne ihn freizugeben. Aber ich habe nicht das Wissen, um genau zu erklären, warum es so wichtig ist, dass für jeden malloc() es muss eine geben free().

Also: Gibt es Umstände, unter denen es angemessen sein könnte, a malloc() ohne zu benutzen free()? Und wenn nicht, wie kann ich das meinen Professoren erklären?

Einfach: Lesen Sie einfach die Quelle von so ziemlich jedem halbwegs ernsten malloc()/free() Implementierung. Damit meine ich das Eigentliche Speichermanager die die Arbeit der Anrufe übernimmt. Dies kann sich in der Laufzeitbibliothek, der virtuellen Maschine oder dem Betriebssystem befinden. Natürlich ist der Code nicht in allen Fällen gleichermaßen zugänglich.

Sicherzustellen, dass der Speicher nicht fragmentiert wird, indem benachbarte Löcher zu größeren Löchern verbunden werden, ist sehr üblich. Seriösere Allokatoren verwenden seriösere Techniken, um dies sicherzustellen.

Nehmen wir also an, Sie führen drei Zuweisungen und Freigaben durch und erhalten Blöcke in dieser Reihenfolge im Speicher:

+-+-+-+
|A|B|C|
+-+-+-+

Dabei spielt die Größe der einzelnen Allokationen keine Rolle. dann befreist du den ersten und letzten, A und C:

+-+-+-+
| |B| |
+-+-+-+

Wenn Sie B schließlich befreien, erhalten Sie (zunächst zumindest theoretisch) Folgendes:

+-+-+-+
| | | |
+-+-+-+

die einfach defragmentiert werden können

+-+-+-+
|     |
+-+-+-+

dh ein einzelner größerer freier Block, keine Fragmente übrig.

Referenzen, wie gewünscht:

• Versuchen Sie, den Code für zu lesen dlmalloc. Ich bin viel weiter fortgeschritten, da ich eine vollständige Implementierung in Produktionsqualität bin.
• Auch in eingebetteten Anwendungen sind defragmentierende Implementierungen verfügbar. Siehe zum Beispiel diese Notizen auf der heap4.c Code in FreeRTOS.

Die anderen Antworten erklären bereits sehr gut, dass echte Implementierungen von malloc() und free() koaleszieren (defragmnieren) Löcher tatsächlich zu größeren freien Brocken. Aber selbst wenn das nicht der Fall wäre, wäre es immer noch eine schlechte Idee, darauf zu verzichten free().

Die Sache ist die, Ihr Programm hat gerade diese 4 Bytes Speicher zugewiesen (und freigeben wollen). Wenn es über einen längeren Zeitraum ausgeführt wird, ist es sehr wahrscheinlich, dass es nur 4 Bytes Speicher erneut zuweisen muss. Selbst wenn diese 4 Bytes niemals zu einem größeren zusammenhängenden Raum zusammenwachsen, können sie dennoch vom Programm selbst wiederverwendet werden.

Es ist totaler Unsinn, zum Beispiel gibt es viele verschiedene Implementierungen von malloceinige versuchen, den Haufen effizienter zu machen, wie Doug Leas oder Dies eines.

Arbeiten Ihre Professoren zufällig mit POSIX? Wenn sie daran gewöhnt sind, viele kleine, minimalistische Shell-Anwendungen zu schreiben, ist das ein Szenario, in dem ich mir vorstellen kann, dass dieser Ansatz nicht allzu schlecht wäre – den ganzen Haufen auf einmal nach Belieben des Betriebssystems freizugeben ist schneller als das Freigeben von tausend Variablen. Wenn Sie davon ausgehen, dass Ihre Anwendung ein oder zwei Sekunden lang ausgeführt wird, könnten Sie problemlos ohne die Aufhebung der Zuordnung davonkommen.

Es ist natürlich immer noch eine schlechte Praxis (Leistungsverbesserungen sollten immer auf Profiling basieren, nicht auf einem vagen Bauchgefühl), und es ist nichts, was Sie Studenten sagen sollten, ohne die anderen Einschränkungen zu erklären, aber ich kann mir eine Menge Tiny-Piping-Shell vorstellen -Anwendungen auf diese Weise geschrieben werden (wenn nicht direkt statische Zuweisung verwendet wird). Wenn Sie an etwas arbeiten, das davon profitiert, dass Sie Ihre Variablen nicht freigeben, arbeiten Sie entweder unter extrem niedrigen Latenzbedingungen (in diesem Fall, wie können Sie sich überhaupt dynamische Zuordnung und C++ leisten? :D), oder Sie tun es etwas sehr, sehr falsch machen (wie das Zuweisen eines Integer-Arrays durch Zuweisen von tausend Integern nacheinander anstelle eines einzelnen Speicherblocks).

Sie erwähnten, dass sie Elektronikprofessoren waren. Sie sind möglicherweise daran gewöhnt, Firmware/Echtzeit-Software zu schreiben, wobei es oft erforderlich ist, die Ausführung von Dingen genau zu timen. Wenn Sie in diesen Fällen wissen, dass Sie über genügend Speicher für alle Zuweisungen verfügen und Speicher nicht freigeben und neu zuweisen, kann dies zu einer einfacher zu berechnenden Begrenzung der Ausführungszeit führen.

In einigen Schemata kann auch ein Hardware-Speicherschutz verwendet werden, um sicherzustellen, dass die Routine in ihrem zugewiesenen Speicher abgeschlossen wird oder einen Trap in dem erzeugt, was sein sollte sehr Ausnahmefällen.

Wenn Sie dies aus einem anderen Blickwinkel betrachten als frühere Kommentatoren und Antworten, besteht eine Möglichkeit darin, dass Ihre Professoren Erfahrungen mit Systemen gemacht haben, bei denen der Speicher statisch zugewiesen wurde (dh wenn das Programm kompiliert wurde).

Statische Zuordnung tritt auf, wenn Sie Folgendes tun:

define MAX_SIZE 32
int array[MAX_SIZE];

In vielen Echtzeit- und eingebetteten Systemen (die am ehesten von EEs oder CEs angetroffen werden) ist es normalerweise vorzuziehen, eine dynamische Speicherzuordnung insgesamt zu vermeiden. Also, Verwendungen von malloc, new, und ihre Deletionsgegenstücke sind selten. Hinzu kommt, dass der Speicher in Computern in den letzten Jahren explodiert ist.

Wenn Ihnen 512 MB zur Verfügung stehen und Sie 1 MB statisch zuweisen, müssen Sie ungefähr 511 MB durchrollen, bevor Ihre Software explodiert (na ja, nicht genau … aber gehen Sie hier mit mir). Angenommen, Sie haben 511 MB zu missbrauchen, wenn Sie jede Sekunde 4 Bytes mallocieren, ohne sie freizugeben, können Sie fast 73 Stunden lang laufen, bevor Ihnen der Speicher ausgeht. Wenn man bedenkt, dass viele Maschinen einmal am Tag abgeschaltet werden, bedeutet dies, dass Ihrem Programm nie der Speicherplatz ausgeht!

Im obigen Beispiel beträgt das Leck 4 Bytes pro Sekunde oder 240 Bytes/min. Stellen Sie sich nun vor, dass Sie das Byte/Min-Verhältnis verringern. Je niedriger dieses Verhältnis ist, desto länger kann Ihr Programm ohne Probleme laufen. Wenn dein mallocs sind selten, das ist eine reale Möglichkeit.

Verdammt, wenn du weißt, dass du es nur tun wirst malloc etwas einmal, und das malloc nie wieder getroffen werden, dann ist es einer statischen Zuweisung sehr ähnlich, obwohl Sie die Größe dessen, was Sie zuordnen, im Voraus nicht wissen müssen. Beispiel: Sagen wir, wir haben wieder 512 MB. Wir müssen malloc 32 Arrays von ganzen Zahlen. Dies sind typische Ganzzahlen – jeweils 4 Bytes. Wir wissen, dass die Größe dieser Arrays niemals 1024 Ganzzahlen überschreiten wird. In unserem Programm treten keine anderen Speicherzuweisungen auf. Haben wir genug Speicher? 32 * 1024 * 4 = 131.072. 128 KB – also ja. Wir haben viel Platz. Wenn wir wissen, dass wir nie mehr Speicher zuweisen werden, können wir das sicher tun malloc diese Arrays, ohne sie freizugeben. Dies kann jedoch auch bedeuten, dass Sie die Maschine/das Gerät neu starten müssen, wenn Ihr Programm abstürzt. Wenn Sie Ihr Programm 4.096 Mal starten/stoppen, werden Ihnen alle 512 MB zugewiesen. Wenn Sie Zombie-Prozesse haben, ist es möglich, dass der Speicher auch nach einem Absturz nie freigegeben wird.

Erspare dir Schmerz und Elend und konsumiere dieses Mantra als Die Eine Wahrheit: malloc sollte stets verbunden sein mit a free. new sollte stets haben eine delete.

Ich denke, die in der Frage angegebene Behauptung ist Unsinn, wenn sie vom Standpunkt des Programmierers wörtlich genommen wird, aber aus Sicht des Betriebssystems ist sie (zumindest teilweise) wahr.

malloc() ruft schließlich entweder mmap() oder sbrk() auf, wodurch eine Seite vom Betriebssystem abgerufen wird.

In jedem nicht-trivialen Programm ist die Wahrscheinlichkeit, dass diese Seite jemals während der Lebensdauer eines Prozesses an das Betriebssystem zurückgegeben wird, sehr gering, selbst wenn Sie den größten Teil des zugewiesenen Speichers freigeben (). Der freie () Speicher wird also die meiste Zeit nur für denselben Prozess verfügbar sein, aber nicht für andere.