Was passiert WIRKLICH, wenn man nach malloc nicht frei gibt, bevor das Programm beendet wird?

Question

Uns allen wurde beigebracht, dass man jeden zugewiesenen Zeiger freigeben MUSS. Ich bin allerdings ein wenig neugierig, was es wirklich kostet, wenn man den Speicher nicht freigibt. In einigen offensichtlichen Fällen, etwa wenn malloc() innerhalb einer Schleife oder eines Teils einer Thread-Ausführung aufgerufen wird, ist es sehr wichtig, den Speicher freizugeben, damit keine Speicherlecks entstehen. Aber betrachten Sie die folgenden zwei Beispiele:

Erstens, wenn ich einen Code habe, der in etwa so aussieht:

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

Was ist das wirkliche Ergebnis hier? Ich denke, dass der Prozess stirbt und dann der Heap-Speicherplatz sowieso weg ist, so dass es keinen Schaden gibt, wenn der Aufruf von free (Ich erkenne jedoch an, wie wichtig es ist, sie trotzdem zu haben, um sie zu schließen, zu warten und um eine gute Praxis zu haben). Liege ich mit dieser Überlegung richtig?

Zweitens: Nehmen wir an, ich habe ein Programm, das ein wenig wie eine Shell funktioniert. Benutzer können Variablen deklarieren wie aaa = 123 und diese werden zur späteren Verwendung in einer dynamischen Datenstruktur gespeichert. Es liegt auf der Hand, dass Sie eine Lösung verwenden, die eine *alloc-Funktion aufruft (Hashmap, verknüpfte Liste oder etwas Ähnliches). Für diese Art von Programm macht es keinen Sinn, nach dem Aufruf von malloc weil diese Variablen während der Ausführung des Programms jederzeit vorhanden sein müssen und es keine gute Möglichkeit gibt (die ich sehen kann), dies mit statisch zugewiesenem Speicherplatz zu implementieren. Ist es schlechtes Design, um einen Haufen Speicher zu haben, der zugewiesen wird, aber nur als Teil der Prozessbeendigung freigegeben wird? Wenn ja, was ist die Alternative?

Answer 1

Wenn Sie eine Anwendung von Grund auf neu entwickeln, können Sie einige fundierte Entscheidungen darüber treffen, wann Sie free aufrufen. Ihr Beispielprogramm ist in Ordnung: Es weist Speicher zu, vielleicht lassen Sie es ein paar Sekunden lang arbeiten, und schließt sich dann, wobei es alle beanspruchten Ressourcen freigibt.

Wenn Sie jedoch etwas anderes schreiben - eine Server-/Langzeitanwendung oder eine Bibliothek, die von jemand anderem verwendet werden soll -, sollten Sie erwarten, dass Sie free für alles aufrufen, was Sie malloc.

Abgesehen von der pragmatischen Seite ist es viel sicherer, den strengeren Ansatz zu verfolgen und sich selbst zu zwingen, alles freizugeben, was Sie malloc. Wenn Sie sich nicht angewöhnt haben, beim Programmieren auf Speicherlecks zu achten, können Sie leicht ein paar Lecks verursachen. Mit anderen Worten: Ja, Sie können darauf verzichten, aber seien Sie bitte vorsichtig.

Answer 2

Wenn ein Programm vergisst, ein paar Megabyte freizugeben, bevor es beendet wird, gibt das Betriebssystem sie frei. Wenn Ihr Programm jedoch wochenlang läuft und eine Schleife innerhalb des Programms vergisst, bei jeder Iteration ein paar Bytes freizugeben, haben Sie ein gewaltiges Speicherleck, das den gesamten verfügbaren Speicher Ihres Computers auffrisst, wenn Sie ihn nicht regelmäßig neu starten => selbst kleine Speicherlecks können schlimm sein, wenn das Programm für eine ernsthafte große Aufgabe verwendet wird, auch wenn es ursprünglich nicht für eine solche konzipiert war.

Answer 3

Ich denke, dass Ihre beiden Beispiele eigentlich nur eines sind: die free() sollte nur am Ende des Prozesses auftreten, was, wie Sie betonen, nutzlos ist, da der Prozess beendet wird.

In Ihrem zweiten Beispiel besteht der einzige Unterschied darin, dass Sie eine unbestimmte Anzahl von malloc() was dazu führen kann, dass der Speicherplatz knapp wird. Die einzige Möglichkeit, mit dieser Situation umzugehen, ist die Überprüfung des Rückgabewerts von malloc() und handeln entsprechend.