相信很多人都有想過這個問題：到底要不要用malloc來配置記憶體呢？要？或不要？都有人贊成與反對。我剛好腦袋突然閃過一個想法，可以回答這個問題。
大家都知道malloc是配置記憶體在heap中，一定要有一個free來將記憶體釋放。但常常都會聽到memory leak這個惡名昭彰的後果。除非就是在程式一開始的時候就要妥善安排一個介面來保證讓malloc與free成對出現。但是有這麼多的人要coding，有這麼多人的要寫thread，最後還是有可能會漏掉。除非你們的team，有採用更好的處理方式以及更嚴謹的code review流程，否則這個夢饜是如影隨形的。
我過去參予了一個DVR的案子，覺得這個方法不錯，這也是某一個老大規定這麼做的。規定其實很簡單，就是專案一開始就不要使用malloc。我覺得有點道理，因為在嵌入式系統的專案中，每一個功能都是需要能運作，幾乎沒有什麼"這個程式即將關閉"的介面讓使用者能夠選擇是否繼續執行。既然每個功能都要保證能動，那記憶體一定要夠執行所有工作才行。
這時，誓死使用malloc的看官一定已經要轉台了。別急，其實這麼做是有道理的。"專案一開始"不使用malloc，這讓我想到用Continue Integration(CI)的精神來解釋。
專案一開始的程式，一定是相對穩定的。如果您不懂我的意思，我舉個極端例子，當你一開始從main開始的時候，裡面只有一行printf("foo");。請問，這樣子會有bug存在嗎？
好，CI的精神就是靠著連續地整合，讓版本之間都彼此有關聯，如果一有問題就能夠藉由每次的版本來找出問題所在。如果一開始就不使用malloc，是不是整合到最後的版本，也都不可能會有memory leak，對吧？
所以，在你的run time時期的記憶體大小還許可的情況下，都不要開始使用malloc。讓你開心地解掉bug，而且完全不需去考慮某個解不掉的bug是否為memory leak的問題。直到你的穩定版本釋出後，如果記憶體真的不足了，或是老闆想要cost down，再考慮以"穩定"的版本去使用malloc，利用CI甚至Unit Test，來讓你的版本一直穩定下去。
但如果平台記憶體非常的少，一定要使用malloc才能繼續開發下去，那就要另尋他法了...。
沒有留言:
張貼留言