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

来源:互联网 发布:sql if else 循环 编辑:程序博客网 时间:2024/04/27 05:41
作为一个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的客观存在也要求监控和自动重启。