解決UDT中記憶體下不去的問題

2021-07-15 05:42:53 字數 856 閱讀 6541

使用udt庫,編寫簡單的網路通訊程式,發現了乙個問題,關閉一部分連線後,程式占用記憶體並沒有變化。

比如先連線500個,再連線另500個,先關掉後面500個,程式占用記憶體降一半,再關掉500個,程式占用記憶體降到0.1。然而,如果先關掉前面500個,程式占用記憶體不會發生變化,只有等再關掉後面500個,程式記憶體才會降到0.1。

換個順序就降不了,這很奇怪,很「玄學」。

跟蹤**至底層,該有的釋放都有,這是為什麼?靈機一動想到可能與linux記憶體管理機制有關,果不其然,linux中給程式分配堆記憶體後,當程式free,記憶體並不會馬上還給系統,而是交由ptmalloc管轄,這樣程式再需要記憶體的時候,就可以直接向ptmalloc取,不用再向系統申請,效率較高。ptmalloc也不是說就不把記憶體還給系統了,返回記憶體的機制叫「記憶體收縮」,當堆頂的空閒記憶體大於收縮閾值(預設是128kb)時,即可觸發。注意,這邊要求的空閒記憶體必須位於堆頂,所以如果堆頂的記憶體不釋放,堆底的記憶體再怎麼釋放都觸發不了記憶體收縮,這就導致了那個玄學的結果。

因此,在**裡新增這麼一句mallopt(m_mmap_threshold, 128);,m_mmap_threshold是mmap分配閾值,當程式所要記憶體大於m_mmap_threshold時,直接呼叫mmap()分配記憶體,free的時候,會直接呼叫munmap()將記憶體還給作業系統,不再被ptmalloc快取管理。所以連線關閉後,記憶體就能下去了。

這樣做的缺點是需要的記憶體更多,需要的記憶體數量隨m_mmap_threshold數值的減少而增多,所以需要選個合適的數字。且這些記憶體不再重用,分配效率也會比較低。

然而,對於分配長生命週期的大記憶體塊,使用mmap()才是最高效的,ptmalloc並不擅長管理長生命週期的記憶體,尤其是持續不定期分配和釋放長生命週期的記憶體,這會導致記憶體暴增。

解決UDT中記憶體下不去的問題

使用udt庫,編寫簡單的網路通訊程式,發現了乙個問題,關閉一部分連線後,程式占用記憶體並沒有變化。比如先連線500個,再連線另500個,先關掉後面500個,程式占用記憶體降一半,再關掉500個,程式占用記憶體降到0.1。然而,如果先關掉前面500個,程式占用記憶體不會發生變化,只有等再關掉後面500...

iOS中濾鏡處理及相關記憶體洩漏問題的解決

最近工作之餘在做乙個美圖秀秀的仿品 做到濾鏡這塊的時候 自己就參考了網上幾位博主 名字忘了記,非常抱歉 的部落格,但是發現跟著他們的demo做的濾鏡處理,都會有很嚴重的記憶體洩漏,於是就自己按照大體的思路將 重新整理了下,並解決了記憶體洩漏問題。大體思路如下 根據建立乙個coregraphic的圖形...

C 中動態記憶體分配引發問題的解決方案

假設我們要開發乙個string類,它可以方便地處理字串資料。我們可以在類中宣告乙個陣列,考慮到有時候字串極長,我們可以把陣列大小設為200,但一般的情況下又不需要這麼多的空間,這樣是浪費了記憶體。對了,我們可以使用new操作符,這樣是十分靈活的,但在類中就會出現許多意想不到的問題,本文就是針對這一現...