嵌入式中是否使用動(dòng)態(tài)內(nèi)存?

所謂動(dòng)態(tài)內(nèi)存分配(Dynamic Memory Allocation)就是指在程序執(zhí)行的過(guò)程中動(dòng)態(tài)地分配或者回收存儲(chǔ)空間的分配內(nèi)存的方法。

動(dòng)態(tài)內(nèi)存分配不像數(shù)組等靜態(tài)內(nèi)存分配方法那樣需要預(yù)先分配存儲(chǔ)空間，而是由系統(tǒng)根據(jù)程序的需要即時(shí)分配，且分配的大小就是程序要求的大小。

關(guān)于靜態(tài)內(nèi)存與動(dòng)態(tài)內(nèi)存

1.1、靜態(tài)和動(dòng)態(tài)內(nèi)存的特點(diǎn)
在探討這個(gè)問(wèn)題之前我們先來(lái)對(duì)比下靜態(tài)內(nèi)存和動(dòng)態(tài)內(nèi)存的特點(diǎn)：
1. 創(chuàng)建的時(shí)間不同：創(chuàng)建的時(shí)間不同：靜態(tài)分配發(fā)生在程序編譯和連接的時(shí)候。動(dòng)態(tài)分配則發(fā)生在程序調(diào)入和執(zhí)行的時(shí)候。

編譯鏈接過(guò)程中已經(jīng)分配好的

代碼運(yùn)行過(guò)程中使用rt_malloc分配:

1staticvoidonmessage_text(rws_socketsocket,constchar*text,constunsignedintlen) 2{ 3char*buff=RT_NULL; 4 5buff=(char*)rt_malloc(2048); 6 7rt_memset(buff,0x00,2048); 8rt_memcpy(buff,text,len); 9 10LOG_D("message(txt),%d(byte):%s",len,buff); 11 12if(buff!=RT_NULL) 13{ 14rt_free(buff); 15} 16}

2. 創(chuàng)建的空間不同：堆都是動(dòng)態(tài)分配的，沒(méi)有靜態(tài)分配的堆。棧有2種分配方式：靜態(tài)分配和動(dòng)態(tài)分配。靜態(tài)分配是編譯器完成的，比如局部變量的分配。動(dòng)態(tài)分配由函數(shù)malloc進(jìn)行分配。不過(guò)棧的動(dòng)態(tài)分配和堆不同，他的動(dòng)態(tài)分配是由編譯器進(jìn)行釋放，無(wú)需我們手工實(shí)現(xiàn)。

1.2、靜態(tài)和動(dòng)態(tài)內(nèi)存的優(yōu)缺點(diǎn)

在了解了靜態(tài)內(nèi)存和動(dòng)態(tài)內(nèi)存不同的特點(diǎn)后可以分析出它們?cè)诓煌姆矫婢哂胁煌膬?yōu)缺點(diǎn)：
1.靜態(tài)內(nèi)存編譯階段就分配好了，不會(huì)存在分配失敗的情況，除非系統(tǒng)內(nèi)存被分配完了，但是在編譯階段就可以查出。動(dòng)態(tài)內(nèi)存在運(yùn)行中分配，在正常運(yùn)行的情況下可能夠正常分配，在某種環(huán)境下可能分配失敗 ，這樣就對(duì)開(kāi)發(fā)者的代碼水平要求更高，要求開(kāi)發(fā)者需要對(duì)代碼的健壯性有要求。

2.靜態(tài)內(nèi)存由于是編譯階段分配好的，而動(dòng)態(tài)內(nèi)存是由運(yùn)行中分配，這樣動(dòng)態(tài)內(nèi)存可以被高效復(fù)用，當(dāng)某段程序使用完畢后，可以將內(nèi)存交換給內(nèi)存池中等待下次程序的分配，由于這種機(jī)制，開(kāi)發(fā)者可以利用更小的內(nèi)存開(kāi)發(fā)更大型的程序。

