我已经编程了很长时间,我看到的程序,当它们内存不足时,会尝试清理并退出,即优雅地失败.我不记得上次我看到一个人真正尝试恢复并继续正常运行.
如此多的处理依赖于能够成功分配内存,特别是在垃圾收集语言中,似乎内存不足错误应归类为不可恢复.(不可恢复的错误包括堆栈溢出等.)
使其成为可恢复错误的令人信服的理由是什么？
这真的取决于你正在建设什么.
网络服务器失败一个请求/响应对然后继续进行进一步的请求并非完全不合理.你必须确定单一故障不会对全球状态产生不利影响 - 但这将是一个棘手的问题.鉴于失败导致大多数托管环境(例如.NET和Java)中的异常,我怀疑如果在"用户代码"中处理异常,它将可以在将来的请求中恢复 - 例如,如果一个请求试图分配10GB的内存和失败了,这不应该损害系统的其余部分.但是,如果系统在尝试将请求移交给用户代码时内存不足,那么这种事情可能会更糟糕.
在库中,您希望有效地复制文件.当你这样做时,你会发现使用少量大块复制比复制大量小块更有效(比如,通过复制15个1MB块比复制15'000复制15MB文件更快1K块).
但代码适用于任何块大小.因此,虽然使用1MB块可能会更快,但如果您为复制了大量文件的系统进行设计,那么捕获OutOfMemoryError并减少块大小可能是明智之举,直到您成功为止.
另一个地方是存储在数据库中的Object的缓存.您希望尽可能多地在缓存中保留对象,但不希望干扰应用程序的其余部分.由于可以重新创建这些对象,因此这是一种节省内存的智能方法,可以将缓存附加到内存处理程序以删除条目,直到应用程序的其余部分再次有足够的空间来呼吸.
最后,对于图像处理,您希望尽可能多地将图像加载到内存中.同样,OOM处理程序允许您在不事先知道用户或操作系统将为您的代码授予多少内存的情况下实现该操作.
[编辑]请注意,我在这里假设您已经为应用程序提供了固定数量的内存,并且此数量小于不包括交换空间的总可用内存.如果你可以分配这么多的内存,那么它的一部分必须被换掉,我的几条评论就再也没有意义了.
在使用大型数组执行算术时,MATLAB的用户总是耗尽内存.例如,如果变量x适合内存并且它们运行"x + 1",那么MATLAB为结果分配空间然后填充它.如果分配失败MATLAB错误,用户可以尝试其他方法.如果在这个用例出现时MATLAB退出,那将是一场灾难.
OOM应该是可恢复的,因为关闭不是从OOM恢复的唯一策略.
在应用程序级别实际上有一个非常标准的OOM问题解决方案.作为应用程序设计的一部分,确定从内存不足情况恢复所需的安全最小内存量.(例如,自动保存文档所需的内存,调出警告对话框,日志关闭数据).
在应用程序开始时或在关键块开始时,预先分配该内存量.如果检测到内存不足情况,请释放保护内存并执行恢复.该策略仍然可能失败,但总的来说,它可以带来巨大的回报.
请注意,应用程序无需关闭.它可以显示模式对话框,直到解决了OOM条件.
我不是100%肯定,但我很确定' Code Complete '(任何受人尊敬的软件工程师必读)都涵盖了这一点.
PS您可以扩展您的应用程序框架以帮助实现此策略,但请不要在库中实现此类策略(良好的库未经应用程序同意不做出全局决策)
我认为,就像许多事情一样,这是成本/收益分析.你可以尝试从malloc()失败中尝试恢复 - 虽然它可能很难(你的处理程序最好不要因为它应该处理的相同内存短缺而违反).
您已经注意到最常见的情况是清理并且优雅地失败.在这种情况下,已经确定优雅地中止的成本低于恢复中的开发成本和性能成本的组合.
我相信你能想到你自己的例子,终止程序是一个非常昂贵的选择(生命支持机器,飞船控制,长期运行和时间关键的财务计算等) - 虽然第一道防线是当然要确保程序具有可预测的内存使用量,并且环境可以提供该内存.
我正在研究一个为IO缓存分配内存以提高性能的系统.然后,在检测到OOM时,需要将其中的一部分恢复,以便业务逻辑可以继续,即使这意味着更少的IO缓存和略低的写入性能.
我还使用了一个嵌入式Java应用程序,它试图通过强制垃圾收集来管理OOM,可选地释放一些非关键对象,如预取或缓存数据.
OOM处理的主要问题是:
1)能够在发生的地方重新尝试,或者能够回滚并从更高的位置重新尝试.大多数当代程序过于依赖语言而无法真正管理它们最终的位置以及如何重新尝试操作.如果不是为了保留操作,通常会丢失操作的上下文
2)能够实际释放一些内存.这意味着一种资源管理器,它知道什么对象是关键的,什么不是,并且系统能够在以后变得关键时重新请求释放的对象
另一个重要问题是能够在不触发另一个OOM情况的情况下回滚.这在高级语言中很难控制.
此外,底层操作系统必须在OOM方面表现出可预测性.例如,如果启用了内存过量使用,则Linux不会.许多支持交换的系统将比将OOM报告给违规应用程序更快地死亡.
而且,当你的进程不是创造了这种情况的情况就是如此,因此如果违规进程继续泄漏,释放内存也无济于事.
由于这一切,它通常是采用这种技术的大型嵌入式系统,因为它们可以控制操作系统和内存以实现它们,以及实现它们的纪律/动机.
京公网安备 11010802040832号 | 京ICP备19059560号-6 