使用 malloc 分配超出现有内存量的内存

问题描述：

此代码片段每次从标准输入读取字母“u”时将分配 2Gb，并且一旦读取“a”将初始化所有分配的字符。

#include <iostream>
#include <stdlib.h>
#include <stdio.h>
#include <vector>
#define bytes 2147483648
using namespace std;
int main()
{
    char input [1];
    vector<char *> activate;
    while(input[0] != 'q')
    {
        gets (input);
        if(input[0] == 'u')
        {
            char *m = (char*)malloc(bytes);
            if(m == NULL) cout << "cant allocate mem" << endl;
            else cout << "ok" << endl;
            activate.push_back(m);
        }
        else if(input[0] == 'a')
        {
            for(int x = 0; x < activate.size(); x++)
            {
                char *m;
                m = activate[x];
                for(unsigned x = 0; x < bytes; x++)
                {
                    m[x] = 'a';
                }
            }
        }
    }
    return 0;
}

我在具有 3Gb RAM 的 Linux 虚拟机上运行此代码。在使用 htop 工具监控系统资源使用情况时，我意识到 malloc 操作并未反映在资源上。

例如，当我仅输入一次“u”（即分配 2GB 的堆内存）时，我没有看到 htop 中的内存使用量增加了 2GB。只有当我输入“a”（即初始化）时，我才看到内存使用量增加。

因此，我能够“malloc”比现有更多的堆内存。例如，我可以 malloc 6GB（这比我的 RAM 和交换内存还多），malloc 会允许这样做（即 malloc 不会返回 NULL）。但是当我尝试初始化分配的内存时，我可以看到内存和交换内存被填满，直到进程被终止。

-我的问题：

1.这是一个内核错误吗？

2.有人能向我解释一下为什么允许这种行为吗？

解决方案 1：

这称为内存过量使用。您可以通过以 root 身份运行来禁用它：

 echo 2 > /proc/sys/vm/overcommit_memory

而且这不是我喜欢的内核功能（所以我总是禁用它）。请参阅malloc(3)和mmap(2)以及proc(5)

注意：通常（但并非总是）也可以。阅读文档（特别是echo 0我刚刚链接到的手册页）。echo 2 proc

解决方案 2：

摘自man malloc（此处在线）：

默认情况下，Linux 遵循乐观内存分配策略。这意味着当 malloc() 返回非 NULL 时，无法保证内存确实可用。

因此，当您只想分配过多内存时，它会“欺骗”您，当您想要使用分配的内存时，它会尝试为您找到足够的内存，如果找不到足够的内存，它可能会崩溃。

解决方案 3：

不，这不是内核错误。您发现了一种称为延迟分页（或过量使用）的东西。

直到您将一个字节写入分配的地址，malloc (...)内核所做的只不过是“保留”地址范围。当然，这实际上取决于内存分配器和操作系统的实现，但大多数好的内存分配器和操作系统在第一次使用内存之前不会产生大部分内核开销。

囤积分配器是第一个想到的罪魁祸首，通过大量测试，我发现它几乎从不利用支持延迟分页的内核。如果您在分配后立即用零填充整个内存范围，则始终可以减轻任何分配器中延迟分页的影响。

实时操作系统（如 VxWorks）绝不会允许这种行为，因为延迟分页会导致严重的延迟。从技术上讲，它所做的只是将延迟推迟到稍后的不确定时间。

如需更详细的讨论，您可能有兴趣了解 IBM 的 AIX 操作系统如何处理页面分配和过度承诺。

解决方案 4：

这是 Basile 提到的过度使用内存的结果。不过，这个解释有点意思。

基本上，当您尝试在 Linux（POSIX？）中映射额外内存时，内核只会保留它，并且只有当您的应用程序访问其中一个保留页面时才会真正使用它。这允许多个应用程序保留比实际总 RAM/交换量更多的内存。

除非您拥有实时操作系统或能够准确知道谁将需要什么资源、何时需要以及为什么需要的东西，否则这在大多数 Linux 环境中都是理想的行为。

否则，有人可能会出现，占用所有 RAM（而不实际执行任何操作）并导致您的应用程序 OOM。

这种惰性分配的另一个例子是 mmap()，其中您有一个虚拟映射，您要映射的文件可以放进去 - 但您只有少量的实际内存专用于此工作。这允许您 mmap() 大型文件（大于可用 RAM），并像普通文件句柄一样使用它们，这很方便）

-n

解决方案 5：

初始化/使用内存应该可以工作：

memset(m, 0, bytes);

您还可以使用calloc它，不仅可以分配内存，还可以用零填充：

char* m = (char*) calloc(1, bytes);

解决方案 6：

1.这是一个内核错误吗？

不。

2.有人能向我解释一下为什么允许这种行为吗？

有几个原因：

• 减轻了解最终内存需求的需要- 让应用程序能够获得一定数量的内存，这是它认为实际需求的上限，这通常很方便。例如，如果它正在准备某种报告，无论是初始传递只是为了计算报告的最终大小，还是连续更大区域的 realloc()（存在必须复制的风险）都可能使代码变得非常复杂并损害性能，而将每个条目的最大长度乘以条目数可能非常快速和容易。如果您知道虚拟内存对于应用程序的需求而言相对充足，那么分配更大的虚拟地址空间非常便宜。

• 稀疏数据- 如果您有多余的虚拟地址空间，那么可以使用稀疏数组并使用直接索引，或者分配具有充足 capacity() 与 size() 比率的哈希表，可以实现非常高性能的系统。当数据元素大小是内存分页大小的倍数，或者比内存分页大小大很多或小的整数部分时，这两种方法效果最佳（在降低开销/浪费和有效使用内存缓存的意义上）。

• 资源共享- 假设一家 ISP 为一栋建筑中的 1000 名消费者提供“每秒 1 千兆位”的连接 - 他们知道如果所有消费者同时使用，他们将获得大约 1 兆位，但根据他们的实际经验，尽管人们要求 1 千兆位，并且希望在特定时间使用其中的很大一部分，但不可避免地会存在较低的最大值和较低的平均并发使用量。同样的洞察力应用于内存允许操作系统支持比它们原本支持的更多的应用程序，并且在满足预期方面具有合理的平均成功率。就像共享互联网连接随着更多用户同时提出要求而降低速度一样，磁盘上交换内存的分页可能会启动并降低性能。但与互联网连接不同，交换内存是有限制的，如果所有应用程序确实尝试同时使用内存，以至于超出了该限制，那么一些应用程序将开始收到报告内存耗尽的信号/中断/陷阱。总而言之，启用这种内存过量使用行为后，仅仅检查malloc()/new返回非空指针不足以确保物理内存确实可用，并且程序在尝试使用内存时仍可能会收到信号。