3. 動(dòng)態(tài)內(nèi)存由于是動(dòng)態(tài)分配，所以涉及到分配和釋放的問(wèn)題，假設(shè)X程序在分配了ABC3塊內(nèi)存，程序執(zhí)行完畢后AC區(qū)域內(nèi)存被釋放，但是由于開(kāi)發(fā)者的疏忽導(dǎo)致B區(qū)域的內(nèi)存被遺留。而X程序又是會(huì)被反復(fù)調(diào)用的，這樣我們的內(nèi)存區(qū)域由于有沒(méi)有釋放的區(qū)域?qū)е旅看握{(diào)用就會(huì)占用一段區(qū)域，最終系統(tǒng)就沒(méi)有內(nèi)存可以使用。這種情況一般在產(chǎn)品實(shí)際體現(xiàn)為最開(kāi)始的時(shí)候設(shè)備正常工作，但是運(yùn)行了幾個(gè)小時(shí)或者幾天后死機(jī)。這種情況一般被稱作內(nèi)存泄漏（Memory Leak）。

4. 在嵌入式RTOS中線程函數(shù)中使用靜態(tài)內(nèi)存，也就是在線程中定義局部變量，會(huì)加大線程?？臻g的開(kāi)銷。

裸機(jī)開(kāi)發(fā)和RTOS開(kāi)發(fā)的特點(diǎn)

1. 代碼規(guī)模：裸機(jī)開(kāi)發(fā)的項(xiàng)目一般代碼規(guī)模都比較小，對(duì)于一般開(kāi)發(fā)者都難于駕馭使用裸機(jī)開(kāi)發(fā)超大規(guī)模項(xiàng)目，人力成本和時(shí)間成本都太高。反而由于RTOS的模塊化特性，更容易開(kāi)發(fā)出代碼規(guī)模大的項(xiàng)目。

2. 系統(tǒng)穩(wěn)定性：在機(jī)電，航空，汽車等行業(yè)都是需要高實(shí)時(shí)性、高穩(wěn)定性和高安全性的。對(duì)于RTOS來(lái)說(shuō)，系統(tǒng)任務(wù)的劃分調(diào)度都是系統(tǒng)管理，當(dāng)開(kāi)發(fā)者對(duì)其機(jī)制了解不清楚的情況下反而帶來(lái)了部分風(fēng)險(xiǎn)。

除此之外RTOS上的內(nèi)存管理也是很大影響系統(tǒng)的，對(duì)于RTOS上一般不會(huì)存在MMU內(nèi)存管理單元，也就代表大部分運(yùn)行RTOS的芯片上都沒(méi)有虛擬地址映射，那么就無(wú)法利用物理地址和虛擬地址的特性進(jìn)行內(nèi)存整理，避免內(nèi)存泄漏。所以說(shuō)在RTOS動(dòng)態(tài)內(nèi)存這塊內(nèi)存有風(fēng)險(xiǎn)。

嵌入式中是否應(yīng)該使用動(dòng)態(tài)內(nèi)存

明白不同內(nèi)存的優(yōu)缺點(diǎn)和裸機(jī)RTOS的特點(diǎn)之后，我們?cè)诨仡^來(lái)分析 “嵌入式中是否應(yīng)該使用動(dòng)態(tài)內(nèi)存?”

在實(shí)時(shí)嵌入式系統(tǒng)中，由于系統(tǒng)軟件并不像PC上復(fù)雜，一般都是很簡(jiǎn)單的內(nèi)存使用，所以一般也不使用動(dòng)態(tài)內(nèi)存管理，但是隨著RTOS面臨的任務(wù)越來(lái)越重，尤其是IoT和AIoT的到來(lái)，讓許多消費(fèi)級(jí)產(chǎn)品運(yùn)行的RTOS的負(fù)擔(dān)越來(lái)越重。

在這種情況下繼續(xù)使用靜態(tài)內(nèi)存開(kāi)發(fā)會(huì)極大的限制開(kāi)發(fā)進(jìn)度，整個(gè)開(kāi)發(fā)的靈活性非常低。同時(shí)靜態(tài)的內(nèi)存無(wú)法復(fù)用使用同一片內(nèi)存區(qū)域，相比與動(dòng)態(tài)內(nèi)存在大型項(xiàng)目中一般會(huì)使用更多的內(nèi)存，在內(nèi)存大小不容樂(lè)觀的嵌入式系統(tǒng)是很難接受的。

