1
為了實現乙個高併發的分布式web大資料查詢引擎，需要避免在程式設計時頻繁的執行malloc和free時所引起的巨大開銷，我們調研了linux核心中的記憶體管理演算法（buddy系統和slab分配器）以及glibc malloc的實現中對於堆的管理。以下記為演算法1和2.
演算法1 和 演算法2 執行的的層面不一樣，初步理解演算法1管理的記憶體是ram的部分記憶體。演算法2管理的是使用者的程序位址空間裡的推段。（需要使用兩個不同的記憶體管理演算法的原因是不同層面的記憶體管理需求不一樣）
接下來將分別介紹對這兩個演算法的理解。
演算法介紹
演算法1linux將ram提供的動態記憶體區域分為三個不同的記憶體管理區，每個記憶體管理區都有各自的buddy系統和slab分配器。圖一介紹了這三個記憶體管理區以及各自演算法執行的位置[1]
buddy系統
buddy系統可以為程序缺頁時（核心態或者使用者態）分配一組頁框，當然，核心可以不通過缺頁異常從buddy系統申請記憶體（一組頁框）。buddy系統的乙個優勢就是避免了外部碎片，即不會出現大量的未使用的不連續的小頁框（比如乙個頁框或者兩個頁框）。
方法即是將記憶體分為不同大小的2的冪次的連續頁框（1，2，4，8，16，32，64，128，256，512，1024）的集合（通過鍊錶的形式組織）。分配的時候從最合適的頁框集合中取，如果有，則返回。如果沒有，則從上一級的頁框中查詢並且切分成兩個當前頁框大小的頁框放入當前集合中，並分配乙個給呼叫者即可。釋放的時候逆向**，即當有連續的同一大小的頁框則合併並放到上一級的集合中，此過程是遞迴過程，直到最大的集合。
slab分配器
從buddy系統的介紹可以看出buddy系統對處理小於乙個頁框的記憶體請求時，會分配一整個頁框，會造成頁內碎片。ulp中介紹slab分配器是執行在cpu快取記憶體中演算法，事實在slab分配器執行在記憶體管理分配器或者buddy系統中都是可以的。將slab分配器執行在cpu快取記憶體中有多個原因，其中乙個是考慮到對夥伴系統函式的呼叫會弄髒快取記憶體中的頁框（快取記憶體中儲存著對buddy系統申請的頁框 ？？）。
這裡沒有找到ulp第三版p325的圖，用了ibm介紹slab的一張圖。原理是一樣的。
slab分配器是一組slab的集合，包含一些特殊的結構體大小的記憶體物件（比如程序結構task_struct之類的）和一些一般大小的記憶體物件（按大小劃分的，32bytes，64bytes，之類）。
slab分配器是構建在cpu快取記憶體上。
有空了繼續總結。
OC 簡單的記憶體管理方法
1.alloc new 或copy 來建立乙個物件，那麼你必須呼叫release 或autorelease 換句話說，不是你建立的，就不用你去釋放。誰建立誰釋放，物件所有權負責釋放 2.如果你在乙個class 的某個方法中alloc 乙個成員物件，且沒有呼叫autorelease或及時releaas...
uC OS II系統中的記憶體管理方法
uc os ii的記憶體管理由自定義的分割槽 陣列 來完成，根據需要進行初始化 建立 獲得 釋放 注意它只是做管理，並沒有提供真實使用的位址，使用的位址是通過osmemcreate由外部提供的。而了解這種機制，在我們平時的程式開發有多記憶體的應用場合，可是採用這種思想進行裝置。1 記憶體的初始化 之...
專案管理方法
ibm的專案管理方法與pmbok的比較 ibm的專案管理方法wwpmm由四個有機部分組成 專案管理領域 pm domain 專案管理工作產品 working product 專案管理工作模式 working pattern 專案管理系統 pm system 其中專案管理領域 pm domain 可以...