在軟體行業，模組化程式設計早已深入人心，通過模組的劃分能有效地減小軟體系統的複雜度，模組化其實就是將系統「分而治之」的方法。在嵌入式系統中，每乙個模組存在初始化函式相對比較的普遍，但是並不是每乙個模組都存在乙個終止化函式，相反，有可能整個系統根本就沒有終止化函式。之所以出現這種現象，這與嵌入式系統的特點有關。與桌面系統上的軟體不同的是，由於整個嵌入式裝置就只有乙個應用軟體在執行，因此，對軟體的關閉或重啟大都是通過開、關裝置電源或按下重啟按鈕這種「粗暴的」方式來完成的。久而久之大家都就習慣了，進而將設計模組的終止化函式當作了多餘。
從完整性的角度來看，乙個模組如果存在初始化的過程，就理應提供終止化函式以實現模組的終止，當然設計終止化函式不應當只是為了感覺更好，而應當還有其它的目的和內涵，那是什麼呢？為每乙個模組設計終止化函式的目的是為了提供一種「優雅地」關機或重啟系統的手段，而其進一步的內涵是，通過這種方式將提供乙個檢測系統資源洩漏的機會。
現在，讓我們以記憶體資源為例來分析採用優雅關機的好處。在嵌入式系統中，由於不考慮各模組終止化函式的設計，造成從堆中分配出來的具有全域性生命週期的內存在系統系統關閉時不存在釋放操作。如此一來，在系統的關閉過程中不容易發現記憶體洩露問題，因為分不清哪些記憶體是系統執行期間必須永久持有的（即非記憶體洩漏），哪些又是動態分配但沒有釋放的（即記憶體洩漏）。假設使用記憶體的每個模組都提供了終止化函式，且系統提供一種方式（比如通過命令列）以觸發優雅關機流程，其結果就是導致每乙個模組的終止化函式被有序地呼叫。顯然，那些具有全域性生命週期的內存在每乙個模組的終止化函式中都應進行釋放操作，最終在優雅關機的過程中也會被釋放。進一步，在記憶體管理模組的終止化函式中（注意：前面講的是使用記憶體的模組，而現在講的是管理記憶體的模組），可以設計成檢測當前是否仍有記憶體被分配出去了，如果有，則很有可能存在記憶體洩漏。如果記憶體管理模組被設計成能記錄所有已分配出去記憶體的詳細資訊的話（指記憶體的分配是在哪乙個檔案的哪一行），在發現仍有記憶體沒有釋放的話，將這些相關資訊通過某種方式輸出將有助於發現記憶體洩漏點。當然，這裡有乙個很重要的前提假設，那就是在優雅關機的過程中使用記憶體的模組的終止化函式必須在記憶體管理模組的終止化函式之前被呼叫，這一點可以通過一定的模組管理輕鬆做到。
記憶體資源可以通過優雅關機的方式發現洩漏，其它的資源同樣可以採用這一方法發現洩漏。比如，在定時器管理模組的終止化函式中可以檢查是否所有的定時器都已**了，等等。有了優雅關機的方式以後，並不妨礙我們採用「粗暴的」方式進行系統的關閉或重啟，但它的存在卻提供了一種需要時能被使用以輔助發現潛在的資源洩漏問題。
設計模組的終止化函式需要一點工作量，但這點工作量是可以承受的，而且也應當承擔它。與潛在的資源洩漏相比，花上這些時間是值得的。另外，設計得好的系統，不只是簡單地提供初始化和終止化函式，還應當站在整個系統的角度設計一定的機制去管理系統中模組的初始化和終止化。
SSRS日期引數的初始化 設計 SQL
1 本月第一天 dateserial year today month today 1 2 本月最後一天 dateadd d 1,dateadd m 1,dateserial year today month today 1 3 上月第一天 dateadd m 1,dateserial year t...
linux 裝置驅動之模組的初始化和退出
include 模組的初始化和退出檔案 include init 和 exit 資料段 模組安裝函式 static int init drive test init void 模組解除安裝函式 static void exit drive test exit void module init dri...
系統架構設計模組拆分維度和原則
在我們從零開始做乙個新系統的時候，會首先進行系統功能模組架構設計，那麼是直接做乙個大而全的垂直的mvc系統，使用乙個war包進行發布管理，還是需要按一些規則進行模組拆分，設計成soa或者微服務系統比較好呢？這個筆者認為需要依據專案具有什麼樣的人力物力條件以及專案需要支撐多少使用者量和交易量為基礎。乙...