動態分配在 C/C++ 中普及，通過在運行時根據需要將系統內存分配給應用程序進程，并在不再需要內存時檢索內存，從而簡化開發。

但動態分配被廣泛認為是安全關鍵型嵌入式軟件的禁忌。使用 C 運行時庫的 malloc（） 和 free（） API 來完成動態分配的繁重工作，可能會引入災難性的副作用，例如內存泄漏或碎片。此外，malloc（） 可能會表現出非常不可預測的性能，并成為多核系統上多線程程序的瓶頸。由于其風險，根據DO-178B標準，在安全關鍵型嵌入式航空電子代碼中禁止動態內存分配。

整個嵌入式行業的開發人員似乎對這個話題做出了發自內心的反應。在最近的一次互聯網技術小組討論中，“你在嵌入式設計中使用動態內存分配嗎？”這個問題獲得了驚人的77個回答，典型的是“一般來說，它被認為違反了容錯系統的最佳實踐”，以及“如果要求包括‘五個九’（99.999%的正常運行時間）可靠性，硬實時或小內存占用，答案是‘從不’。求職者請注意：一位咨詢工程師的面試策略“是溫和地探查潛在員工在實時應用程序中的動態內存分配使用情況。如果他們對此沒有問題，他們就不會被雇用。

更好的策略 - 無論是代碼安全和工作面試成功 - 是將安全關鍵代碼中的標準（默認）分配器替換為更匹配特定分配方案的自定義內存分配函數。以下討論描述了兩個這樣的自定義內存管理器：基于堆棧的分配器和線程本地分配器。擺脫 malloc（） 和 free（） 應用程序的另一種方法——從而獲得更好的性能、穩定性和可預測性——是用包含自定義分配器的現成軟件替換基于標準分配函數的代碼。內存數據庫系統（IMDS）的使用被討論為這種“購買而不是構建”方法的一個例子。

這是標準的，但它是最好的嗎？

為什么標準（動態）內存管理器不適合任務關鍵型代碼？通常，它們基于列表分配器算法，該算法將內存池組織到單向鏈表中的連續位置（空閑孔）。然后，分配器“行走”這條鏈條，尋找合適的孔來滿足請求。列表分配器是典型的通用功能：它們在各種情況下分配和解分配內存方面做得很好 - 但在任務或安全關鍵系統中“相當好”還不夠好。

基于堆棧的算法：分配和倒帶內存

某些應用程序方案需要分配許多生存期較短的對象，然后一次釋放所有對象。基于堆棧的分配器（不要與應用程序調用堆棧混淆）是一種類型的自定義分配器，在這里運行良好。使用此算法，每次分配返回堆棧指針當前位置的地址，并按請求量推進指針（圖 1）。當不再需要內存時，堆棧指針將倒帶。處理開銷減少了，因為沒有要管理的指針鏈，也沒有任何要跟蹤的分配大小或可用孔。這種方法也更安全：不會因不當的解除分配而意外引入內存泄漏，因為應用程序不必跟蹤特定的分配。

圖1：基于堆棧的自定義分配器

與標準列表分配器相比，使用基于堆棧的分配器所消除的開銷隨著應用程序的繼續運行而增加。當內存以隨機順序釋放時，列表分配器通常需要將指針和大小值添加到其鏈中（這稱為碎片），以便指針和大小值表示占總堆大小的更大百分比。因此，列表分配器的開銷（必須管理的元數據量以及必須走得更遠才能找到合適的可用漏洞的可能性）隨著應用程序的繼續運行而增長。（使用基于堆棧的分配器，從某個時間點分配的所有塊都會在一個操作中返回到堆中，從而避免碎片。

多線程、多核分配挑戰

當多線程應用程序陷入多處理器硬件時，由互斥鎖控制的默認 malloc（） 和 free（） 函數通常是罪魁禍首。使用這些分配器的線程可能會導致鎖定沖突，操作系統通過消耗性能的上下文切換部分解決這些問題。自定義線程本地分配器通過為每個線程分配特定的內存池來避免沖突。線程的分配是從這個塊執行的，而不會干擾其他線程的請求，從而提高性能和可預測性。當線程分配器內存不足時，如果系統允許，其他分配器可以為其分配另一個塊。線程本地分配器對每個線程使用掛起請求列表或 PRL 來協調由執行原始分配的線程以外的線程釋放的內存塊的釋放。由同一線程分配和取消分配的內存不需要協調，因此不會發生鎖沖突。

