FreeRTOS8.0.1內(nèi)存管理的最后一個堆模型Heap_4，貌似是在這一個版本才有的。所以找到的說明幾乎沒有。代碼的開頭注釋也只是簡單地說了一下實現(xiàn)了pvPortMalloc()和vPortFree()兩個函數(shù)，并且能夠?qū)厥盏膬?nèi)存塊進行合并，減少碎片的出現(xiàn)。（A sample implementation of pvPortMalloc() and vPortFree() that combines (coalescences) adjacent memory blocks as they are freed, and in so doing limits memory fragmentation.）不過經(jīng)過這一次的剖析之后，發(fā)現(xiàn)Heap_4所用的內(nèi)存管理算法為首次適配法（first fit algorithm）。

和Heap_2一樣，Heap_4先申請了一個數(shù)組ucHeap[ configTOTAL_HEAP_SIZE ]作為自己管理的堆空間，同樣也有空閑塊頭結(jié)構(gòu)BlockLink_t來管理空閑塊。但是和Heap_2不一樣的是，Heap_4用了BlockLink_t中xBlockSize的最高一位來標識某個內(nèi)存塊是否處于空閑狀態(tài)。所以這就是為什么會有一個宏heapBITS_PER_BYTE的出現(xiàn)，而且定義為( ( size_t ) 8 )。這樣一來，每一個分配出去的內(nèi)存塊大小就有限制了。例如，我用的是STM32F103，size_t是定義為unsigned int類型的，32位，可支持到4G的內(nèi)存空間。但是最高1位用來指示空間狀態(tài)的話，那就只有31位去標識內(nèi)存塊地址，即只支持到2G的內(nèi)存空間。所以用Heap_4還是有一點點代價的，特別是用在16位或8位的單片機上。
還是先剖析一下堆空間的初始化過程prvHeapInit()。首先還是先將內(nèi)存堆進行首地址對齊。接下來就是運用xStart和pxEnd來組織整個空閑塊鏈表。要注意的是，xStart是BlockLink_t的一個實體變量，存儲在靜態(tài)存儲區(qū)，而pxEnd只是BlockLink_t的一個指針，存儲在靜態(tài)存儲區(qū)中，卻指向了內(nèi)存堆的最后一個BlockLink_t大小的位置上。也就是說，內(nèi)存堆最后的空間是存儲著一個BlockLink_t，用來指示空閑塊鏈表的終結(jié)，這是和Heap_2有所不同的地方。下圖說明了初始化流程最終將空閑塊鏈表組織成的樣子。

