Delphi 内存异常是否可恢复？

在捕获到

EOutOfMemory

异常或堆或堆栈很可能损坏后继续执行是否有意义

---

我不是说以前的内存损坏导致

EOutOfMemory

的情况，而是说调用

GetMem

并捕获

EOutOfMemory

的正确代码。在我看来，尝试从

EOutOfMemory

继续下去是没有意义的。根据我的经验，堆被破坏的可能性非常高，并且可以预期将来会出现错误。通常，最安全的做法是终止流程。

一般来说，我同意尝试恢复没有意义。但它在特定情况下可能有用。例如，根据用户的选择分配大量内存，如果失败，您可以完全退出，让他们使用不同的设置重试。我这样做是为了将点云转换为三维网格，其中包括一些事先不知道内存需求的步骤。它只需要对您想要恢复的步骤进行仔细编码，并提供一个立即且干净的回退路径。例如，我的一些数据结构是位图或缓冲区，每行单独分配，以最大限度地减少内存碎片的问题。构造器已尝试。。。除了处理和抛出OutofMemory异常之外，析构函数释放已经分配的任何行。我不能保证它会一直工作，但它工作得足够好，值得一做。

我怀疑它不可恢复，但我不确定。我不知道FastMM的内部结构，可能还有Windows内存管理。在我们的服务器中，我们在初始化时声明内存是在OutofMemory上释放的，因此在我们终止进程之前，异常和其他日志记录有一定的操作空间。@Marjannema这也有风险，至少如果您的其他代码将使用损坏的堆。请注意，Delphi RTL在启动时分配单个

EOutOfMemory

实例，这样它就不需要进行堆分配来引发异常。@MatheusFreitas

Halt（0）

调用单元终结，您可以预期它会失败。我说您应该调用

ExitProcess

@MatheusFreitas，它来自

outofmemory

。据我所知，无论它在哪里被提出，游戏就结束了，所以，是的，我会调用

ExitProcess

。有时是这样。我看到有人试图在Win32应用程序中分配3GB内存缓冲区：-），所以这取决于你在出错之前真正尝试了什么。在某些情况下是可恢复的。