由于語言在自動內存管理上的欠缺，C/C++在內存管理上從來都是需要程序員小心處理的一個方面，當項目代碼上了一定規模，內存消耗和泄漏就會成為程序穩定運行的第一大敵。如果不在項目之初就建立內存管理和泄漏檢測機制，后面蛋疼的問題就會接踵而來。這篇文章著重討論內存泄漏檢測，而內存管理與具體項目類型關系密切，后面有時間我會著重游戲項目來討論。
內存泄漏檢測的基本步驟是：1）包裝（重載）內存分配/釋放API；2）進行內存分配時記下相關信息：地址、大小、調用棧；3）釋放時清除之前記錄的對應信息；4）程序退出時（確保在所有內存釋放操作完成之后），輸出剩下的記錄。其中，對進行分配操作是的調用?；厮菔莻€重點信息，它能夠幫助我們找出內存泄漏代碼。
Windows中的Dbghelp庫提供了豐富的調試API。StackWalk應該是進行?；厮葑钪苯拥囊环N接口了，但是它不夠快。如果能先記錄下調用棧上的CALL指令地址，然后在輸出日志時解析出符號，將會大大降低檢測機制對程序本身性能的影響。Dbghelp庫中提供了Sym*FromAddr系列API，可以通過指令地址獲取函數符號，那么剩下的就是如何記錄指令地址的問題了。從網上借了一張x86調用棧示意圖，如下：
_thumb.png "Image(12)")
從圖中可以看出，Callee的EBP始終指向Caller的EBP，EBP下面是指向Caller下一條指令（注意x86體系下棧的增長方向是小地址），因此通過EBP就可以回溯整個調用棧了。通過下面代碼可以實現此功能：
_thumb.png "Image(13)")
宏參數frame是個void*指針數組，數組的大小取決于想要回溯的棧深度。內存分配和回收的包裝代碼如下：
_thumb.png "Image(14)")
我們看到，內存管理系統內部終究還是要使用語言提供的內存分配/釋放API，只要配對實現了分配與釋放管理，系統內部的無泄漏是很容易保證的。在這里著重講解原理，就不重載new/delete operator了。最后看一下調用棧函數符號的回溯代碼：
_thumb.png "Image(15)")
我們用下面代碼做測試用例：
_thumb.png "Image(16)")
泄漏檢測結果：
_thumb.png "Image(17)")
參考：
[1] Using DbgHelp
[2] Intel x86 Function-call Conventions - Assembly View