對Linux堆內(nèi)存釋放的總結(jié)

snow_insky

今天上午得到了該版的一些高手指點，終于弄懂了堆內(nèi)存釋放的奧秘，特總結(jié)出來與大家分享！


Linux用戶進程是如何釋放內(nèi)存的
Linux進程使用內(nèi)存的基本流程：

C:\Documents and Settings\eric\My Documents\Linux用戶進程是如何使用內(nèi)存的.doc
從圖中我們可以看出，進程的堆，并不是直接建立在Linux的內(nèi)核的內(nèi)存分配策略上的，而是建立在glibc的堆管理策略上的（也就是glibc的動態(tài)內(nèi)存分配策略上），堆的管理是由glibc進行的。
所以我們調(diào)用free對malloc得到的內(nèi)存進行釋放的時候，并不是直接釋放給操作系統(tǒng)，而是還給了glibc的堆管理實體，而glibc會在把實際的物理內(nèi)存歸還給系統(tǒng)的策略上做一些優(yōu)化，以便優(yōu)化用戶任務(wù)的動態(tài)內(nèi)存分配過程。

那么glibc的堆管理器在什么時候才把物理內(nèi)存歸還給系統(tǒng)呢？
它會從堆的最大線性地址開始，從后向前計算用戶任務(wù)當前有多少空閑的堆內(nèi)存（直到碰到使用中的堆內(nèi)存地址為止），比如在該圖中，
它會認為有2048k的可釋放內(nèi)存，只有在該值大于某個特定的threshhold時（2.3.6上為64k），它才會把這些內(nèi)存歸還給系統(tǒng)。而在中間的“未使用”內(nèi)存是不會歸還給系統(tǒng)的，所以系統(tǒng)也不可能再利用這塊物理內(nèi)存頁（我們假設(shè)系統(tǒng)沒有swap區(qū)和swap文件），也就是說系統(tǒng)的內(nèi)存會為此減少，除非在它之前的堆內(nèi)存都用free進行釋放以后，glibc的堆管理器才有可能（只是有可能）把該段內(nèi)存歸還給系統(tǒng)。

由此，我們在使用malloc/free時應(yīng)該小心，特別是在初始化時分配了好多內(nèi)存，但是在這之后卻再也不需要這么多的內(nèi)存了，而這塊內(nèi)存又沒有達到threshhold值或者在堆的最高線性地址處有某塊內(nèi)存沒有釋放，但是它前面的所有堆內(nèi)存都釋放了；這種情況下，用戶任務(wù)將會浪費一些物理內(nèi)存，這在資源比較緊張的嵌入式系統(tǒng)中是不可容忍的。


謝謝！

snow_insky

Linux用戶進程是如何釋放內(nèi)存的
Linux進程使用內(nèi)存的基本流程：
    見圖1
從圖中我們可以看出，進程的堆，并不是直接建立在Linux的內(nèi)核的內(nèi)存分配策略上的，而是建立在glibc的堆管理策略上的（也就是glibc的動態(tài)內(nèi)存分配策略上），堆的管理是由glibc進行的。
所以我們調(diào)用free對malloc得到的內(nèi)存進行釋放的時候，并不是直接釋放給操作系統(tǒng)，而是還給了glibc的堆管理實體，而glibc會在把實際的物理內(nèi)存歸還給系統(tǒng)的策略上做一些優(yōu)化，以便優(yōu)化用戶任務(wù)的動態(tài)內(nèi)存分配過程。

那么glibc的堆管理器在什么時候才把物理內(nèi)存歸還給系統(tǒng)呢？
它會從堆的最大線性地址開始，從后向前計算用戶任務(wù)當前有多少空閑的堆內(nèi)存（直到碰到使用中的堆內(nèi)存地址為止），比如在該圖中，
    見圖2
