基于鏈?zhǔn)蕉询B的內(nèi)存管理方法與系統(tǒng)的制作方法
【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及信息技術(shù)領(lǐng)域，關(guān)于計算機(jī)系統(tǒng)的動態(tài)內(nèi)存管理，尤其是用于嵌入式 實時內(nèi)核中的內(nèi)存管理方法與系統(tǒng)，適于對由單片機(jī)作為主控，性能、資源相對有限的系 統(tǒng)，例如以實時內(nèi)核MadOS為基礎(chǔ)的嵌入式系統(tǒng)的內(nèi)存進(jìn)行高效管理。
【背景技術(shù)】
[0002] 在嵌入式系統(tǒng)領(lǐng)域，uCOS-II與FreeRTOS是兩個非常典型的實時內(nèi)核，其中內(nèi)存 管理方法也很具代表性。
[0003] 1、uCOS-II中的內(nèi)存管理
[0004] UC0S-II在嵌入式系統(tǒng)領(lǐng)域一直以其穩(wěn)定性著稱，它曾經(jīng)被用在美國的月球車之 中。其高穩(wěn)定性的一個重要原因在于，uCOS-II盡可能的避免使用動態(tài)內(nèi)存，例如：uC0S-II 中的每一個線程堆棧都是一個預(yù)定義好的數(shù)組。換句話說，uCOS-II盡可能將內(nèi)存的分配 放在程序的編譯階段，而非運行階段。
[0005] uCOS-II的內(nèi)存管理的核心思想是：先在源代碼里定義一塊數(shù)據(jù)，當(dāng)上層應(yīng)用需 要時，將這塊數(shù)據(jù)區(qū)域分配給上層應(yīng)用使用。具體而言，就是預(yù)先在代碼里定義一個全局 變量：unsigned char buffer。當(dāng)有上層應(yīng)用申請動態(tài)內(nèi)存時，直接將buffer指針返回給 上層應(yīng)用。顯然，這里只定義了一塊內(nèi)存是肯定不夠用的，uCOS-II中將其定義為2維數(shù)組 buff er[X][y]，x是內(nèi)存塊的數(shù)量，y即每塊內(nèi)存的大小。假設(shè)y的值是64,那么當(dāng)上層應(yīng) 用實際需要一塊17字節(jié)的空間時，由于buffer是預(yù)先定義好的數(shù)組，不可能從內(nèi)部拆分， 所以，實際返回給應(yīng)用的是一塊64字節(jié)的內(nèi)存，如此一來，在應(yīng)用釋放這塊內(nèi)存之前，這塊 內(nèi)存中的64-17 = 47個字節(jié)就處于"無所事事"的狀態(tài)，造成內(nèi)存浪費。
[0006] uCOS-II將上述方法做了改進(jìn)：定義多個y值不同的buffer，應(yīng)用根據(jù)自身的需 要，選擇最合適的尺寸進(jìn)行申請。例如：假設(shè)預(yù)先定義了 y值分別為32、64、128、256的4種 buffer，當(dāng)應(yīng)用需要60字節(jié)時，就向y值為64的buffer申請，當(dāng)應(yīng)用需要70字節(jié)時，就向 y值為128的buffer申請。這樣的做法一定程度上緩解了內(nèi)存浪費，但是并沒有從根本上 解決問題。
[0007]uCOS-II內(nèi)存管理的核心在于一個數(shù)據(jù)結(jié)構(gòu)。uCOS-II把每一種y值對應(yīng)的2維 數(shù)組buffer稱作一個分區(qū)（Partition)，新建一個分區(qū)需要：
[0008] 1)定義一個全局2維數(shù)組buffer [x] [y]。
[0009] 2)取得一個由內(nèi)存管理模塊定義的0S_MEM結(jié)構(gòu)體，并對其初始化。將buffer下 的每一個內(nèi)存塊鏈接在一起，如圖1所示。
[0010] -個分區(qū)（pa)初建立時，形成了一條以pa.OSMemFreeList為頭部的單鏈表。
[0011] 當(dāng)需要向pa分區(qū)申請動態(tài)內(nèi)存時，實際上是將鏈表中的一個元素刪除，并將這個 元素返回給上層應(yīng)用。
[0012] 當(dāng)需要向pa分區(qū)釋放動態(tài)內(nèi)存時，實際是將欲釋放的內(nèi)存塊插入到鏈表頭部。
[0013] 可見，對于一種y值的buffer來說，使用者必須在源代碼里定義好x值，也就是 說，使用者必須對需要多少個內(nèi)存塊做出判斷。然而，在一個系統(tǒng)中，動態(tài)內(nèi)存的使用時機(jī) 是不確定的，因此要得到X的值有兩種做法：
[0014] 1)大量實驗，根據(jù)實驗的結(jié)果確定x的值。但在實際項目中，這種方法是不可行 的，首先，需要考慮各種使用環(huán)境；再者，針對不同的項目，X的值需要重新進(jìn)行測試。這種 方法使得以往的工作成果變得不可重復(fù)利用，嚴(yán)重降低了工作效率。
[0015] 2)預(yù)設(shè)一個大值。在一個實際的嵌入式系統(tǒng)中，可能包含多個第三方模塊，有的 模塊有自己的內(nèi)存管理子模塊，這些模塊并不需要系統(tǒng)提供的內(nèi)存管理方法。那么當(dāng)x值 設(shè)得很大時，就會出現(xiàn)一種情況：系統(tǒng)自身的內(nèi)存管理模塊占用了大量的內(nèi)存，而利用率很 低，其他第三方模塊的內(nèi)存管理子模塊只占用很少的內(nèi)存，而不夠用。最終整個系統(tǒng)因為第 三方模塊無法正常運行而出現(xiàn)異常，甚至崩潰。
[0016] y值的確定也存在著與x值類似的問題。而且，有些情況下，應(yīng)用是沒法知道自己 在運行到某一時刻是需要多少動態(tài)內(nèi)存的，例如，一些自定的通信協(xié)議，會先傳輸一個固定 長度的頭部，后面跟一個長度可變的數(shù)據(jù)載荷，這個數(shù)據(jù)載荷需要用動態(tài)內(nèi)存臨時存儲，那 么，應(yīng)用編程人員必須在代碼里，對申請哪個y值的動態(tài)內(nèi)存進(jìn)行判斷，如果系統(tǒng)上存在多 個通信接口，而通信協(xié)議都具有上述的特征，還需要考慮如何將對y值的判斷方法抽象成 一般規(guī)則，以便能應(yīng)用到全部的接口上。
[0017]2、FreeRTOS中的內(nèi)存管理
[0018] FreeRTOS是實時內(nèi)核家族中的新成員，以開源的形式得到很多開發(fā)者的青睞。其 中的內(nèi)存管理方式與uCOS-II截然不同。
[0019] FreeRTOS內(nèi)存管理的核心思想是將整個內(nèi)存堆空間看作一個整體，遵循需要多 少，分配多少的原則進(jìn)行內(nèi)存管理。FreeRTOS中也有一個類似0S_MEM的數(shù)據(jù)結(jié)構(gòu)。
[0020] 在使用動態(tài)內(nèi)存之前需要調(diào)用初始化API，對內(nèi)存堆進(jìn)行初始化，如圖2所示。
[0021] 1)初始化全局變量xStart、xEnd，這兩個變量都是xBlockLink類型的，其作用是 標(biāo)識空閑內(nèi)存鏈表的頭與尾。
[0022] 2)在內(nèi)存堆的首地址處插入一個xBlockLink結(jié)構(gòu)體，使之與xStart、xEnd -起 組成最初的空閑內(nèi)存鏈表：
[0023] 經(jīng)過初始化后的全局變量xStart、xEnd及內(nèi)存堆的狀態(tài)如圖3所示。
[0024] 當(dāng)申請動態(tài)內(nèi)存時，掃描以xStart為頭，xEnd為尾的空閑內(nèi)存塊鏈表list，找出 一塊xBlockSize大于需求尺寸wantSize的內(nèi)存塊，然后：
[0025] 1)將該塊空閑內(nèi)存從list中刪除，并記錄表下該塊內(nèi)存的首地址ptr。
[0026] 2)在ptr+sizeof(xBlockLink)+wantSize的內(nèi)存處放置一個xBlockLink結(jié)構(gòu)體， 形成一個新的空閑塊：
[0027] 新尺寸=原尺寸-wantSize。
[0028] 3)將新形成的空閑塊插入到list中。
[0029] 4)將指針（ptr+sizeof(xBlockLink))返回給上層應(yīng)用。
[0030] 當(dāng)釋放動態(tài)內(nèi)存時，將上層傳入的指針減去sizeof(xBlockLink)就得到該塊內(nèi) 存的xBlockLink結(jié)構(gòu)體指針，然后將該塊內(nèi)存插入到list鏈表中，即完成回收。
[0031] FreeRTOS的這種回收機(jī)制必須考慮一個重要的問題：內(nèi)存塊回收之后，如果存在 幾個連續(xù)的內(nèi)存塊，如何將他們合并？實際上，F(xiàn)reeRTOS并沒有考慮內(nèi)存合并的問題，那 么，隨著系統(tǒng)運行時間的推移，將會產(chǎn)生大量的內(nèi)存碎片，最終，當(dāng)需要某一大尺寸的內(nèi)存 塊時，空閑內(nèi)存的總量是足夠的，但都是非常小的碎片，導(dǎo)致內(nèi)存分配失敗，進(jìn)而引起系統(tǒng) 功能混亂、甚至崩潰。
[0032] FreeRTOS在管理內(nèi)存時，會將list中的內(nèi)存塊按由小到大的順序排列，以便再分 配時，盡可能分配一塊小內(nèi)存給應(yīng)用，這樣就提升了內(nèi)存使用效率。但是，由于不對內(nèi)存塊 進(jìn)行合并，這樣的思路會導(dǎo)致一個問題，由于小內(nèi)存不斷細(xì)化，空閑鏈表list的前面會存 在大量的小塊，而這些小塊隨著自己越來越小，被利用的概率會越來越低，那么，當(dāng)查找一 塊較大的空閑內(nèi)存時，將會有大量的CPU時間浪費在掃描那些細(xì)化的小塊上。
[0033] 另外，釋放內(nèi)存時uCOS-II與FreeRTOS都沒有考慮傳入一個錯誤指針，即并非指 向有效動態(tài)內(nèi)存塊的指針時應(yīng)該如何處理，如果不做處理，而對該無效內(nèi)存塊執(zhí)行釋放操 作，必然導(dǎo)致系統(tǒng)崩潰。

