檢測記憶體流失

網上搜尋了一下，發現檢測記憶體流失的工具還是很多的。下面是從網上找到的一些材料，主要是在linux系統中記憶體流失的檢測方法。

（1）什麼是記憶體記憶體流失？
　　在此，談論的是程式設計中記憶體流失和錯誤的問題，不過，並不是所有的程式都有這一問題。首先，泄漏等一些記憶體方面的問題在有的程式語言中是不容易發生的。這些程式語言一般都認為記憶體管理太重要了，所以不能由程式員來處理，最好還是由程式語言設計者來處理這些問題，這樣的語言有Perl、Java等等。 　　
　　然而，在一些語言(最典型的就是C和C++)中，程式語言的設計者也認為記憶體管理太重要，但必需由開發人員自己來處理。記憶體流失指的是程式員動態分配了記憶體，但是在使用完成後卻忘了將其釋放。除了記憶體流失以外，在開發人員自己管理記憶體的開發中，緩衝溢出、懸擺指標等其它一些記憶體的問題也時有發生。 　　　　
(2) 問題緣何產生
　　為了讓程式能夠處理在編譯時間無法預知的資料佔用記憶體的大小，所以程式必需要從作業系統即時地申請記憶體，這就是所謂的動態記憶體。這時候，就會出現程式申請到記憶體塊並且使用完成後，沒有將其歸還給作業系統的錯誤。更糟的情況是所擷取的記憶體塊的地址丟失，從而系統無法繼續識別、定位該記憶體塊。還有其它的問題，比如試圖訪問已經釋放的指標(懸擺指標)，再如訪問已經被使用了的記憶體(記憶體溢出)的問題。
（3）後果不容忽視　　
　　對於那些不常駐記憶體的程式來說，由於執行過程很短，所以即使有漏洞可能也不會導致特別嚴重的後果。不過對於一些常駐記憶體的程式(比如Web伺服器Apache)來說，如果出現這樣的問題，後果將非常嚴重。因為有問題的程式會不斷地向系統申請記憶體，並且不釋放記憶體，最終可能導致系統記憶體耗盡而導致系統崩潰。此外，存在記憶體流失問題的程式除了會佔用更多的記憶體外，還會使程式的效能急劇下降。對於伺服器而言，如果出現這種情況，即使系統不崩潰，也會嚴重影響使用。
　　懸擺指標會導致一些潛在的隱患，並且這些隱患不容易暴發。它非常不明顯，因此很難被發現。在這三種存在的問題形式中，緩衝溢出可能是最危險的。事實上，它可能會導致很多安全性方面的問題(一個安全的程式包含很多要素，但是最重要的莫過於小心使用記憶體)。正如上面所述，有時也會發生同一記憶體塊被多次返還給系統的問題，這顯然也是程式設計上的錯誤。一個程式員非常希望知道在程式啟動並執行過程中，使用記憶體的情況，從而能夠發現並且修正問題。
（4）如何處理　　　　
　　現在已經有了一些即時監測記憶體問題的技術。記憶體流失問題可以通過定時地終止和重啟有問題的程式來發現和解決。在比較新的Linux核心版本中，有一種名為OOM(Out Of Memory )殺手的演算法，它可以在必要時選擇執行Killed等程式。懸擺指標可以通過定期對所有已經返還給系統的記憶體置零來解決。解決記憶體溢出問題的方法則多種多樣。 　　
　　事實上，在程式運行時來解決這些問題，顯然要麻煩得多，所以我們希望能夠在開發程式時就發現並解決這些問題。下面介紹一些可用的自由軟體。

	記憶體回收行程(GC)	Memprof	Valgrind
