查看进程占用内存

1 top -p $pid

2 pmap -x $pid

3 cat /proc/$pid/statm   以页为单位。 所有的页数，物理内存大小 共享页 虚存 数据段+用户栈 脏页

4 cat /proc/$pid/maps

 

如何区分各个内存的段：代码段，数据段，堆段，栈段

主要是根据权限来区分，

代码段的权限，只读，可执行，例如：

2a95575000-2a9557f000 r-xp 00000000 fd:00 38699038                       /lib64/libnss_files-2.3.4.so

数据段的权限是：可读，可写，不可执行，例如：

2a95556000-2a95557000 rw-p 2a95556000 00:00 0

堆段由程序自有分配，不对应文件，在地址上是向上增长，例如：

005b5000-005ba000 rwxp 005b5000 00:00 0

栈，位于虚拟内存的顶端，地址向下增长，例如：

7fbfffa000-7fc0000000 rw-p 7fbfffa000 00:00 0

 

 

 

 

进程向系统申请/释放内存的过程【猜测？】

申请：

1 进程调用new之类的操作

2 new内部可能是检查已分配的内存是否够，够就直接返回； 不够就向os申请

 

释放：

1 进程调用delete

2 delete内部只是将该内存并入进程的空闲列表中， 不是直接返回给os

 

进程会选择合适时机（退出时？）才最终返回给os。

 

=======stl的容器（使用默认的allocator， allocator其实是容器vector的基类； hash+map使用allocator作为hashtable的成员； hashtable是hash_map的成员）， 容器对象释放后按理说所有内存都delete了， 但有时候还是可以看到进程占用的内存空间并没有减少， 就是因为如上原因？

=====http://blog.163.com/dengminwen@126/blog/static/870226720097189486788/

上述链接佐证了我的猜测。

stl的对象出料生命周期或者被delete时， 内存肯定是被delete掉了； 但至于是否还给了os， 则需要看delelte的具体实现。 如果容器对象本身都已经不存在了， 内存还没有降下来， 不是因为stl的allocator缓存的原因。 redhat4.1.2 上的allocator实际上就是简单的封装了new/delete， 没有任何缓存机制。 详见 /usr/include/c++/4.1.2/ 可以找到默认的allocator的真正实现。

 

上面隐含了一个意思， allocator是和容器相依的； 同种类型、不同的两个容器， 其allocator是完全无关的：

当使用了带缓存的allocator时cache_allocator时，

vector<int, ,,cache_allocator<> > vi1;

vector<int, ,,cache_allocator<> > vi2;

这两个容器有各自的缓存。。 两个缓存完全无关。

很好理解。 如果两个缓存是相关的、甚至是同一个， 那么多线程测试程序中， 两个线程各操纵一个私有的vector， 就会存在竞态条件。 而从直观上理解， 这种情况下是不应该有静态条件的