在象通訊系統中的基站這樣的複雜嵌入式系統中，對於內存管理模塊的效率具有很高的要求，因此內存管理模塊的算法很有講究。講究在於，不僅要考慮算法的效率，還要兼顧算法是否會帶來大量的內存碎片以及如何進行內存碎片合併。正因如此，這類嵌入式系統軟件大多會對內存管理模塊根據業務特點進行適當的優化。
優化的方式無外乎引入內存池，或對堆管理模塊引入新的算法加以優化，然而這些方法除了引入了一定的算法複雜度外，仍存在不小的改善空間。藉此，作者想提出一種面向業務流的內存管理算法與大家共同探討。
爲了討論的方便性，我們假設某虛擬系統存在如下的業務流順序圖。圖中的三個模塊只是代表性的，它們即可以指以消息爲通訊手段的三個任務，也可以指存在函數調用關係的三個模塊。圖中的紅色消息表示存在處理的過程中需進行內存分配的操作，並假設所分配出來的內存在消息的後續處理中需要用到。比如，處理MsgA時所分配的內存可能需要被ModuleB和ModuleC使用，且該內存在處理完MsgA後需要釋放。值得一提的是，這個虛擬系統存在大量的併發業務流需要處理（這好比機站中存在多個電話呼叫信令需要同時處理）。
對於這樣的業務流，最爲傳統的內存使用方法是分別在處理MsgA和MsgB時調用內存分配函數獲取內存，並將所獲得的內存指針通過消息攜帶的方式傳遞給後續模塊處理。當系統複雜（一個消息的後續處理模塊數非常多），且所分配的內存在大小上存在不小差別時，分配和釋放內存的效率及內存碎片問題或成爲系統的瓶頸，加之內存的分配與釋放功能是分散在不同的模塊中的，因而容易產生內存泄漏。
現在讓我們跳出這種使用內存的傳統思維，站在業務流的角度重新審視內存的使用方法。不難發現，對於一個業務流，處理MsgA和MsgB所分配的內存儘管存在分配時機上的區別，但它們都共同服務於同一業務流。既然如此，我們爲何不將內存的分配與釋放時機放在業務流的開始與結束處呢？比如，在處理MsgA時將MsgB所需的內存也分配好，所有分配的內存也可以在業務流結束後共同釋放。採用這種方式需要解決一個問題，既在處理MsgA時需要知道處理MsgB時所需分配內存的大小。顯然，不能簡單地將處理MsgB的部分功能挪到處理MsgA的功能塊中，因爲這可能會破壞程序結構。簡易的解決方法可以通過犧牲一定的內存獲得 — 通過分析業務流，我們可以知道處理某消息所需分配內存的最大值，進而用那個最大值作爲在處理MsgA時所需提前分配的數量。（注：如果內存的大小存在很大的差異，作者建議結合採用傳統方法，而非完全採用後面將要談到的方法）
至此，我們邁出了很重要的一種思路轉變，爲了獲得方便的實現方法我們仍需更進一步。如果一個業務流中各處所需分配的內存大小能預先以取最大值的方式確定下來加以規劃，我們就可以通過一定的數據結構來表達，如下圖所示。
- #define MAX_SIZE_FOR_MSGA 32
- #define MAX_SIZE_FOR_MSGB 128
- typedef struct
- {
- char forMsgA [MAX_SIZE_FOR_MSGA];
- char forMsgB [MAX_SIZE_FOR_MSGB];
- } business_flow_memory_t;
- #define CONFIG_MAX_BUSINESS_FLOW_SUPPORTED 900
- business_flow_memory_t g_memory_pool [CONFIG_MAX_BUSINESS_FLOW_SUPPORTED];
相信圖中的前部分代碼很是直截了當，後部分代碼則假設系統最多同時支持900個業務流需要處理。當一個新的業務流需要處理時（在這裏的例子中，處理MsgA時），直接從g_business_memory_pool數組中獲取一個元素，以作處理整個業務流所需的全部內存（可以設想，這一內存會在業務流的不同處理階段被使用）；當結束一個業務流時（在這裏的例子中，處理完MsgA後），則可以通過一次性地釋放該元素從而完成內存釋放。顯然，數組元素的獲取與釋放需要爲這提供相應的函數，且對元素的管理可以考慮引入鏈表等方法以提高管理效率。這部分內容我們在此不展開。
致此相信讀者已瞭解面向業務流內存管理算法的機理了。作爲結束，我們應總結一下這一算法的優缺點。優點有：一，分配與釋放非常高效，且不會隨着系統的運行而產生任何內存碎片；二，很容易杜絕內存泄漏。缺點有：一，由於每處使用的內存需以最大值進行規劃，存在一定的內存浪費；二，當以內存所需最大值進行規劃存在嚴重的內存浪費時，該算法存在適用性問題。再囉嗦一下，如有適用性問題時，請運用傳統使用內存的方法（調用malloc/free）與這裏所主張的方法相結合加以解決。
本文出自李雲的博客，請務必保留此出處：http://blog.csdn.net/hzliyun/article/details/7816266。
