重新分配失败的可能性有多大？

Question

与malloc类似，当它用完可用内存时会失败吗？或者可能还有其他原因吗？

Answer 1

任何分配函数（malloc、realloc、calloc 以及 POSIX 上的 posix_memalign）都可能因任何原因而失败原因如下，可能还有其他原因：

• 您已经用完了整个虚拟地址空间，或者至少是其中的可用部分。在 32 位机器上，只有 4GB 的地址，并且可能保留 1GB 左右的地址供操作系统内核使用。即使您的机器有 16GB 物理内存，单个进程也不能使用超过其地址的内存。
• 您尚未用完虚拟地址空间，但您已将其严重碎片化，以至于没有所请求大小的连续地址范围可用。如果您成功分配 6 512MB 块，释放所有其他块，然后尝试分配 1GB 块，则可能会发生这种情况（在 32 位计算机上）。当然，还有很多内存较小的其他示例。
• 您的计算机已耗尽物理内存，这可能是由于您自己的程序已使用了所有物理内存，也可能是由于该计算机上运行的其他程序已使用了所有物理内存。某些系统（默认配置下的 Linux）会过度使用，这意味着在这种情况下 malloc 不会失败，但操作系统稍后会在发现时杀死一个或多个程序确实没有足够的物理内存可供使用。但在健壮的系统（包括禁用过量使用的 Linux）上，如果没有剩余物理内存，malloc 将失败。

请注意，严格来说，分配函数可以在任何时间因任何原因失败。最大限度地减少失败是一个实施质量问题。即使减小对象的大小，realloc 也可能会失败；这可能发生在严格按大小隔离分配的实现上。当然，在这种情况下，您可以简单地继续使用旧的（较大的）对象。

Answer 2

您应该将 realloc 视为这样工作：

void *realloc(void *oldptr, size_t newsize)
{
   size_t oldsize = __extract_size_of_malloc_block(oldptr);
   void *newptr = malloc(newsize);

   if (!newptr)
     return 0;

   if (oldsize > newsize)
     oldsize = newsize;

   memcpy(newptr, oldptr, oldsize);
   free(oldptr);
   return newptr;
}

实现可能能够比这更有效地处理特定情况，但完全按照所示方式工作的实现是 100% 正确的。这意味着 realloc(ptr, newsize) 可能会在 malloc(newsize) 失败的任何时候失败；特别是，即使您缩小分配，它也可能会失败。

现在，在现代桌面系统上，有充分的理由不尝试从 malloc 故障中恢复，而是将 malloc 包装在函数中（通常称为 xmalloc） code>)，如果 malloc 失败，则立即终止程序；当然，同样的论点也适用于realloc。情况是：

1. 桌面系统通常在“过度使用”模式下运行，假设程序实际上不会使用所有地址空间，内核会乐意分配比 RAM+swap 所能支持的更多的地址空间。如果程序确实尝试使用所有这些，它将被强制终止。在此类系统上，只有在耗尽地址空间时，malloc 才会失败，这在 32 位系统上不太可能，在 64 位系统上几乎不可能。
2. 即使您没有处于过量使用模式，桌面系统也有可能拥有如此多的 RAM 和交换空间，早在您导致 malloc 失败之前，用户就会厌倦他们的颠簸磁盘并强制终止您的程序。
3. 没有实际的方法可以测试从分配失败中恢复；即使您有一个垫片库可以准确控制对 malloc 的哪些调用失败（此类垫片在最好的情况下是困难的，在最坏的情况下是不可能创建的，具体取决于操作系统），您也必须测试2^N 种故障模式，其中 N 是程序中调用 malloc 的次数。

论点 1 和 2 不适用于嵌入式或移动系统（目前！），但论点 3 在那里仍然有效。

参数 3 仅适用于必须在每个调用站点检查和传播分配失败的程序。如果您很幸运能够按照预期使用 C++（即有例外），您可以依靠编译器为您创建错误恢复路径，因此测试负担会大大减轻。如今，在任何值得使用的高级语言中，您都有异常和垃圾收集器，这意味着即使您愿意，也不必担心分配失败。

Answer 3

我想说它主要是特定于实现的。有些实施很可能会失败。有些可能会在重新分配之前使程序的其他部分失败。始终保持防御状态并检查是否失败。

请记住释放您尝试重新分配的旧指针。

ptr=realloc(ptr,10);

总是可能存在内存泄漏。

总是这样做：

void *tmp=ptr;
if(ptr=realloc(ptr,10)==NULL){
  free(tmp);
  //handle error...
}

Answer 4

你有两个问题。