它會認為有2048k的可釋放內(nèi)存，只有在該值大于某個特定的threshhold時（2.3.6上為64k），它才會把這些內(nèi)存歸還給系統(tǒng)。而在中間的“未使用”內(nèi)存是不會歸還給系統(tǒng)的，所以系統(tǒng)也不可能再利用這塊物理內(nèi)存頁（我們假設(shè)系統(tǒng)沒有swap區(qū)和swap文件），也就是說系統(tǒng)的內(nèi)存會為此減少，除非在它之前的堆內(nèi)存都用free進行釋放以后，glibc的堆管理器才有可能（只是有可能）把該段內(nèi)存歸還給系統(tǒng)。

由此，我們在使用malloc/free時應(yīng)該小心，特別是在初始化時分配了好多內(nèi)存，但是在這之后卻再也不需要這么多的內(nèi)存了，而這塊內(nèi)存又沒有達到threshhold值或者在堆的最高線性地址處有某塊內(nèi)存沒有釋放，但是它前面的所有堆內(nèi)存都釋放了；這種情況下，用戶任務(wù)將會浪費一些物理內(nèi)存，這在資源比較緊張的嵌入式系統(tǒng)中是不可容忍的。


謝謝！

yjh777

原來是這樣! 謝謝,謝謝!

soi

前幾天都在商量malloc的內(nèi)存碎片問題，原來是這樣的
up

dustman

1，通過malloc申請的內(nèi)存并不一定代表實際已經(jīng)得到的物理內(nèi)存，而只是改變了用戶空間heap空間的大小。
2，通過free釋放的內(nèi)存并不一定馬上歸還給系統(tǒng)，必須是用戶heap空間內(nèi)連續(xù)空閑內(nèi)存數(shù)據(jù)超出一個閾值時才將這片內(nèi)存歸還給內(nèi)核。
3，如果在用戶空間內(nèi)空閑內(nèi)存區(qū)存在并未達到釋放閾值的內(nèi)存塊，并且后續(xù)不再申請內(nèi)存，那么該塊內(nèi)存就將被用戶進程“霸占”。

是這樣理解嗎？

snow_insky

目前的Linux堆內(nèi)存管理是用的ptmalloc的管理方案，在該實現(xiàn)中有個叫做fastbin的東西，好像是用來對分配的內(nèi)存進行按size分類，比如你分配了一個8byte的內(nèi)存，在釋放的時候如果不能和別人合并，則會緩存起來，鏈到一個8bytes鏈中，下次再分配相同大小的內(nèi)存時，glibc會直接看，在該鏈中是否有項，如果有，則直接在該鏈表中摘取一項，返回該項給進程。分配結(jié)束�。。�！

所以glibc的堆管理器已經(jīng)做了小內(nèi)存分配的優(yōu)化動作，我們可以不做了，不過，如果對我們自己的應(yīng)用有特定需求，則我們也可以再在glibc上包裝一層，對小尺寸的內(nèi)存分配做優(yōu)化！！

snow_insky

原帖由 dustman 于 2005-12-28 12:44 發(fā)表
1，通過malloc申請的內(nèi)存并不一定代表實際已經(jīng)得到的物理內(nèi)存，而只是改變了用戶空間heap空間的大小。
2，通過free釋放的內(nèi)存并不一定馬上歸還給系統(tǒng)，必須是用戶heap空間內(nèi)連續(xù)空閑內(nèi)存數(shù)據(jù)超出一個閾值時才將這 ...

1，3的理解是正確的，但是2可能有點出入，應(yīng)該是這樣的：

不是heap空間中有連續(xù)的空閑內(nèi)存數(shù)據(jù)超過一個閥值時才歸還給系統(tǒng)，而是從最后向前測量，直到一個在用的空間為止，如果這段沒用的空間總量超過了閥值，則把這段內(nèi)存歸還給系統(tǒng)。

因為系統(tǒng)調(diào)用sbrk和brk僅僅只能做的事情是，移動堆的最大線性地址（top memory），它并不能處理中間的空閑空間

dustman

謝了

收藏

snow_insky

如題，以及在哪里做堆棧的限制

zhhhuang

好東西！