使用概要分析器來檢測內(nèi)存泄漏

　　在此用例中，將運行Chapter 72 Using the Flex Profiler項目的源代碼目錄中可用的MemoryLeak.mxml應(yīng)用程序。通過在概要分析會話里啟動這一應(yīng)用程序來開始使用這個案例。
　　（1）當(dāng)啟動概要分析會話的時候請確保Enable memory profiling復(fù)選框、Watch live memory data復(fù)選框和Generate object allocation stack traces復(fù)選框都被選中。
　　（2）使應(yīng)用程序運行一分鐘，觀察Memory Usage圖。它開始看上去會有點像。內(nèi)存泄露的第一個警告信號發(fā)生在Current Memory總量隨著Peak Memory總量一起上升，而沒有穩(wěn)定跡象時。
　?。?）既然可以查看泄漏了，就看一看Live Objects視圖。觀察Live Objects視圖幾分鐘。所尋找的是活動對象實例數(shù)在繼續(xù)持續(xù)增長的對象，這個數(shù)量與累積實例數(shù)保持一致。例如，可以看到LeakyTitleWindow有135個累積實例和135個實例。與此同時，有135個Popup Data累積實例，并且只有30個活動對象實例。這意味著，可能PoUpData正在正確地回收垃圾，而LeakyTitleWindow沒有。
　?。?）由于LeakyTitleWindow是可疑的，因此拍攝1張內(nèi)存快照并打開它。因為這看上去類似于Live Objects視圖，所以這里沒有提供屏幕截圖。
　　（5）雙擊內(nèi)存快照中的LeakyTitleWindow來打開Object References視圖。首先看到的是LeakyTitleWindow的第一個對象實例有22個反向引用。展開第一個LeakyTitleWindow反向引用的樹。如果查看前兩個反向引用，就會發(fā)現(xiàn)它們源于Leaky Title Window類本身。這是重要的一點：并不是顯示的所有對象引用都將導(dǎo)致泄漏。
　　（6）按列表中從上到下的方式開始工作，展開反向引用來查看它們什么時候終止。如果展開標(biāo)記為“Function”的反向引用，會看到圖中所示的一個反向引用。查看這個特別的后引用鏈會發(fā)現(xiàn)它最終回到同一個LeaktTitleWindow實例。換句話說，一旦Leaky Title Window實例不再可達(dá)，這個反向應(yīng)用鏈將對垃圾回收期就是無關(guān)緊要的，于是不會再被關(guān)。
　?。?）返回并再一次選擇Function反向引用?？匆豢从疫叺腁llocation trace窗格。正如您所看到的，這個函數(shù)在LeakyTitleWindow的onCreationCompleteO方法中創(chuàng)建。這為我們提供了代碼里堵塞泄漏的起點。
　?。?）更改代碼后，運行另一個內(nèi)存概要會話。在等待一小會兒后將在Memory Usage圖和Live Object視圖上看到類似圖。