1樓：黃逸塵
記憶體池在嵌入式開發也有應用。
之前做過的多功能一體機就是在開發之初就定下各個子系統可以使用的記憶體配額，並在啟動時統一進行分配和初始化。之後各個子系統再自行分配。
優點不在於效能，而是在於可以大大提高系統的穩定性和魯棒性。即使出現記憶體洩漏，也只會影響個別子系統而已，不會造成整機的崩潰。
2樓：littlewolf
我來說個其他問題，在windows下，當32位的程式占用記憶體過大（長期使用的內存在1.2G左右時），且分配頻繁，記憶體碎片化會相當嚴重，最終結果就是你雖然還有可能記憶體，但是已經無法分配出連續的512K以上的記憶體了，這個問題在windows xp和window 7下都存在，win7情況相對好些。
這個時候需要記憶體池，自己進行管理，可以避免記憶體碎片化。
3樓：
雲風貌似不上知乎，那我來引個雲風昨天寫的allocator吧：
github.com/cloudwu/lalloc再援引一句雲風在群裡說的原話，我不知道是不是斷章取義了，僅供參考哈，「不了解分配器怎麼工作的才會去想再寫個記憶體池吧」
4樓：
如果是thread-local的記憶體池，是可以不用加鎖的。
不同生命週期的記憶體塊，分別在相應的記憶體池裡分配，方便釋放，也方便除錯。
到時候整塊記憶體都不要了，而且不需要呼叫析構函式的話，可以一下子整個釋放。
遊戲裡，從場景退到主選單，就可以這麼做。
5樓：
做網路裝置，伺服器端開發和做應用開發的對於這個問題可能感受完全不一樣。
要處理的資料物件不一樣，網路和伺服器開發，大部分的資料並不駐留記憶體。
網路類的資料屬於stream型別的資料，也就是說這個資料對於CPU來說，在很長的時間之內只用一次。
但是應用類的資料，可能要頻繁駐留記憶體，例如遊戲，檔案處理的客戶端，而且會對原資料頻繁增添資料。
當然有人會說HTML的靜態頁面難道不會駐留記憶體嗎？我了我說的只是通常情況。
對於第一種型別的資料，重新構建乙個記憶體池沒有意義。在路由器上動態申請記憶體是乙個非常愚蠢的行為，靜態預先分配往往有更好的效果。
但是對於做應用的人，總會覺得系統原有的東西不夠靈活，無法滿足要做得更好的要求。
「發明」乙個新的記憶體池可能並不是想代替系統自帶的。
比如說QQ，我相信它肯定是自己發明了一套東西去管理資料。
如果它一啟動就靜態申請個256M記憶體，整天被程式設計師冷嘲熱諷的，怎麼玩？
6樓：Xi Yang
效能倒也罷了，現代作業系統自帶的記憶體分配器的效能，不是你自己能夠輕易達到的。其實主要是為了特別的需求。
首先我們不難想到，在自己做的記憶體池裡，你可以監控到一切的記憶體分配事件。所以首先可以玩各種debug、profiling的花樣。
然後，對於特別的操作，還是有可能優化效能的。比如某種物件，在資料處理的時候被頻繁訪問，它的數量又特別大，尺寸又不太大。那麼我們可以單獨開乙個pool，把所有的這種物件盡量連續地放在一起，可以有利於快取命中。
7樓：陳碩
動不動就 32GB 以上記憶體的伺服器真需要關心記憶體碎片問題嗎？
一句話：不要低估了各路 malloc 作者的實力，這些都是大神級的人物：Doug Lea、Ulrich Drepper、Poul-Henning Kamp、Jason Evans、Sanjay Ghemawat。
你說的「減少開銷/更高效」有資料支援嗎？
為硬體保留的記憶體怎麼釋放？
嚴華公升 嘗試過在msconifg裡修改，無效 嘗試在bois裡禁用quike booting，無效在bios裡無意瞄到了usable memory 4088MB，可我裝了8G的記憶體啊。拆機箱，把記憶體全部重插一遍，再進bios檢視，可用記憶體8184MB，進windows檢視為硬體保留的記憶體從...
將java物件記憶體釋放橋接到C 的delete上去，對於GC有什麼影響？
dwing 你的想法其實很多人都想過了,但很少見到在自動管理記憶體的系統中提供手動delete,最關鍵的原因就是這會把一門以記憶體安全當做最主要優勢打破了.只要引入手動delete,那麼所有的記憶體誤用都可能出現,包括 野指標 釋放後繼續訪問 多次delete乙個指標.解決這些問題對JVM來說即使在...
無鎖的執行緒池 和記憶體池 還有無鎖的佇列 的設計思路是什麼呢
很久很久以前研究過無鎖演算法，無鎖演算法主要是基於 cas 操作做文章。cas 操作簡單的說就是把記憶體的值儲存下來，準備回寫的時候比較一下值是否相同，相同就認為沒有其他執行緒動過，如果變了，重新取值重新計算。高效能無鎖 Lock free 記憶體池 我還做了測試 再談高效能無鎖 Lock free...