內存泄漏的問題，在
百度是遇到最多的，阿里相對少點。與內存泄漏斗爭了很久，我總結下常用的一些有效
測試方法吧。
1、valgrind，這是非常好用的工具，雖然參數很多，輸出結果較多，但是只要認真看下，就很容易發現問題，報告是很詳細的，不要被嚇倒。valgrind檢測的內存泄漏是非常準的，可以精確定位到代碼行甚至是變量。valgrind基于valginrd core框架，這是個非常有強大的框架，他的作用不僅僅在于檢測內存泄漏的，強烈建議測試新手通讀下全部的文檔。valgind自己也會有誤報和漏報，所有具體場景需要具體分析。報告中一旦出現definitely lost的標記，就表示一定會有內存泄漏，泄漏的字節數也會報告出來，可以根據泄漏的內存大小和請求次數計算出到底是那個變量沒有釋放。
2、利用pmap+gdb，pmap可以列出特定進程的所有內存分配的地址和大小，通過gdb就可以直接看這些地址屬于什么變量，通過統計這些內存地址的大小，就可以很容易的發現問題。利用自動化的gdb調試工具也可以很方便的定位。
3、其他的還包括memprof、商業工具Purify
IBM出品，官方宣傳說的不錯，但是這種不開放的技術，在業界得不到認可，國內大公司一般那都不用，只有人傻錢多的公司在用。
4、利用一些trace工具，比如ptrace，strace之類的工具，這些trace工具會追蹤特定的api，只需要統計malloc和free的調用次數就可以簡單的發現是否有泄漏，但是無法定位代碼行。另外還有一個更高深的工具，SystemTap，這個在國內應用還不多，但是非常厲害，可以方便hook程序的關鍵邏輯并插入探針。從而可以方便的檢測內存泄漏。Systemtap目前還不通用，而且安裝復雜，暫時不推薦使用，可以關注下，過幾年可能會大規模應用。
valgrind是首選，因為他的設計就是為了解決所有的c++的內存問題。一些valgrind不能簡單發現的，我一般會review代碼，然后通過gdb自動調試技術來發現問題。通過valgrind+gdb，可以解決所有的內存泄漏。
另外，內存的泄漏也并不完全是沒有及時的free，還有可能是其他的原因，比如設計問題等。需要靠一定的開發經驗判斷。
要盡量把靜態測試和動態測試盡早的加入到持續集成中，以盡早的發現問題，不然一旦代碼復雜，追查的成本就會增大。