容器化 Linux 环境中的 C++：为什么尝试分配大向量会导致 SIGABRT 或永无休止的循环而不是 bad_alloc？

Question

我在 Windows 机器上的三种环境中用 C++ 编写：

1. 带有 Ubuntu - g++ 编译器的 Docker Linux 容器 (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
2. Windows 上的 WSL Ubuntu 环境 - g++ 编译器 (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
3. Windows - gcc 编译器（i686-posix-dwarf-rev0，由 MinGW-W64 项目构建）8.1.0

我正在处理巨大的数据集，基本上需要能够将它们分解成尽可能大的块以便在内存中进行操作。为了找到块的大小，我想象了如下所示：

size_t findOptimalSize(long long beginningSize) {
    long long currentSize = beginningSize;
    while (currentSize > 0) {
      try {
        std::vector<double> v(currentSize);
        return currentSize;
      } catch (std::bad_alloc &ex) {
        currentSize /= 10;
      }
    }
    return 0;
  }

int main() {
  long long size(50000000000000);
  try {
    std::vector<double> v(size);
    std::cout << "success" << std::endl;
  } catch (std::bad_alloc &ex){
    std::cout << "badAlloc" << std::endl;
  }
  size_t optimal = findOptimalSize(size);
  std::cout << "optimal size: " + std::to_string(optimal);
  return 0;
}

上面的代码在 Windows 环境中的表现完全符合预期。然而，在这两个 Linux 环境中，虽然它总是能够抛出第一个 bad_alloc 异常，但它会执行以下两种操作之一：

1. 引发 SIGABRT 并显示以下消息：

new 无法满足内存请求。这并不一定意味着您已经用完虚拟内存。这可能是由于错误使用指针或过时的共享库引起的堆栈冲突

2. 经过几次迭代后，似乎陷入了无限循环std::vector<double> v(currentSize);（我最好的猜测是，它接近 Linux 环境可用的内存量，并且它陷入等待额外的一点点额外内存的情况）释放以满足我的要求）

有什么方法可以完成我正在尝试的任务并在 Linux 环境中避免这些问题吗？我猜测容器使事情变得复杂，并用它们复杂的内存管理逻辑混淆了我的简单分配检查。

在这种情况下如何检查是否可以分配内存？

Answer 1

容器没有复杂的内存管理逻辑。您所看到的是一个令人惊讶的 Linux 策略（称为内存过量使用）的结果。

在 Linux 中，大量分配不会失败；malloc()总是成功的。在您实际尝试使用内存之前，内存并未实际分配。如果操作系统无法满足需求，它会调用OOM Killer来终止进程，直到释放足够的内存。

为什么会有这个存在？

Linux 计算机通常有许多异构进程在其生命周期的不同阶段运行。从统计上看，在任何时间点，它们都不需要为它们已分配的每个虚拟页面（或稍后在程序运行中分配）共同需要映射。

严格的非过度使用方案将在分配虚拟页时创建从虚拟地址页到物理 RAM 页帧的静态映射。这将导致系统可以同时运行的程序少得多，因为大量的 RAM 页框将被毫无用途地保留。

（来源）

你可能会觉得这很荒谬。你不会孤单。这是一个极具争议性的系统。如果您的第一反应是“这太愚蠢了”，我鼓励您仔细阅读并暂时搁置判断。最终，无论您是否喜欢过度使用，这都是所有 Linux 开发人员都必须接受和应对的现实。