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， 就會存在競態條件。 而從直觀上理解， 這種情況下是不應該有靜態條件的

總結

以上是生活随笔為你收集整理的查看进程占用内存的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。