內存泄漏經常出現(xiàn)在本地代碼中，特別是多線程和發(fā)生異常的情況下，這時候在delphi環(huán)境下，F(xiàn)astMM4就特別有用。 


FastMM4是非常高效可靠的內存管理器，用來替代久久不更新的borland內存管理器是最好的。地址：http:///projects/fastmm/ 


調試過程如下： 


1.打開FastMM4的調試功能，首先在自己的project里把FastMM4放在最前面，例如： 


  FastMM4, 
  Main in ‘Main.pas’ {MainForm}, 
再修改FastMM4Options.inc，打開全調試模式。例： 


{$define FullDebugMode} 


也可以在project中定義編譯常量：FullDebugMode。同時把FastMM_FullDebugMode.dll拷貝到編譯后生成的可執(zhí)行程序所­在目錄。 


再要打開內存泄漏報告：EnableMemoryLeakReporting。一般情況下是缺省打開的。 


這樣就打開了全調試模式，如果發(fā)生內存泄漏將會生成報告文件，如果在IDE運行的時候還會彈出一個對話框顯示。報告文件類似：kicoy_MemoryMana­ger_EventLog.txt 


2.報告文件由兩部分組成，并且是每次運行append。 


第一部分是泄漏的詳細內容，將每個沒釋放的內存塊詳細信息顯示出來。例： 


A memory block has been leaked. The size is: 28 
{一個28字節(jié)的內存塊在程序結束后沒有被釋放} 


{這個內存塊在分配的時候的調用堆棧，也就是Call 
Stack，可以清楚看出調用函數(shù)的次序。如果是系統(tǒng)dll則還有相應的函數(shù)名。} 
Stack trace of when this block was allocated (return addresses): 
4028E7 
4030EC 
406649 
412365 
41236E 
411DD3 
426B45 
427236 
42888C 
{這個內存類型，如果是字符串string或TObject繼承的對象則會顯示名稱。} 
The block is currently used for an object of class: Unknown 


{將內存塊頭256個字符顯示出現(xiàn)，作為內容提示。} 
Current memory dump of 256 bytes starting at pointer address 107BDD8: 


第二部分是總結性內容，例： 


{這個小型內存塊泄漏的報告，如果有大型內存塊泄漏則會加一行專門提示大型內存塊泄漏。} 
This application has leaked memory. The small block leaks are 
(excluding expected leaks registered by pointer): 


{21-28字節(jié)的內存塊泄漏，未知類型一個} 
21 - 28 bytes: Unknown x 1 


Note: Memory leak detail is logged to a text file in the same folder as 
this application. To disable this memory leak check, undefine 
“EnableMemoryLeakReporting”. 


有了這份報告只不過了解到內存泄漏存在，但是哪里沒釋放就還需要更進一步地調查。 


調查的目標有： 


1.內存塊分配在哪個函數(shù)里哪段代碼。 


這個在報告里可以結合內容和調用堆棧來看。前256個字節(jié)可以進行分析，推測分配者，調用堆棧就直接指出了分配函數(shù)，不過是一些地址，不能直接知道函數(shù)名和代碼­段。這時候就需要在delphi 
ide環(huán)境下查看二進制內存映像了，就是View CPU功能。 


在設定斷點并停下后，可以View CPU，在菜單View=>Debug 
Window=>CPU  快捷鍵：Ctrl+Alt+C 


View CPU Window： 


正中就是內存映像，而且源碼也相應地標注好了，左邊列的地址就是內存報告中的Call 
Stack中的地址，翻頁找到所對應的代碼就知道哪里分配內存了。 


2.檢查釋放內存的地方是否被調用，可以用日志或斷點來調試，如果壓根就沒有釋放內存那就補上代碼，如果有卻沒有執(zhí)行則檢查一下執(zhí)行條件是否正確，如果斷點沒起­作用很可能是因為代碼永遠不會被執(zhí)行（死代碼）。 


這要靠經驗和調試，基本上借助IDE和內存報告就可以很好地防止內存泄漏。同時要加強測試用例，爭取在測試用例中能遍歷到所有的代碼和大部分關鍵功能，這樣內存­泄漏報告就會更準確一點。 


fastmm每次在程序關閉后就會根據(jù)情況生成內存泄漏報告，如果沒有彈出內存泄漏警告則恭喜你，內存管得很好。 


現(xiàn)在總算不用羨慕虛擬機代碼自動回收內存了，本地代碼的內存管理也不是兩眼一抹黑了，這是可以精確控制的，一切盡在掌握中。 


另： 


1.內存管理不是GC自動回收內存，而是檢查是否有泄漏。 


2.windows系統(tǒng)的內存泄漏是無法檢查的，僅限于應用程序內部，不過檢查出系統(tǒng)泄漏也沒辦法，只能等更新了。 


3.檢查泄漏后要自己去檢查代碼補齊內存釋放，報告并不能做這事。