【问题标题】:STL not release memory from System levelSTL 不从系统级别释放内存
【发布时间】:2019-05-12 11:46:52
【问题描述】:

据我所知,STL 具有自动内存管理功能。但是当我使用topps -aux之类的东西来显示进程的内存使用情况时,它表明即使STL对象超出范围,这些内存仍然被进程拥有。

这是一个例子:

void run()
{
    map<int, int> a;
    for(int i = 0; i < 1000000; i++)
    { 
        a[i] =  i;
    } // 64376K memory used by process
}

int main()
{
    run();
    sleep(5); // still 64376 memory used
    map<int, int> a;
    for(int i = 0; i < 1000000; i++)
    { 
        a[i] =  i;
    } // still 64376 memory used
    return 0;
}

进程在run() 中拥有64376KB 内存,并且在函数run() 之后内存没有释放。但是这些内存好像被第二个map占用了。

我使用valgrind --tool=massif查看发生了什么后,得到了正常的结果。

所以我的问题来了

  1. 为什么进程内存趋势与代码和valgrind不匹配
  2. 不同的 STL 对象如何共享相同的分配内存。

【问题讨论】:

标签: c++ memory stl


【解决方案1】:

这是完全正常的。这就是操作系统的工作方式。如果他们把所有的时间都花在从微小的进程中回收一小部分内存上,他们就不会做任何其他事情了。

您只需要相信他们复杂的算法知道他们在做什么来为您的系统获得最佳性能。

在逻辑层上层层叠叠,将物理 RAM 一直分配到进程的虚拟内存。

深入了解操作系统的工作原理超出了本文的范围,而且毫无意义。但是,如果您真的想了解这一切,您可以报名参加相关的教学课程。

如果我们忘记缓存和虚拟内存等,即使是简单的经验法则也可以总结如下:从程序中释放内存告诉操作系统它可以取回;这并不意味着操作系统必须收回它。

【讨论】:

  • 那么有没有一种有效的方法来监控进程的真实内存使用情况,除了valgrind,它可能太慢了?
  • @LTzycLT 基本上。我通常不会打扰,除了偶尔会大致了解一下我的内存消耗,但在长期测试期间密切关注整体内存消耗,以便及早发现任何严重的内存泄漏。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2016-08-05
  • 1970-01-01
  • 1970-01-01
  • 2019-04-17
  • 2019-11-02
相关资源
最近更新 更多