可能重复:
What's the graceful way of handling out of memory situations in C/C++?
您好,
乍一看,这似乎是一个简单的问题。而且我不想开始讨论什么是最好的方法......上下文:Windows> = 5,32位,C ++,Windows SDK / Win32 API
但在问similar question之后,我读了一些MSDN和Win32内存管理,所以现在我更担心如果分配失败该怎么办,让我们说C ++ new运算符。
所以我现在非常感兴趣你如何实现(并隐含地,如果你实现的话)在你的应用程序中为OOM实现错误处理。
如果,哪里(主要功能?),哪些操作(分配),以及如何处理OOM错误。
(我的意思并不是主观,将其转化为偏好问题,我只是想看到不同的方法来解释不同的条件或适应不同的情况。所以随时为GUI应用程序,服务提供答案 - 用户模式的东西....)
对OOM的一些典型反应,以表明我的意思:
感谢您的回答!
最好的解释方式将获得接受的答案的极大荣誉:D - 即使它只包含MessageBox行,但解释了为什么其他地方无用,错误或不必要。
编辑:到目前为止,我感谢您的回答,但我错过了一些实际的回答;我的意思是大多数人说不要介意OOM,因为当没有内存时(系统挂起/性能不佳)你无法做任何事情。但这是否意味着避免对OOM进行任何错误处理?或者只在main中显示一个简单的try-catch,显示一个MessageBox?
答案 0 :(得分:4)
你完成同样的事情:
您向客户发送了一条非常简陋的消息,您可以为编写这些糟糕的代码而道歉并承诺修复错误的交付日期。其他任何事情都不够好。您希望如何获得通知取决于您。
答案 1 :(得分:4)
在大多数现代操作系统上,OOM将在系统完全无法使用很久之后发生,因为在实际耗尽之前,虚拟内存系统将开始分页物理RAM,以便为分配额外的虚拟内存腾出空间,而且很可能很难因为页面必须以越来越高的频率进行交换,所以磁盘会像疯了一样开始颠簸。
简而言之,在你去OOM条件附近的任何地方之前,你都有更严重的问题要处理。
附注:目前,上述声明并不像以前那样真实,因为具有大量物理RAM的32位计算机可能会在开始寻呼之前耗尽其地址空间。但这仍然不常见,只是暂时的,因为64位会逐渐升级并接近主流应用。
编辑:似乎64位已经成为主流。在浏览戴尔网站时,我找不到一个32位系统。
答案 2 :(得分:1)
基本上,您应该尽一切可能避免让用户丢失重要数据。如果磁盘空间可用,则可以写出恢复文件。如果您想要超级有用,可以在程序打开时分配恢复文件,以确保在紧急情况下它们可用。
答案 3 :(得分:1)
只需显示一条消息或对话框(取决于您是否在终端或窗口系统中),说“错误:内存不足”,可能带有调试信息,并包含一个供用户提交错误报告的选项,或者链接到他们可以做到的地方。
如果你真的没有记忆,那么说实话,除了优雅地退出之外别无其他任何事情,试图处理错误是没用的,因为你无能为力。
答案 4 :(得分:0)
在我的情况下,当你有一个应用程序将内存分解得太多而无法分配处理大量节点所需的连续块时会发生什么?
好吧,我尽可能地分开处理。
对于OOM,您可以做同样的事情,将您的流程切成尽可能多的部分并按顺序执行。
当然,为了处理错误,直到你修复它(如果你可以!),你通常会让它崩溃。然后你确定那些内存分配失败(就像你从未预料到的那样)并将错误消息直接发送给用户“哦,亲爱的,一切都出错了。请与支持部门联系”。在任何情况下,您都可以通知用户。虽然,它的既定做法是使用app当前使用的任何机制 - 如果它写入日志文件,那么,如果它显示错误对话框,则执行相同操作,如果它使用Windows“发送信息到microsoft”对话框,请执行在前面,让它成为坏消息的承载者 - 用户期待它,所以不要试图聪明并做其他事情。
答案 5 :(得分:0)
这取决于您的应用,技能水平和时间。如果它需要全天候运行,那么显然你必须处理它。这取决于实际情况。也许有可能尝试更慢的算法,但需要更少的堆。也许你可以添加功能,这样如果确实发生了OOM,你的应用程序就能自行清理,所以你可以再试一次。
所以我认为答案是'以上所有!',除了让它崩溃。你为自己的工作感到自豪,对吗?
不要陷入'有大量内存,所以它可能不会发生'陷阱。如果每个应用程序编写者都采取这种态度,你会更频繁地看到OOM,而不是所有应用程序都在桌面计算机上运行,例如拿手机,你很可能在RAM饥饿的平台上遇到这样的OOM相信我!
如果所有其他方法都失败,则会显示一条有用的消息(假设MessageBox有足够的内存!)