但是針對(duì)一些高穩(wěn)定性和高安全性的項(xiàng)目來(lái)說(shuō)，使用動(dòng)態(tài)內(nèi)存就需要好好斟酌下，由于RTOS上基本沒(méi)有MMU的硬件支持或者是系統(tǒng)軟件支持，所以不可避免的系統(tǒng)中會(huì)出現(xiàn)內(nèi)存碎片，從而有可能導(dǎo)致系統(tǒng)異常。最終說(shuō)了這么多總結(jié)成以下幾點(diǎn)：
1. 沒(méi)有使用RTOS的項(xiàng)目：不建議使用動(dòng)態(tài)內(nèi)存，這種項(xiàng)目一般很簡(jiǎn)單，不必使用動(dòng)態(tài)內(nèi)存增大系統(tǒng)開(kāi)銷和復(fù)雜度。

2. 使用RTOS的消費(fèi)級(jí)項(xiàng)目：建議使用動(dòng)態(tài)內(nèi)存，一般這種項(xiàng)目代碼復(fù)雜度比裸機(jī)高，合理使用動(dòng)態(tài)內(nèi)存會(huì)有效降低內(nèi)存的開(kāi)銷。同時(shí)很多Github項(xiàng)目的linux程序都是會(huì)使用內(nèi)存管理，有這套機(jī)制能更加方便的移植代碼。

3. 使用RTOS的軍工、航天、醫(yī)療等高穩(wěn)定性和高安全性項(xiàng)目：建議盡量降低對(duì)動(dòng)態(tài)內(nèi)存的使用與依賴以確保系統(tǒng)的穩(wěn)定性。當(dāng)然也不代表動(dòng)態(tài)內(nèi)存就無(wú)法在這些項(xiàng)目上使用，只是要求系統(tǒng)開(kāi)發(fā)者對(duì)系統(tǒng)內(nèi)存的把控要求更高。

RT-Thread的內(nèi)存管理

RT-Thread 操作系統(tǒng)在內(nèi)存管理上，根據(jù)上層應(yīng)用及系統(tǒng)資源的不同，有針對(duì)性地提供了不同的內(nèi)存分配管理算法。總體上可分為兩類：內(nèi)存堆管理與內(nèi)存池管理，而內(nèi)存堆管理又根據(jù)具體內(nèi)存設(shè)備劃分為三種情況：

第一種是針對(duì)小內(nèi)存塊的分配管理（小內(nèi)存管理算法）；
第二種是針對(duì)大內(nèi)存塊的分配管理（slab 管理算法）；
第三種是針對(duì)多內(nèi)存堆的分配情況（memheap 管理算法）。

小內(nèi)存管理算法是一個(gè)簡(jiǎn)單的內(nèi)存分配算法。初始時(shí)，它是一塊大的內(nèi)存。當(dāng)需要分配內(nèi)存塊時(shí)，將從這個(gè)大的內(nèi)存塊上分割出相匹配的內(nèi)存塊，然后把分割出來(lái)的空閑內(nèi)存塊還回給堆管理系統(tǒng)中。每個(gè)內(nèi)存塊都包含一個(gè)管理用的數(shù)據(jù)頭，通過(guò)這個(gè)頭把使用塊與空閑塊用雙向鏈表的方式鏈接起來(lái)。

RT-Thread 的 slab 分配器是在 DragonFly BSD 創(chuàng)始人 Matthew Dillon 實(shí)現(xiàn)的 slab 分配器基礎(chǔ)上，針對(duì)嵌入式系統(tǒng)優(yōu)化的內(nèi)存分配算法。最原始的 slab 算法是 Jeff Bonwick 為 Solaris 操作系統(tǒng)而引入的一種高效內(nèi)核內(nèi)存分配算法。

memheap 管理算法適用于系統(tǒng)含有多個(gè)地址可不連續(xù)的內(nèi)存堆。使用 memheap 內(nèi)存管理可以簡(jiǎn)化系統(tǒng)存在多個(gè)內(nèi)存堆時(shí)的使用：當(dāng)系統(tǒng)中存在多個(gè)內(nèi)存堆的時(shí)候，用戶只需要在系統(tǒng)初始化時(shí)將多個(gè)所需的 memheap 初始化，并開(kāi)啟 memheap 功能就可以很方便地把多個(gè) memheap（地址可不連續(xù)）粘合起來(lái)用于系統(tǒng)的 heap 分配。