很多人喜欢逻辑上‘完美’的解决方案,下面两个是常见的:
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的客观存在也要求监控和自动重启。