我遇到的許多嵌入式軟件開發(fā)人員提出的一個我覺得特別有趣的話題是動態(tài)內(nèi)存分配——在需要時獲取內(nèi)存塊。這種看似簡單和常規(guī)的操作會帶來大量問題。這些并不局限于嵌入式開發(fā)——許多桌面應(yīng)用程序都會出現(xiàn)內(nèi)存泄漏，這會影響性能，并且會使系統(tǒng)重新啟動很常見。但是，我擔(dān)心嵌入式開發(fā)環(huán)境。

通常不建議將malloc()用于嵌入式應(yīng)用程序的原因有很多：

• 該函數(shù)通常不可重入（線程友好），因此將其與實時操作系統(tǒng)一起使用可能具有挑戰(zhàn)性。
• 它的性能不是確定性的（可預(yù)測的），因此分配一個內(nèi)存塊所花費的時間可能是非?？勺兊?，這在實時應(yīng)用程序中是一個挑戰(zhàn)。
• 內(nèi)存分配可能會失敗。

盡管這些都是有效的觀點，但它們可能并不像看起來那么重要。

僅當(dāng)從多個線程調(diào)用函數(shù)時，重入才是一個問題。編寫一個可重入的malloc()函數(shù)是非?？尚械?，但也可以使用標(biāo)準(zhǔn)版本以使重入變得不必要。只需將所有內(nèi)存分配活動本地化為單個任務(wù)。您甚至可以創(chuàng)建一個唯一功能是動態(tài)內(nèi)存分配的任務(wù)；其他任務(wù)將簡單地發(fā)送一條消息，請求分配或釋放內(nèi)存塊。

并不總是需要確定性。并非應(yīng)用程序是實時的，并且那些不一定需要對其操作的所有部分確定性的應(yīng)用程序。

分配失敗可能是個問題，但可以管理。如果malloc()函數(shù)無法分配所請求的內(nèi)存，則它會返回一個空指針。必須檢查此響應(yīng)并采取適當(dāng)?shù)拇胧?/font>如果失敗是由于內(nèi)存耗盡，很可能是設(shè)計缺陷——沒有為堆分配足夠的內(nèi)存。然而，分配失敗的一個常見原因是堆碎片。有足夠的可用內(nèi)存，但它不在連續(xù)區(qū)域中。這種碎片的出現(xiàn)是因為內(nèi)存以隨機方式分配和釋放，從而導(dǎo)致內(nèi)存的分配和空閑區(qū)域。有兩種方法可以消除碎片：

首先，如果應(yīng)用程序允許，只需確保使用遵循這種模式的代碼按順序完成分配和釋放：

a = malloc(1000);
b = malloc(100);
c = malloc(5000);
...
免費（c）；
免費（乙）；
免費（一）；

當(dāng)然，這通常是不可能的。因此，需要另一種選擇。

事實證明，許多應(yīng)用程序并不需要malloc()提供的所有靈活性。所需的內(nèi)存塊具有固定大小（或少量不同大?。?。為固定大小的塊編寫內(nèi)存分配器非常簡單；這消除了碎片化，如果需要，可以很容易地確定性。毫不奇怪，大多數(shù) RTOS 都有以這種方式分配內(nèi)存塊的服務(wù)調(diào)用。

不管它的不可預(yù)測性如何， malloc()還有另一個問題——它往往相當(dāng)慢。這并不奇怪，因為該函數(shù)的功能非常復(fù)雜。基于塊的分配器的內(nèi)在簡單性非常有效地解決了這個問題。

但是，如果應(yīng)用程序在不可預(yù)測的時間確實需要隨機大小的內(nèi)存塊怎么辦？

實現(xiàn)這種靈活性同時避免碎片和不確定性的一種方法是構(gòu)建一個分配器，根據(jù)請求的內(nèi)存塊大小從多個“池”中選擇塊。為池選擇塊大小的一個好方法（如果您事先不知道需要的塊大?。┦鞘褂脦缀蜗盗?，如 16、32、64、128 字節(jié)。然后分配將像這樣工作：

顯然，一些分配會非常有效：16 字節(jié)池中的 16 字節(jié)。有些會非常好；來自 32 字節(jié)池的 31 個字節(jié)。其他人會沒事的；來自 16 字節(jié)池的 9 個字節(jié)。還有一些效率低下；來自 128 字節(jié)池的 65 個字節(jié)。總體而言，這些低效率是為速度、確定性和消除碎片化的好處付出的小代價。

審核編輯：湯梓紅