【發(fā)明內(nèi)容】

[0034] 本發(fā)明目的在于提供一種用于實時內(nèi)核的內(nèi)存管理方法，采用鏈?zhǔn)蕉询B，使得已 分配內(nèi)存塊向內(nèi)存堆的頭部"堆積"，從而減少內(nèi)存碎片的產(chǎn)生，同時提高實時內(nèi)核運行時 動態(tài)內(nèi)存的使用效率。
[0035] 本發(fā)明的上述目的通過獨立權(quán)利要求的技術(shù)特征實現(xiàn)，從屬權(quán)利要求以另選或有 利的方式發(fā)展獨立權(quán)利要求的技術(shù)特征。
[0036] 為達(dá)成上述目的，本發(fā)明提出一種用于實時內(nèi)核的內(nèi)存管理方法，包括：
[0037] 為內(nèi)存堆內(nèi)每一塊被分配的動態(tài)內(nèi)存前面插入一個結(jié)構(gòu)體形成一個動態(tài)內(nèi)存塊， 使得每個動態(tài)內(nèi)存塊包括該結(jié)構(gòu)體和數(shù)據(jù)內(nèi)存區(qū)；每個動態(tài)內(nèi)存塊的首地址都鏈接在一條 單鏈表上，其中所述的結(jié)構(gòu)體包括動態(tài)