16

Linux glibc 分配器的行为似乎很奇怪。希望有人可以对此有所了解。这是我拥有的源文件：

第一个.cpp：

#include <unistd.h>
#include <stdlib.h>
#include <list>
#include <vector>

int main() {

  std::list<char*> ptrs;
  for(size_t i = 0; i < 50000; ++i) {
    ptrs.push_back( new char[1024] );
  }
  for(size_t i = 0; i < 50000; ++i) {
    delete[] ptrs.back();
    ptrs.pop_back();
  }

  ptrs.clear();

  sleep(100);

  return 0;
}

第二个.cpp：

#include <unistd.h>
#include <stdlib.h>
#include <list>

int main() {

  char** ptrs = new char*[50000];
  for(size_t i = 0; i < 50000; ++i) {
    ptrs[i] = new char[1024];
  }
  for(size_t i = 0; i < 50000; ++i) {
    delete[] ptrs[i];
  }
  delete[] ptrs;

  sleep(100);

  return 0;
}

我同时编译：

$ g++ -o first first.cpp
$ g++ -o 秒 second.cpp

我先运行，在它休眠后，我看到常驻内存大小：

当我编译 first.cpp 并运行它时，我用 ps 查看内存：

$ ./first&
$ ps aux | grep first
davidw    9393  1.3  0.3  64344 53016 pts/4    S    23:37   0:00 ./first


$ ./second&
$ ps aux | grep second
davidw    9404  1.0  0.0  12068  1024 pts/4    S    23:38   0:00 ./second

注意常驻内存大小。首先，常驻内存大小为 53016k。其次是1024k。首先从未出于某种原因将分配释放回内核。

为什么第一个程序不将内存释放给内核，而第二个程序却可以呢？我知道第一个程序使用链表，链表可能会在同一页面上分配一些节点作为我们正在释放的数据。但是，这些节点应该被释放，因为我们要弹出这些节点，然后清除链表。如果你通过 valgrind 运行这些程序中的任何一个，它就不会出现内存泄漏。可能发生的情况是内存在 first.cpp 中变得碎片化，而在 second.cpp 中没有。但是，如果一个页面上的所有内存都被释放，那么该页面如何不被释放回内核呢？将内存交还给内核需要什么？如何修改 first.cpp（继续将 char* 放在列表中）以便将内存让给内核。

4

4 回答 4

17

这种行为是有意的，glibc 使用一个可调阈值来决定是否将内存实际返回给系统，或者是否缓存它以供以后重用。在您的第一个程序中，您每次都进行大量小分配，push_back这些小分配不是连续的块，并且可能低于阈值，因此不要返回操作系统。

清除列表后调用malloc_trim(0)应该会导致 glibc 立即将最顶部的可用内存区域返回给系统（sbrk下次需要内存时需要系统调用。）

如果您确实需要覆盖默认行为（除非分析显示它确实有帮助，否则我不建议这样做），那么您可能应该使用 strace 和/或尝试 mallinfo查看程序中实际发生的情况，并可能mallopt用于调整阈值用于将内存返回给系统。

于 2012-06-08T08:42:58.607 回答
5

如果您再次请求它们，它会保留较小的块可用。这是一个简单的缓存优化，而不是需要关注的行为。

于 2012-06-08T07:53:54.250 回答
3

通常，分配的内存new只会在进程终止时返回给系统。在第二种情况下，我怀疑这libc是对非常大的连续块使用特殊分配器，它确实返回它，但如果你的任何一个new char[1024]被返回，我会感到非常惊讶，而且在许多 Unices 上，即使是大块也不会被退回。

于 2012-06-08T07:52:51.193 回答
2

（编辑我的答案，因为这里真的没有任何问题。）

如前所述，这里没有真正的问题。Johnathon Wakely 一针见血。

当内存利用率不是我在 Linux 上的预期时，我通常使用该mtrace工具开始分析，并分析/proc/self/maps文件。

mtrace通过将代码括在两个调用中来使用，一个用于启动跟踪，一个用于结束它。

  mtrace();
  {
      // do stuff
  }
  muntrace();

只有设置了环境变量，mtrace调用才有效。MALLOC_TRACE它指定 mtrace 日志记录输出的文件名。然后可以分析此日志记录输出是否存在内存泄漏。调用的命令行程序mtrace可用于分析输出。

$ MALLOC_TRACE=mtrace.log ./a.out
$ mtrace ./a.out mtrace.log

该/proc/self/maps文件提供了当前程序正在使用的内存映射区域的列表，包括匿名区域。它可以帮助识别特别大的区域，然后需要额外的侦查来确定该区域与什么相关联。下面是一个将/proc/self/maps文件转储到另一个文件的简单程序。

void dump_maps (const char *outfilename) {
  std::ifstream inmaps("/proc/self/maps");
  std::ofstream outf(outfilename, std::ios::out|std::ios::trunc);
  outf << inmaps.rdbuf();
}
于 2012-06-08T08:50:34.313 回答