是否需要分配内存后检查NULL，当内核使用过量内存 [英] Is there a need to check for NULL after allocating memory, when kernel uses overcommit memory
问题描述
这是一般的做法一个malloc（后检查NULL（内存是否成功分配）），有的东西一样
It is general practice to check for NULL (whether memory is successfully allocated) after a malloc(), some thing like
void *ptr = malloc(10);
if (ptr != NULL) {
// do some thing usefull
} else {
// no memory. safely return/throw ...
}
在内核中启用内存过量使用，有没有得到NULL的机会吗？我应该遵循宗教NULL检查每个分配的做法？会的malloc aggresive过量机制返回NULL inspite（我猜值1）？
with memory overcommit enabled in kernel, is there a chance of getting NULL? Should I follow the practice of religiously checking NULL for each allocation? Will malloc return NULL inspite of aggresive overcommit mechanism (I guess value 1)?
事实上的Android内核的问题使用内存过量使用（不知道价值，很想知道它（过量值）和它的意义）。一些框架源代码（C / C ++）code中的Android（可能是第三方）的不检查分配后空也不抓bad_alloc。我缺少的东西吗？
As a matter of fact Android kernel uses memory overcommit (not sure about the value, would love to know it(overcommit value) and its significance). Some of the framework source(C/C++) code in Android (might be 3rd party) doesn't check for NULL nor catch bad_alloc after allocations. Am I missing something?
有在SO就过量使用内存某些线程，但他们没有解决我的困惑。
There are some threads in SO regarding overcommit memory, but none of them resolved my confusion.
编辑：如果正在使用激进的过载NULL不会被退回（假设1）。当有可用的，最多在试图访问分配的内存（写入到分配的内存）无物理内存，OOM会杀死一些进程，直到它反过来（假设2）被处死的应用程序分配内存。在这两种情况下，我没有看到任何需要cheking NULL（内存分配得到或进程被杀死）。
我的权利在我的假设？结果
可移植性是不是这个问题值得关注。
If aggressive overcommit is being employed NULL wont be returned(assumption 1). When there is no physical memory available and up on trying to access the allocated memory (write in to the memory allocated), OOM will kill some process and allocates memory for the application till it gets killed in turn(assumption 2). In either case i dont see any need for cheking NULL (memory getting allocated or process getting killed).
am i right in my assumptions?
Portability is not a concern for this question.
推荐答案
是的，你还是应该检查由的malloc 返回故障。在这种overcommits内存，你将不能够检测并从故障中恢复，由于环境中运行出来的，当你写的已经由previous呼叫分配给你的程序的地址空间部分所需物理存储环境到的malloc 。
Yes, you should still check for failures returned by malloc. In an environment that overcommits memory you will not be able to detect and recover from failures due to the environment running out of physical storage required when you write to parts of the address space that have been allocated to your program by a previous call to malloc.
不过，这不是会导致的malloc 在传统的环境中失败的唯一问题。一种用于存储特别大的块当你的程序的地址空间变得支离破碎甚至可能会失败，如果有足够的潜在总物理内存来满足请求的要求。因为有免费的地址空间不连续的范围的malloc 一定会失败。这种类型的故障必须由的malloc 发出信号返回 NULL ，环境是否过量使用内存。
However, this is not the only problem that would cause a malloc to fail in a traditional environment. A request for a particularly large block of memory when the address space of your program has become fragmented may fail even if there is potentially enough total physical memory to satisfy the request. Because there is no contiguous range of free address space malloc must fail. This type of failure must be signaled by malloc returning NULL, whether or not the environment is overcommitting memory.
这篇关于是否需要分配内存后检查NULL，当内核使用过量内存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
