[C++] 应该如何应对OOM？

作为一个C/C++程序员，应该怎么应对OOM，尤其是作为一个linux server开发者？

很多人喜欢逻辑上‘完美’的解决方案， 下面两个是常见的：

1，new失败的时候抛异常，外面进行catch和拒绝
2，程序判断malloc/new的返回值，为NULL就拒绝请求

这两个看似完美的方案都有巨大的缺陷。

1，new失败抛异常会导致C++不能正确的释放资源。除非C++程序员精心的设计每个类，并且精心的进行每次catch，这实际上是不可能的；而且常常会导致各种复杂性和不稳定。
2，程序判断malloc/new的返回值，这个相对靠谱一点，但实际上也会把程序变得复杂，而且没法控制类库里面malloc/new失败之后会做什么。而且无法解决操作系统的oom_killer带来的问题。
3， 无法处理lazy allocation和memory overcommit。这是最致命的。

正确的解决方案是什么？

1，事先规划内存，像memcached、squid那样，规定自己最多用多少内存。如果要拒绝请求，在malloc之前就拒绝，永远不要碰到oom这种事情。因为oom不仅会给自己带来麻烦，还会通过oom_killer给操作系统和其他进程带去麻烦。
2，信任oom_killer，相信内存不足的时候系统会给你腾出你该有的内存。（内存不足的时候malloc/new是会阻塞的等oom_killer把活儿干完的。所以，如果malloc/new失败了，那就是连oom_killer都找不出可杀的进程了）
3，不要信任oom_killer，是的，这和上面是矛盾的。oom_killer拥有非常高的优先级，常常会引起swap，会造成各种意料之外的副作用。你最好永远都不要遇到它。
4，在linux下要信任glibc的malloc，网上很多文章介绍说malloc碎片什么的，都是炒冷饭。如果你不明白原理和最新的进展，那么就信任malloc。实在内存分配多，就搞个mem pool。
5，做好监控，和自动重启。由于oom_killer等意外的存在，监控和自动重启是必须的。另外，coredump的客观存在也要求监控和自动重启。

转载于:https://www.cnblogs.com/hehe520/archive/2012/05/09/6330382.html