簡介	在GCC工具包中，有一個"記憶體回收行程(GC)"，它可以輕鬆檢測並且修正很多的記憶體問題。目前該項目由HP的Hans-J.Boehm負責。	Memprof是一個非常具有吸引力且非常便於使用的軟體，它由Red Hat的Owen Talyor創立。這個工具是用於GNOME前端的Boehm-Demers-Weiser記憶體回收行程。	Valgrind是一個致力於解決所有記憶體問題的程式，而記憶體流失只不過是其中的問題之一而已。該工具的開發人員是Julian Seward(以Bzip2和Cacheprof而聞名)。該工具宣稱自己"是專門致力於解決x86 Linux中開放原始碼的記憶體問題"，事實上，它的確做到了自己的宣言。此外，它還可以描述CPU緩衝的使用方式，不過這一功能並不常用。
使用的技術	GC使用的是名為Boehm-Demers-Weiser的可以持續跟蹤記憶體定位的技術。它的演算法通過使用標準的記憶體定位函數來實現。程式使用這些函數進行編譯，然後執行，演算法就會剖析器的操作。該演算法非常著名並且比較容易理解，不會導致問題或者對程式有任何幹擾。	就其核心技術來說，Memprof和上面提到的GC沒有什麼本質的不同。不過在實現這一功能時，它是從程式中捕獲所有的記憶體請示並且即時將其重定位到記憶體回收行程。	在這個程式中使用的技術非常複雜，不過其文檔非常豐富和完整(http://developer.kde.org/~sewardj/docs/techdocs.html)。程式分配的每一位元組的記憶體都被一個有九位的狀況字跟蹤，其目的是用於識別其意圖。這種做法大大加重了系統的負擔。
效能	該工具有很好的效能，故可以有效提高程式效率。其代碼非常少並且可以直接在GCC中使用。	該工具的效能非常不錯，其GUI設計得也不錯。這個工具直接就可以執行，並且其工作起來無需對原始碼進行任何修改。在程式執行時，這個工具會以圖形化的方式顯示記憶體的使用方式，以協助你瞭解程式運行過程中記憶體的申請情況	這個工具是我們這兒介紹的三款中效能最差的一個，原因是顯而易見的。該工具提供的資訊細節是三個工具中最豐富的，因而速度也是最慢的。除了一些常見的問題外，該工具還可以發現記憶體其它的一些問題，甚至一些POSIX線程方面的問題。緩衝的資訊對於大部分程式來說似乎沒有必要，不過它是一個查看程式效能的很好方式。對於Valgrind來說，值得一提的就是其開發速度非常快，其開發社團也非常活躍。事實上，在Valgrind的首頁上作者甚至有一句話："如果你在使用Valgrind過程中有任何問題，請不要介意，給我發郵件吧"。
缺點	該工具沒有介面，使用起來比較困難，所以要想掌握它還是要花一些工夫的。一些現有的程式很有可能無法使用這個編輯器進行配置。此外，為了讓所有的調用能被捕獲，所有的記憶體調用(比如malloc()和free())都必須要使用由GC提供的相應函數來代替。我們也可以使用宏來完成這一工作，但還是覺得不夠靈活。	該工具目前只能運行於x86和PPC體繫結構之上的Linux系統之中。如果你需要用於其它的平台，應該想想使用其它的工具。該工具不是GTK應用程式，所以需要一個完整的GNOME環境。這樣就使得其不能靈活用於所有的地方。此外，該工具的開發工作進展得也比較緩慢(現在是0.4.1版)。	不過，該工具是專門用於x86的。其介面是純命令列方式，但是其可用性非常好。該工具可以直接在二進位下運行，所以在使用時並不需要對其進行重新編譯。不過要熟練掌握它，還是需要使用者進行一番努力的。此外，雖然該工具曾經使用於Mozilla、OpenOffice等一些大的線程程式，但該工具對線程的支援並不完善。我想如果該工具要是有一個GUI介面，將會贏得更多人的青睞。
結論	如果你希望能夠有跨平台(體繫結構、作業系統)的解決方案，那麼就是它了。	如果你喜歡GUI工具並且不介意只能用於Linux以及GNOME之下，該工具應該可以說是非常不錯。	如果你使用x86，對自己的代碼非常瞭解並且不介意使用命令列方式，那麼這個程式將是你的至愛。

　
 

　結論：另外還有一些其他的工具，可在下面網站中找到很多檢測記憶體錯誤的工具：http://www.sslug.dk/emailarkiv/bog/2001_08/msg00030.html。此外，還有一些商業工具，比如Purify、Geodesic等。在此就不詳細介紹。