Wird die Objektfreigabe beim Programm-Exit wirklich benötigt?

Question

Ich habe eine technische Frage. Dies ist KEINE Frage über richtige Codierung.

Meine Frage ist TECHNICALLY Freigabe von Objekten auf einem Programm beenden/schließen benötigt?

Mit anderen Worten, sagen wir aus Gründen des Arguments, haben Sie eine Schaltfläche, die Ihre Anwendung schließt, aber kurz bevor Sie schließen Sie ein Bild anzeigen, und dann schließen Sie die Anwendung.

Müssen Sie diese Bildansicht TECHNISCH vor dem Schließen der Anwendung freigeben? Wird der Speicher automatisch freigegeben, wenn das Programm beendet wird, oder wenn Sie ihn nicht freigeben, bleibt der Speicher irgendwie "aktiv"?

Ich verstehe, dass Sie "sollte" es freigeben, meine Frage ist über die technische Seite davon, und was passiert hinter den Kulissen.

Vielen Dank.

Answer 1

Es ist nicht notwendig. Aber wenn Sie valgrind oder ein ähnliches Tool verwenden, werden Sie bald feststellen, dass Sie mit falschen Warnungen überflutet werden, wenn Sie Ihren gesamten Speicher baumeln lassen.

Auf der Linux-Seite der Dinge ist der Heap unter Verwendung der sbrk Systemaufruf gewachsen. Dies vergrößert den Gesamtspeicherplatz des Prozessors um einen großen Block auf einmal (so wird nur ein sbrk benötigt, um genügend Platz für viele malloc s) zu bieten. Wenn der Prozess abbricht, lädt der Kernel den gesamten von sbrk zugewiesenen Speicher zurück. Deshalb bist du in Sicherheit. Der Kernel schließt auch alle Dateideskriptoren, die von diesem einen Prozess geöffnet wurden.

Es gibt ein paar Probleme, die auftreten können. Wenn Ihr Prozess jemals fork zu einem ungünstigen Zeitpunkt stattfindet, werden alle offenen Dateideskriptoren dupliziert. Ich habe gesehen, dass sich dies als eine TCP-Verbindung manifestiert, die auf mysteriöse Weise am Leben geblieben ist, nachdem der ursprüngliche Prozess gestorben ist, nämlich böse. Darüber hinaus gibt es andere Ressourcen, die nicht auf den Prozess beschränkt sind, so dass sie nicht zurückgewonnen werden, wenn der Prozess abbricht. Dazu gehören Shared-Memory-Segmente, temporäre Dateien, Named Pipes und UNIX-Sockets und wahrscheinlich eine Reihe anderer IPC-Mechanismen.

Zusammenfassung? Die Erinnerung ist in Ordnung. Dateideskriptoren sind normalerweise gut. Einige der esoterischen IPC-Funktionen werden schrecklich zerstört, wenn sie nicht aufgeräumt werden.

Answer 2

In der Tat ist es nicht notwendig, aber wenn Sie einige Ihrer Quelle wiederverwenden und in einem anderen Programm verwenden möchten, können Speicherlecks auftreten. Denken Sie außerdem daran, dass das Betriebssystem niemals fehlerfrei ist. Es könnte "vergessen", einige Ressourcen freizugeben.

Answer 3

Auf dem iPhone müssen Sie nicht, und soweit ich weiß, können Sie nicht. Nach dem Empfang von ApplicationWillTerminate: Sie haben ein paar Sekunden, um Ihren Status zu speichern und dann das Betriebssystem tötet Ihren Prozess. Erstellen Sie eine der Beispielanwendungen und fügen Sie einen Haltepunkt in eine der Dealloc-Methoden ein. Sie werden nie getroffen.

Hier ist ein großes Argument darüber: link text

Hinweis: Objective C dealloc ist nicht das gleiche wie ein C++ Deconstructor. In einem Dekonstruktor können Sie Dateien, Handles usw. schließen. In Objective C dient dealloc nur zur Freigabe von Speicher. Sie müssen Ihre anderen Ressourcen früher schließen, da dealloc möglicherweise nie aufgerufen wird.

Answer 4

Releasing kann Ihnen helfen, Fehler zu finden. In den meisten Fällen werden dynamische Speicherprobleme zur Freigabezeit ausgelöst (z. B. wenn Sie versuchen, ein ungültiges Objekt freizugeben).Immer zu veröffentlichen kann Ihnen helfen, Fehler zu finden, die sonst schwer zu finden wären.