FreeRTOS 作為一個(gè)嵌入式實(shí)時(shí)操作系統(tǒng)，其運(yùn)行的環(huán)境一般資源有限，特別是其內(nèi)存資源，可能只有幾 M，甚至是幾十 KB。針對(duì)不同的應(yīng)用場(chǎng)景，F(xiàn)reeRTOS 源碼中提供了 5 種內(nèi)存管理方案。本文就來(lái)聊聊這些內(nèi)存管理方案以及相關(guān)的優(yōu)化措施。

內(nèi)存管理相關(guān)的代碼在 lib/FreeRTOS/portable/MemMang 目錄下，從 heap_1.c 到 heap_5.c，文件相互獨(dú)立，并提供統(tǒng)一接口：

void *pvPortMalloc( size_t xWantedSize );
void vPortFree( void *pv );

而 heap 的定義，可以是一塊靜態(tài)分配的數(shù)組作為 heap，也可以是指定的一塊區(qū)域作為 heap，本文就以靜態(tài)數(shù)組為例進(jìn)行講解。

#if( configAPPLICATION_ALLOCATED_HEAP == 1)
extern uint8_t ucHeap[ configTOTAL_HEAP_SIZE ];
#else
static uint8_t ucHeap[ configTOTAL_HEAP_SIZE ];
#endif

實(shí)際上，內(nèi)存釋放接口并不一定都有效，因?yàn)?heap_1 方案是不支持內(nèi)存釋放的。在 heap_1 中調(diào)用 pvPortMalloc() 的時(shí)候，其具體實(shí)現(xiàn)如下所示：

pucAligendHeap: 對(duì)齊后的 heap 起始地址。

xNextFreeByte: 記錄下一次分配內(nèi)存的偏移值，實(shí)際就是已分配內(nèi)存的總大小。

pvReturn = pucAlignedHeap + xNextFreeByte;
xNextFreeByte += xWantedSize;

每次分配的時(shí)候，返回 pucAligendHeap + xNextFreeByte 的地址，然后更新 xNextFreeByte。當(dāng)然了，整個(gè)分配過(guò)程中，還有一些對(duì)齊操作。由于分配后的內(nèi)存不能進(jìn)行釋放，所以這種分配方案適用于不需要頻繁申請(qǐng)釋放內(nèi)存的場(chǎng)景。

相對(duì)于 heap_1 方案，在 heap_2 中增加了內(nèi)存釋放的函數(shù)。其實(shí)現(xiàn)是在每一次分配的內(nèi)存中增加了一些描述信息（也就是多分配一個(gè)結(jié)構(gòu)體大小的內(nèi)存，用于保存描述信息），這樣在釋放的時(shí)候，就可以根據(jù)這些信息回收內(nèi)存。

typedef struct A_BLOCK_LINK {
    struct A_BLOCK_LINK *pxNextFreeBlock;
    size_t xBlockSize;
} BlockLink_t;

static const uint16_t heapSTRUCT_SIZE = (( sizeof( BlockLink_t ) + ( portBYTE_ALIGNMENT - 1 )) & ~portBYTE_ALIGNMENT_MASK );

xWantedSize += heapSTRUCT_SIZE;  /*每次分配的時(shí)候自動(dòng)加上描述結(jié)構(gòu)體的大小*/

描述信息結(jié)構(gòu)體中包含了一個(gè)鏈表指針，用于在釋放的時(shí)候，將該內(nèi)存加入到空閑鏈表中，每次分配內(nèi)存實(shí)際就是從空閑鏈表上進(jìn)行分配（初始狀態(tài)，整個(gè)鏈表除了頭尾，就一個(gè)成員，就是整個(gè)空閑的 heap 塊）。xBlockSize 用于描述分配內(nèi)存的大小。

其中，xStart 和 xEnd 是空閑鏈的頭尾節(jié)點(diǎn)。初始狀態(tài)時(shí)，整個(gè) heap 就是一個(gè)空閑塊。分配的時(shí)候，從頭遍歷空閑鏈，找到第一個(gè)滿足大小的塊，也就是最先匹配原則（first fit），從中分裂出所需的大小，然后將剩余的插入到空閑鏈中。而釋放就是將其插入到空閑鏈中。

需要注意的是，插入空閑鏈中，都是升序排列的，也就是說(shuō)在分配的時(shí)候，最先滿足的塊也是最優(yōu)的塊（best fit），可以減少碎片的產(chǎn)生。從實(shí)現(xiàn)來(lái)看，heap_2 雖然添加了釋放內(nèi)存函數(shù)，但其在插入到空閑鏈的時(shí)候，沒(méi)有對(duì)相鄰的塊進(jìn)行合并，所以 heap_2 適用于操作固定大小內(nèi)存的場(chǎng)景。

heap_3 的方案沒(méi)有基于 heap_2 進(jìn)行優(yōu)化，而是直接使用 libc 庫(kù)中 malloc() / free() 接口，所以這里就不多做介紹。

