越來越多的嵌入式軟件開發人員意識到動態內存分配——在需要時獲取大塊內存并在以后放棄它們——雖然方便靈活，但也充滿了問題。這些問題不僅限于嵌入式代碼，許多桌面應用程序都存在影響性能和可靠性的內存泄漏。但在這里我想專注于嵌入式。

質疑使用標準malloc（）庫函數的三個關鍵原因：

內存分配可能會失敗。這可能是因為沒有足夠的可用內存（在堆中）來滿足請求。也可能是碎片造成的；有足夠的可用內存，但沒有連續的塊足夠大。

該函數通常是不可重入的。在多線程（多任務）系統中，如果函數被多個任務調用，則它們必須是可重入的。這確保了，如果調用被中斷，對該函數的另一次調用不會危及第一次調用。

它不是確定性的。在實時系統中，可預測性（確定性）至關重要。標準malloc（）函數的執行時間非常多變且無法預測。

這些都是有效的點，并且有解決它們的方法，這通常是使用實時操作系統 （RTOS） 提供的功能的問題。

然而，盡管它們是有效的，但問題可能并不總是像看起來那么重要：

如果發生分配失敗，該函數將返回一個NULL指針。這很容易檢查，并且可以采取行動。

在許多應用程序中，所有內存分配和釋放都在單個任務中執行。這使得重入是不必要的。

并非所有嵌入式系統都是實時的，因此可能不需要確定性。

malloc（）可能會帶來另一個挑戰：它相當慢。一些系統需要速度，而不是可預測性，因此需要考慮找到一種方法來提供此功能的功能并具有更高的性能。

該函數性能不佳的主要原因是它提供了很多功能。不同大小的內存塊的管理是相當復雜的。對于許多應用程序來說，這實際上是多余的，因為所需的內存分配都是相同的大?。ɑ蛏倭坎煌囊阎笮。?。為固定大小的塊編寫內存分配器非常簡單；只是一個帶有使用標志的數組或者一個鏈表。代碼肯定會更快，甚至可以確定地完成。分配失敗仍然可能發生，但管理起來很簡單。這種類型的內存分配通常由流行的 RTOS 產品提供。

審核編輯：郭婷