在大多数现代系统上，malloc 或 realloc 失败的可能性可以忽略不计。仅当虚拟内存不足时才会发生这种情况。您的系统将在访问内存时失败，而不是在保留内存时失败。

Wrt 失败realloc 和malloc 几乎相同。 realloc 可能另外失败的唯一原因是您给它一个错误的参数，即尚未使用 malloc 或 realloc 分配的内存或者之前已经免费了。

编辑：鉴于R.的评论。是的，您可以配置您的系统，使其在分配时失败。但首先，据我所知，这不是默认设置。它需要以这种方式配置权限，作为应用程序程序员，这不是您可以指望的。其次，即使您有一个以这种方式配置的系统，只有当您的可用交换空间被耗尽时才会出错。通常，您的机器在此之前很久就会无法使用：它将在您的硬盘上进行机械计算（又称交换）。

Answer 5

来自zwol的答案< /a>:

现在，在现代桌面系统上，有充分的理由不尝试从 malloc 故障中恢复，而是将 malloc 包装在函数中（通常称为 xmalloc），如果 malloc 失败，则立即终止程序；
当然，同样的论点也适用于realloc。

您可以看到 Git 2.29（2020 年第 4 季度）应用了该原则：xrealloc() 可以发送已释放的非 NULL 指针，这一点已得到修复。

请参阅 提交 6479ea4（2020 年 9 月 2 日），作者：杰夫·金 (peff)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 56b891e，2020 年 9 月 3 日）}

xrealloc：不要重用由零长度 realloc()

^{签字人：杰夫·金}

此补丁修复了 xrealloc(ptr, 0) 可能在某些平台（至少包括 glibc）上双重释放并损坏堆的错误。

C99 标准对 malloc 的描述（第 7.20.3 节）：

如果请求的空间大小为零，则行为为
实现定义的：要么返回空指针，要么返回
行为就好像大小是某个非零值，除了
返回的指针不得用于访问对象。  

因此我们可能会返回NULL，或者我们可能会得到一个实际的指针（但我们不允许查看其内容）。

为了简化代码，我们的 xmalloc() 通过将 NULL 返回转换为单字节分配来处理它。
这样呼叫者就可以获得一致的行为。这是早在 4e7a2eccc2 ("?alloc : 当要求零字节时不返回 NULL", 2005-12-29, Git v1.1.0 -- 合并）。

我们还给予了 xcalloc() 和 xrealloc() 相同的处理。根据 C99 的说法，这很好；上面的文字位于适用于所有三个的段落中。

但是在这种情况下我们传递给 realloc() 的内存会发生什么情况呢？即，如果我们这样做：

ret = realloc(ptr, 0);  

并且“ptr”不是NULL，但我们得到了NULL：“ptr”仍然有效吗？
C99 没有具体涵盖这种情况，但说（第 7.20.3.4 节）：

realloc函数释放ptr指向的旧对象并
返回一个指向新对象的指针，该对象的大小由 size 指定。  

因此“ptr”现在已被释放，我们只需查看“ret”。
由于“ret”是NULL，这意味着我们根本没有分配的对象。但这还不是故事的全部。它还说：

如果无法为新对象分配内存，则旧对象被分配
没有被释放并且它的值没有改变。
[...]
realloc 函数返回一个指向新对象的指针（可能是
与指向旧对象的指针具有相同的值），或空指针
如果无法分配新对象。  

因此，如果我们看到 NULL 返回一个非零大小，我们可以预期原始对象仍然有效。
但对于非零大小，它是不明确的。 NULL 返回可能意味着失败（在这种情况下对象有效），或者可能意味着我们成功分配了任何内容，并使用 NULL 来表示这一点。

realloc() 的 glibc 联机帮助页明确指出：

[...]如果 size 等于 0，并且 ptr 不为 NULL，则调用为
相当于 free(ptr)。  

同样，StackOverflow 对“malloc(0) 返回什么？”的回答:
声称 C89 提供了类似的指导（但我没有副本来验证）。

评论对“malloc(0) 的意义何在？”的回答 声称 Microsoft 的 CRT 具有相同的行为。

但是我们当前的“用 1 个字节重试”代码再次传递了原始指针。
因此，在glibc上，我们有效地free()指针，然后尝试再次realloc()它，这是未定义的行为。

这里最简单的解决方法是将“ret”（我们知道它是NULL）传递给后续的realloc().
但这意味着不释放原始指针的系统会泄漏它。目前尚不清楚是否存在任何这样的系统，并且对标准的解释似乎不太可能（我希望在这种情况下不释放的系统只是返回原始指针）。
但为了安全起见，很容易犯错误，根本不向 realloc() 传递零大小。