事實(shí)上，相鄰塊合并功能是在 heap_4 中引入的。在將空閑塊插入到鏈表的時(shí)候，會(huì)判斷是否有空閑塊是相鄰的，如果相鄰就合并成一個(gè)更大的空閑塊，就能減少碎片的產(chǎn)生，進(jìn)而更適用于一般的內(nèi)存分配和釋放場(chǎng)景。注意 heap_4 在插入空閑鏈的時(shí)候，不再是升序排列，而是根據(jù)地址大小進(jìn)行排列，這樣便于判斷量表中前后兩個(gè)塊是否相鄰。

heap_5 相對(duì)于 heap_4 方案并沒(méi)有進(jìn)行算法上的優(yōu)化，它添加了一個(gè)接口可以指定某個(gè)內(nèi)存塊作為 heap。

void vPortDefineHeapRegions( const HeapRegion_t * const pRegions );

在前幾種內(nèi)存管理方案中，除了 heap_3，內(nèi)存塊都是靜態(tài)分配的。而在 heap_5 中 heap 不再是靜態(tài)定義的全局變量，而是需要顯示指定的一塊內(nèi)存區(qū)域作為 heap。這樣的好處就是，heap 的來(lái)源更加靈活，可以是和運(yùn)行空間不連續(xù)的一塊內(nèi)存，也可以將多個(gè)不連續(xù)的內(nèi)存塊作為 heap 進(jìn)行管理。

以上就介紹了 FreeRTOS 中原生的 5 種內(nèi)存管理方案?？梢钥闯?，后面的內(nèi)存管理方案對(duì)前面的管理方案是兼容的，比如 heap_5 可以替代 heap_1, heap_2 和 heap_4 方案。這里可能就有個(gè)疑問(wèn)了，為什么不直接用 heap_5 方案呢？更豐富的功能，意味著復(fù)雜的一些實(shí)現(xiàn)，在一些簡(jiǎn)單的場(chǎng)景中，heap_5 分配速度可能沒(méi)有 heap_1 或者 heap_2 來(lái)得快，所以 heap_1，heap_2 等方案也有其存在的意義。

在實(shí)際場(chǎng)景中，比如隨機(jī)的分配和釋放，而且分配的大小也不一致，這個(gè)時(shí)候，一般會(huì)選擇 heap_4。heap_4 引入了內(nèi)存合并功能，可以減少內(nèi)存碎片，但和 heap_2 相比，也把最優(yōu)匹配的原則去掉了。如下圖所示：

當(dāng)要分配一個(gè) 32Bytes 的內(nèi)存（經(jīng)過(guò)對(duì)齊等處理后的大?。凑?heap_4 的分配方案，最先匹配原則，會(huì)從 56Bytes 大小的塊中分配一個(gè)32Bytes 出去，而不是從第二個(gè)空閑塊，剛剛好是 32Bytes 的塊中分配。這樣的分配方法就會(huì)產(chǎn)生碎片。碎片多了就會(huì)導(dǎo)致空閑內(nèi)存看似很多，但大的內(nèi)存塊已經(jīng)沒(méi)有了。

優(yōu)化的辦法也很簡(jiǎn)單，就是遍歷整個(gè)空閑鏈表，找到最優(yōu)的一個(gè)塊，其修改方法就是在原來(lái) first fit 的基礎(chǔ)上，遍歷剩余的鏈表：

/* first fit */
while ((pxBlock- >xBlockSize < xWantedSize) && (pxBlock- >pxNextFreeBlock != NULL))
{
   pxPreviousBlock = pxBlock;
   pxBlock = pxBlock- >pxNextFreeBlock;
}
/* best fit */
BlockLink_t *pxTmp = pxBlock;
BlockLink_t *pxPreTmp = pxPreviousBlock;while (pxTmp != pxEnd){
   if ((pxTmp- >xBlockSize >= xWantedSize) && (pxTmp- >xBlockSize < pxBlock- >xBlockSize))
  {
       pxBlock = pxTmp;
       pxPreviousBlock = pxPreTmp;
  }
   pxPreTmp = pxTmp;
   pxTmp = pxTmp- >pxNextFreeBlock;
}

最優(yōu)匹配的引入，不是一定就比原來(lái)的方案效果要好，因?yàn)楸闅v整個(gè)空閑鏈表，會(huì)導(dǎo)致分配內(nèi)存的時(shí)間變長(zhǎng)。這在某些對(duì)實(shí)時(shí)要求較高的環(huán)境中就不適應(yīng)了，比如在一些網(wǎng)絡(luò)環(huán)境中可能會(huì)因?yàn)槌瑫r(shí)而導(dǎo)致功能不正常。

其實(shí)分配快，內(nèi)存碎片少的方法有很多，只是他們的實(shí)現(xiàn)成本會(huì)有所不同，一個(gè)算法不可能適用所有的場(chǎng)景，分配方案中也沒(méi)有哪個(gè)比哪個(gè)一定更好，找到適合應(yīng)用場(chǎng)景的就是好的算法。這也許就是 FreeRTOS 中保留了多種分配方案的原因吧。