为什么这个吃记忆的人真的不吃记忆？

我想创建一个程序来模拟Unix服务器上的内存不足（OOM）情况。我创建了这个超级简单的内存消耗者：

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

unsigned long long memory_to_eat = 1024 * 50000;
size_t eaten_memory = 0;
void *memory = NULL;

int eat_kilobyte()
{
    memory = realloc(memory, (eaten_memory * 1024) + 1024);
    if (memory == NULL)
    {
        // realloc failed here - we probably can't allocate more memory for whatever reason
        return 1;
    }
    else
    {
        eaten_memory++;
        return 0;
    }
}

int main(int argc, char **argv)
{
    printf("I will try to eat %i kb of ram\n", memory_to_eat);
    int megabyte = 0;
    while (memory_to_eat > 0)
    {
        memory_to_eat--;
        if (eat_kilobyte())
        {
            printf("Failed to allocate more memory! Stucked at %i kb :(\n", eaten_memory);
            return 200;
        }
        if (megabyte++ >= 1024)
        {
            printf("Eaten 1 MB of ram\n");
            megabyte = 0;
        }
    }
    printf("Successfully eaten requested memory!\n");
    free(memory);
    return 0;
}

它消耗的内存与定义的内存一样多memory_to_eat，现在恰好是50 GB的RAM。它按1 MB分配内存，并精确打印无法分配更多内存的点，这样我就知道它设法吃掉了哪个最大值。

问题是它有效。即使在具有1 GB物理内存的系统上。

当我检查顶部时，我看到该进程占用了50 GB的虚拟内存，而占用的驻留内存不到1 MB。有没有办法创建确实消耗掉它的内存消耗者？

系统规范：Linux内核3.16（Debian）最有可能启用了过量使用（不确定如何检出），并且没有交换和虚拟化。

当您的malloc()实现从系统内核请求内存（通过sbrk()或mmap()系统调用）时，内核仅记录您已请求内存以及将其放置在地址空间中的位置。它实际上还没有映射那些页面。

当进程随后访问新区域内的内存时，硬件将识别分段错误并向内核发出警报。内核然后在其自己的数据结构中查找该页面，并发现那里应该有一个零页面，因此它映射到一个零页面（可能首先从页面高速缓存中逐出了一个页面）并从中断返回。您的过程没有意识到这一切都发生了，内核操作是完全透明的（内核工作时的短暂延迟除外）。

此优化使系统调用可以非常快速地返回，并且最重要的是，它避免了在进行映射时将任何资源提交给您的进程。这样，进程就可以保留正常情况下不需要的相当大的缓冲区，而不必担心会占用过多的内存。

因此，如果要对内存消耗程序进行编程，则绝对必须对分配的内存进行实际操作。为此，您只需要在代码中添加一行：

int eat_kilobyte()
{
    if (memory == NULL)
        memory = malloc(1024);
    else
        memory = realloc(memory, (eaten_memory * 1024) + 1024);
    if (memory == NULL)
    {
        return 1;
    }
    else
    {
        //Force the kernel to map the containing memory page.
        ((char*)memory)[1024*eaten_memory] = 42;

        eaten_memory++;
        return 0;
    }
}

请注意，在每个页面中写入单个字节（在X86上包含4096个字节）就足够了。那是因为从内核到进程的所有内存分配都是以内存页面粒度完成的，这又是因为硬件不允许以较小粒度进行分页。

所有虚拟页面均以写时复制开始，映射到相同的清零物理页面。要用尽物理页面，可以通过在每个虚拟页面中写入内容来弄脏它们。

如果以root用户身份运行，则可以在分配页面时使用mlock(2)或mlockall(2)让内核连接页面，而不必弄脏页面。（普通的非root用户ulimit -l只能使用64kiB。）

正如许多其他人所建议的那样，除非您进行写入，否则Linux内核似乎并没有真正分配内存。

代码的改进版本，可以执行OP所需的功能：

这也解决了printf格式字符串与memory_to_eat和eaten_memory类型不匹配的问题，%zi用于打印size_t整数。可以选择将要占用的内存大小（以kiB为单位）指定为命令行arg。

使用全局变量并且以1k而不是4k页增长的混乱设计没有改变。

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

size_t memory_to_eat = 1024 * 50000;
size_t eaten_memory = 0;
char *memory = NULL;

void write_kilobyte(char *pointer, size_t offset)
{
    int size = 0;
    while (size < 1024)
    {   // writing one byte per page is enough, this is overkill
        pointer[offset + (size_t) size++] = 1;
    }
}

int eat_kilobyte()
{
    if (memory == NULL)
    {
        memory = malloc(1024);
    } else
    {
        memory = realloc(memory, (eaten_memory * 1024) + 1024);
    }
    if (memory == NULL)
    {
        return 1;
    }
    else
    {
        write_kilobyte(memory, eaten_memory * 1024);
        eaten_memory++;
        return 0;
    }
}

int main(int argc, char **argv)
{
    if (argc >= 2)
        memory_to_eat = atoll(argv[1]);

    printf("I will try to eat %zi kb of ram\n", memory_to_eat);
    int megabyte = 0;
    int megabytes = 0;
    while (memory_to_eat-- > 0)
    {
        if (eat_kilobyte())
        {
            printf("Failed to allocate more memory at %zi kb :(\n", eaten_memory);
            return 200;
        }
        if (megabyte++ >= 1024)
        {
            megabytes++;
            printf("Eaten %i  MB of ram\n", megabytes);
            megabyte = 0;
        }
    }
    printf("Successfully eaten requested memory!\n");
    free(memory);
    return 0;
}

在这里进行明智的优化。在使用内存之前，运行时实际上不会获取内存。

一个简单的方法memcpy就足以避免这种优化。（您可能会发现，calloc直到使用点为止，它仍然可以优化内存分配。）

对此并不确定，但我能做的唯一解释是linux是写时复制操作系统。当一个调用时fork，两个进程都指向相同的物理内存。仅当一个进程实际写入到存储器中时，才会复制该存储器。

我认为，实际的物理内存仅在尝试向其中写入内容时才分配。调用sbrk或mmap可能仅更新内核的内存保留。仅当我们实际尝试访问内存时才可以分配实际的RAM。