当内核使用过度使用内存时，是否需要在分配内存后检查 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 会返回 NULL(我猜值为 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内核使用内存过度使用(不确定值，很想知道它(过度使用值)及其意义).Android 中的一些框架源代码(C/C++)(可能是第 3 方)在分配后不会检查 NULL 也不会捕获 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).在任何一种情况下，我都认为不需要检查 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 返回的故障.在过度使用内存的环境中，您将无法检测到故障并从故障中恢复，因为当您写入之前调用 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 必然失败.这种类型的失败必须由返回 NULL 的 malloc 发出信号，无论环境是否过度使用内存.

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屋！