簡而言之，通過從 malloc（） 和 free（） 中刪除內存管理責任并將其分配給應用程序，可以避免安全關鍵代碼中的問題，應用程序使用與特定應用程序任務相吻合的自定義分配器。自定義分配器為該任務的獨占使用留出緩沖區（通常在啟動期間），并滿足來自它的內存分配請求。如果緩沖區內存不足，應用程序將收到通知，并可以釋放緩沖區內的內存。或者它可以在其他地方找到更多的內存來投入到任務中。耗盡此專用池中的內存不會影響系統的其他部分。可以選擇的自定義分配器包括所討論的分配器，以及位圖分配器、塊分配器等。

通過第三方應用程序分配

自定義內存分配器的優勢也可以通過集成使用它們的第三方軟件來利用。IMDS是受益于自定義分配器的良好候選者，因為它們專門設計用于管理RAM中的應用程序對象。圖 2 說明了使用 malloc（） 和 free（） 進行分配/解除分配。圖3顯示了使用McObject的eXtremeDB的相同過程，這是一個IMDS，它結合了自定義分配器，包括基于堆棧和線程本地。在圖 2 的開頭，C 程序定義了一個結構，聲明了一個指向該結構實例的指針，并通過 malloc（） 為其分配內存。

圖2：使用 malloc（） 和 free（） 進行內存分配

圖3：使用內存數據庫系統的內存分配

使用IMDS的程序員在數據庫模式文件中定義類，該文件被處理（通過特殊的編譯器）以產生.C 文件，以及 。包含類型定義和函數原型的 H 文件。

如果使用 malloc/free 的程序是多線程的，并且線程將共享 Sensor 對象，則開發人員必須實現并發控制。使用IMDS，并發性通過事務自動管理。圖 3 顯示了事務如何開始 （mco_trans_start） 并獲取事務句柄。

調用 Sensor_new（） 會聲明一些專用于新傳感器對象的 IMDS 內存池。（在軍事/航空航天應用中，傳感器對象可以代表任何東西，從用于跟蹤導彈目標的光學傳感器到用于化學戰防御的生物傳感器或幫助導航飛機的運動傳感器。Sensor_new（） 返回數據庫對象的句柄，通過該句柄可以寫入和/或讀取對象的值。相比之下，C 程序直接處理結構的字段，從而在多線程應用程序中創建并發訪問控制的需求。

當 C 程序完成使用 Sensor 結構時，free（） 將內存返回到堆中。當帶有IMDS的代碼完成時，數據庫中的空間被放棄，事務結束，用于傳感器對象的內存返回到專用內存池。

eXtremeDB IMDS可能會內存不足，但這會產生“數據庫已滿”錯誤消息，應用程序可以處理該錯誤消息。相反，由 malloc（） 和 free（） 引起的內存碎片和泄漏可能會破壞整個系統的穩定性。IMDS提供了一種“幕后”工作的機制，通過使用多種底層分配器類型，以更高的效率和靈活性分配和釋放內存，避免malloc（）和free（）固有的風險。

但是，自定義內存管理器并不是IMDS所特有的。例如，用于管理傳感器網絡的現成代碼非常適合一種稱為塊分配器的自定義內存管理器。雖然離散傳感器值事先不知道，但這些值的大小是固定的（如 4 字節時間戳和 8 字節值），并且塊分配器擅長分配預定義大小的內存塊。基于堆棧的分配器對于任何計算需求都很有用，可以分為需要所有內存的第一階段和不再需要所有內存的第二階段。任何必須解析某些輸入流的程序都符合此描述。例如，通信監視程序可能會解析文本流（口語），構建令牌樹（單詞或短語），然后對其執行一些后處理。這種后處理可能是決定給定的單詞或短語是否與其上下文相關。

事實上，很難想象一種應用程序類型不會從面向其特定分配模式和挑戰的內存管理中受益。當然，自定義內存管理為已經復雜的軟件開發任務增加了另一個考慮因素。但是，進入安全關鍵領域的軟件工程師知道，與消費者或業務應用程序開發相比，需求和風險更高。編寫避免動態內存分配而是使用一個或多個自定義內存管理器的代碼不太方便。但它增加了安全性和穩定性，這是安全關鍵系統的工程師應該接受的權衡。

審核編輯：郭婷