Ist "Speicherplatzmangel" ein behebbarer Fehler?

Question

Ich programmiere schon sehr lange, und die Programme, die ich sehe, wenn ihnen der Speicher ausgeht, versuchen aufzuräumen und sich zu beenden, d.h. sie scheitern mit Anstand. Ich kann mich nicht erinnern, wann ich das letzte Mal gesehen habe, dass ein Programm tatsächlich versucht hat, sich zu erholen und normal weiterzuarbeiten.

Ein so großer Teil der Verarbeitung hängt davon ab, dass Speicher erfolgreich zugewiesen werden kann, insbesondere in Sprachen mit Garbage-Collector, dass Fehler außerhalb des Speichers als nicht wiederherstellbar eingestuft werden sollten. (Zu den nicht wiederherstellbaren Fehlern gehören Dinge wie Stapelüberläufe.)

Welches zwingende Argument spricht dafür, dass es sich um einen anfechtbaren Fehler handelt?

Answer 1

Speicherplatzmangel bedeutet normalerweise, dass Sie Ihre Arbeit beenden müssen. Wenn Sie jedoch bei der Bereinigung vorsichtig sind, kann das Programm selbst funktionsfähig bleiben und auf andere Anfragen reagieren. Es ist besser, wenn ein Programm sagt: "Tut mir leid, ich habe nicht genug Speicher", als dass es sagt: "Tut mir leid, kein Speicher mehr, ich beende das Programm."

Answer 2

Speichermangel kann entweder durch die Erschöpfung des freien Speichers oder durch den Versuch, einen unangemessen großen Block (etwa ein Gigabyte) zuzuweisen, verursacht werden. In den Fällen, in denen der Speicher erschöpft ist, wirkt sich das auf das gesamte System aus und beeinträchtigt in der Regel auch andere Anwendungen und Systemdienste, so dass das gesamte System instabil werden kann und es ratsam ist, den Vorgang zu vergessen und neu zu starten. In Fällen von "unangemessen großen Blöcken" kommt es nicht zu einem Engpass und es ist sicher, weiterzumachen. Das Problem ist, dass Sie nicht automatisch erkennen können, welcher Fall vorliegt. Daher ist es sicherer, den Fehler nicht behebbar zu machen und für jeden Fall, in dem dieser Fehler auftritt, eine Abhilfemaßnahme zu finden - Ihr Programm sollte weniger Speicher verwenden oder in einigen Fällen einfach Fehler im Code beheben, der die Speicherzuweisung aufruft.

Answer 3

Es gibt hier bereits viele gute Antworten. Aber ich möchte mit einer anderen Perspektive beitragen.

Die Erschöpfung so gut wie jeder wiederverwendbaren Ressource sollte im Allgemeinen rückgewinnbar sein. Der Grund dafür ist, dass jeder einzelne Teil eines Programms im Grunde ein Unterprogramm ist. Nur weil ein Teilprogramm zum jetzigen Zeitpunkt nicht zu Ende geführt werden kann, bedeutet das nicht, dass der gesamte Zustand des Programms Müll ist. Nur weil der Parkplatz voller Autos ist, heißt das nicht, dass Sie Ihr Auto zu Schrott fahren. Entweder man wartet eine Weile, bis ein Stand frei wird, oder man fährt in einen weiter entfernten Laden, um seine Kekse zu kaufen.

In den meisten Fällen gibt es einen alternativen Weg. Wenn ein Fehler nicht mehr behoben werden kann, entfallen viele Möglichkeiten, und niemand von uns möchte, dass jemand für uns entscheidet, was wir tun können und was nicht.

Das Gleiche gilt für den Speicherplatz. Es ist wirklich die gleiche Argumentation. Und im Gegensatz zu Ihrer Unterstellung, dass ein Stapelüberlauf nicht behebbar ist, würde ich sagen, dass dies eine willkürliche Einschränkung ist. Es gibt keinen guten Grund, warum man nicht in der Lage sein sollte, eine Exception auszulösen (und dabei eine Menge Frames zu zerstören) und dann einen anderen, weniger effizienten Ansatz zu verwenden, um die Aufgabe zu erledigen.

Meine zwei Cents :-)

Answer 4

Wenn Sie wirklich keinen Speicher mehr haben, sind Sie verloren, da Sie nichts mehr freigeben können.

Wenn Sie keinen Speicher mehr haben, aber etwas wie ein Garbage Collector eingreifen und Speicher freigeben kann, sind Sie noch nicht tot.

Das andere Problem ist die Fragmentierung. Auch wenn der Speicher nicht leer (fragmentiert) ist, kann es sein, dass Sie nicht in der Lage sind, den großen Speicherplatz zuzuweisen, den Sie haben möchten.

Answer 5

Ich weiß, dass Sie nach Argumenten dafür gefragt haben, aber ich kann nur Argumente dagegen erkennen.

Ich sehe keine Möglichkeit, dies in einer Multithreading-Anwendung zu erreichen. Woher wissen Sie, welcher Thread tatsächlich für den Out-of-Memory-Fehler verantwortlich ist? Ein Thread könnte ständig neuen Speicher zuweisen und gc-roots auf 99 % des Heaps haben, aber die erste Zuweisung, die fehlschlägt, erfolgt in einem anderen Thread.

Ein praktisches Beispiel: Wenn in unserer Java-Anwendung (die auf einem JBoss-Server läuft) ein OutOfMemoryError auftritt, ist es nicht so, dass ein Thread stirbt und der Rest des Servers weiterläuft: Nein, es gibt mehrere OOMEs, die mehrere Threads (von denen einige JBoss-interne Threads sind) beenden. Ich wüsste nicht, was ich als Programmierer tun könnte, um das zu beheben - oder auch, was JBoss tun könnte, um das zu beheben. Tatsächlich bin ich mir nicht einmal sicher, ob man das KANN: Die javadoc für VirtualMachineError deutet darauf hin, dass die JVM nach dem Auftreten eines solchen Fehlers "kaputt" sein kann. Aber vielleicht war die Frage eher auf das Sprachdesign gerichtet.