Gnome资源监视器报告的C ++程序中的内存使用情况:混乱

我看着我的应用程序消耗的内存,以确保我没有分配太多,并且对Gnome Resource Monitor向我展示的内容感到困惑。 我已经使用下面的代码片段分配两个单独的应用程序,否则相同的内存; 他们除了这个代码和一个scanf()调用暂停执行,而我抓住内存使用情况:

malloc(1024 * 1024 * 100); 

 char* p = new char[1204*1024*100]; 

下图显示了每个这些行之前和之后的应用程序的内存使用情况:

内存使用

现在,我已经读了很多(但显然不够)关于内存使用情况(包括这个问题),并且在区分可写内存和虚拟内存时遇到了困难。 根据相关问题,

“可写内存是您的进程使用写权限分配的地址空间量”

“虚拟内存是您的应用程序分配的地址空间”

1)如果我自己分配内存,当然它有写权限?

2)链接的问题也说明(关于malloc)

“…实际上不会分配任何内存(详情请参阅malloc(3)页末尾的提示)

我没有看到任何“咆哮”,我的图像显示虚拟内存增加了! 有人可以解释这个吗?

3)如果我纯粹以下代码:

 char* p = new char[100]; 

资源监视器显示内存和可写内存都增加了8KB – 就像我分配一个完整的一兆字节一样! – 虚拟内存增加0.1。 这里发生了什么?

4)我应该在资源监视器中查看哪些列,以查看我的应用使用了多less内存?

非常感谢您的参与,如果不清楚或遗漏了任何可能导致我自己find答案的事情,我深表歉意。

Gnome资源监视器报告的内存类(实际上是绝大多数的资源报告工具)不是简单的单独的内存类 – 它们之间有重叠,因为它们报告内存的不同特性。 其中一些不同的特征包括:

  • 虚拟与物理 – 现代操作系统上的进程地址空间中的所有内存都是虚拟的; 该虚拟地址空间通过CPU的硬件能力被映射到实际的物理存储器; 映射如何完成本身就是一个复杂的话题,不同架构之间有很多不同之处
  • 内存访问权限 – 内存可以是可读的,可写的,可执行的,也可以是三者的任意组合(理论上 – 某些组合没有意义,因此硬件和/或软件实际上可能不允许)这些权限被分开处理)
  • 驻留与非驻留 – 使用虚拟内存系统,进程的大部分地址空间可能实际上并不会真正映射到真实的物理内存,原因有很多 – 可能尚未分配; 它可能是二进制文件或其中一个库的一部分,甚至可能是尚未加载的数据段,因为程序还没有调用它; 它可能已经被交换到交换区域,为需要它的不同程序释放物理内存
  • 进程虚拟地址空间的共享与私有部分是只读的(例如,程序和大多数库的实际代码)可以与使用相同库或程序的其他进程共享 – 这是一个很大的因为有37个不同的xterm实例运行并不意味着xterm的代码需要被加载到内存的不同时间 – 所有进程可以共享代码的一个副本

由于这些以及其他一些因素(IPC共享内存,内存映射文件,具有映射到硬件中的内存区域的物理设备等),确定任何单个进程甚至整个系统使用的实际内存,可以是复杂的。

在Linux上理解正在运行的进程的内存使用情况的更准确的方法是使用proc(5)文件系统。

所以,如果你的进程pid是1234,那么试试吧

 cat /proc/1234/maps 

请注意,进程在虚拟内存中具有其地址空间 。 该地址空间可以通过mmap(2)和其他系统调用(2)来改变。 由于malloc(3)的多个效率原因,并且free使得这些系统调用过多,而且更愿意重新使用以前的free内存区域。 所以当你的程序free一些内存块(或者在C ++中delete )的时候,这个块经常被标记为可重用,但是不会被释放回内核(例如munmap )。 同样,如果你的malloc只有100个字节,你的libc被允许例如使用mmap请求整个兆字节(下一次你调用malloc例如200字节时,它将使用该字节的一部分)

另请参阅http://linuxatemyram.com/和高级Linux编程 (以及有关内存过量使用的问题 )