接下來剖析Heap_4的第一個重點：pvPortMalloc()。和以前一樣，分配內(nèi)存之前還是先調(diào)用vTaskSuspendAll()掛起所有任務(wù)，以確保分配內(nèi)存的過程不被中斷。下一步通過判斷pxEnd是否為空來決定是否需要初始化內(nèi)存堆和空閑塊鏈表。因此，初始化之后pxEnd就不為空了，以后再調(diào)用pvPortMalloc()也因此不再調(diào)用初始化函數(shù)。但是這一個判斷的另一個分支（else分支卻調(diào)用了一個mtCOVERAGE_TEST_MARKER()的宏，這個宏的定義在FreeRTOS.h里，定義為空。因此目前還不知道這一個宏具體作用，看名字應(yīng)該是用來測試什么的。接下來是判斷用戶申請內(nèi)存大小的最高位是否為0，為0即合法（之前說過，最高位用來標識空閑塊的空閑狀態(tài)，因此最高位為1則說明用戶申請的內(nèi)存大小已超出空閑塊的最大大?。?。然后還是一個size_t類型的數(shù)據(jù)與0比較的判斷（雖然這個判斷總為真，但也不知道作者為啥要寫這么一個判斷，要是有人知道這一個判斷的意途，請告訴我），里面是增大用戶申請的空間大小以便容納空閑塊塊頭BlockLink_t以及將最終申請的內(nèi)存大小進行對齊。
以上的預(yù)處理完成了，開始進入分配算法的核心了。只要最終申請的空間大小仍在空閑空間大小的范圍內(nèi)，則進入內(nèi)存的分配。首先遍歷鏈表，找到第1塊能比申請空間大小大的空閑塊，修改空閑塊的信息，記錄用戶可用的內(nèi)存首地址。接下來，如果分配出去的空閑塊比申請的空間大很多，則將該空閑塊進行分割，把剩余的部分重新添加到鏈表中。
分配內(nèi)存的主要流程基本結(jié)束了，和之前分析的一樣，pvPortMalloc()繼續(xù)調(diào)用調(diào)試宏traceMALLOC()輸出調(diào)試信息，恢復(fù)所有掛起的任務(wù)，并按設(shè)置調(diào)用勾子函數(shù)vApplicationMallocFailedHook()，最終把用戶可用的內(nèi)存首地址返回。到這里整個pvPortMalloc()就結(jié)束了。
但是，有一個地方剛剛沒怎么詳細講，就是把分割出來的空閑塊重新添加到鏈表中的過程?，F(xiàn)在來詳細分析一下，這也是Heap_4的一個重點。和Heap_2不同，這一次的prvInsertBlockIntoFreeList()并不是寫成一個宏，而是寫成了一個函數(shù)。進入函數(shù)的開始，可以看到，F(xiàn)reeRTOS實際上是將這個空閑塊鏈表里的所有空閑塊按地址順序排列的。當然，如果不這么排列，怎么能將相鄰的空閑塊進行合并呢？將要回收的空閑塊為pxBlockToInsert，這個空閑塊將被插到pxIterator的后面。通過一次鏈表的遍歷，就把pxIterator找出來了。接下來，F(xiàn)reeRTOS先試著將pxIterator和pxBlockToInsert進行合并，可以合并的標準為pxIterator的首地址加上pxIterator的塊大小之后等于pxBlockToInsert的首地址。相等就說明兩個塊是相鄰的。如果不能合并，就什么事都不做。然后，F(xiàn)reeRTOS再試著將pxBlockToInsert和pxIterator指向的下一個空閑塊進行合并?？珊喜⒌臉藴屎蛣倓傉f的一樣，只是這次用pxBlockToInsert的首地址加上pxBlockToInsert的塊大小與pxIterator指向的下一個塊地址比較。能合并是最好的，不能合并，則要修改pxBlockToInsert的Next指針，指向pxIterator的下一個空閑塊。這是鏈表插入的基本操作，不用再細講了。最后，要是pxBlockToInsert沒有和pxIterator合并，則還要修改pxIterator的Next指針，這樣整條鏈表才完整無誤。
最后一個重點是vPortFree()。不過這里的vPortFree()的流程和Heap_2的差不多，只是判斷指針合法性的時候多了兩個條件，一個是檢查回收的塊大小最高位是否為1，為1才是合法的，畢竟是分配出去了嘛。第二個是Next指針是否為空，為空了說明那是pxEnd，那就不能回收了。在這兩個判斷之前也有這兩個條件的斷言configASSERT()，定義在FreeRTOS.h里，同樣也是定義為空，可能是留給用戶另外用的吧。
Heap_4的其它三個函數(shù)，一個名字看上去是做什么初始化的，卻什么都沒有實現(xiàn)，所以沒啥好講的，另外兩個只是用來返回內(nèi)存堆的一些狀態(tài)而已，所以也沒啥好講的。到這里，整個Heap_4就剖析完成了。

總結(jié)：終于把FreeRTOS的4個內(nèi)存堆模型全部剖析完了。心情好激動。終于可以開始剖析FreeRTOS的內(nèi)核代碼了。不過，內(nèi)核代碼可不是那么容易剖析的，可能不像內(nèi)存堆一樣，幾百行就解決了，所以，之后花的時間可能會更多。不過不怕，反正有的是時間，總會有一天把整個內(nèi)核都剖析完的。下一次開始，就從list.c開始剖析吧！