马洛克

Question

所以，我有这段代码：

#include <stdio.h>
#include <stdlib.h>

int main()
{
    char *p;
    long n = 1;

    while(1) {
        p = malloc(n * sizeof(char));
        //p = calloc(n, sizeof(char));

        if(p) {
            printf("[%ld] Memory allocation successful! Address: %p\n", n , p);
            n++;
         } else {
            printf("No more memory! Sorry...");
            break;
        }
    }

    free(p);
    getch();
    return 0;
}

我在Windows上运行。有趣的是：

>

如果我们使用calloc，程序会分配大约2 GB的内存，然后停止（此处照片=

（奇怪的测试）：如果我们同时使用这两者，它将使用最大值（~400MB~2GB）/2=

然而，如果我在Linux上运行相同的代码，分配会一直持续下去（在600k分配和使用了许多GB之后，它仍然会继续，直到最终被杀死），并且使用的内存量大致相同。

所以我的问题是：他们不应该分配相同数量的内存吗？我认为唯一的区别是calloc用零初始化内存（malloc返回未初始化的内存）。为什么它只发生在Windows上？同时很奇怪也很有趣。

希望你能帮我解释一下。谢谢

编辑：

>

de::BGNU GCC编译器锁定13.12

Windows 10（x64）

Linux Mint 17.2“Rafaela”-肉桂色（64位）（用于Linux测试）

Answer 1

查看程序输出，实际上分配了相同数量的块，65188用于malloc，65189用于calloc。忽略开销，这略低于2GB的内存。

我的猜测是，您在32位模式下编译（指针转储为32位），这将单个用户进程可用的内存量限制在2GB以下。进程图显示上的差异来自于程序如何使用其分配的内存。

malloc版本不涉及分配的页面：超过四分之三的页面实际上没有映射，因此只有430MB。

calloc版本显示了2GB的映射内存：很可能你的C库函数会清除分配的内存，即使是从操作系统获得的页面。这不是最优的，但只有在不接触分配的内存时才可见，这是一种特殊情况。然而，不清除从操作系统获得的页面会更快，因为它们被指定为零填充。

在Linux中，您可能需要编译到64位，从而可以访问超过2GB的虚拟进程空间。由于您不触摸内存，因此它不会被映射，同样的情况似乎也发生在calloc中。C运行时是不同的（Linux上的64位glibc，Windows上的32位Microsoft库）。您应该在Linux的不同终端中使用top或ps来检查在这两种情况下实际映射到进程的内存量。