隨著Web 2.0技術的深入發展，Flex成為很多企業級應用的前端展示層。雖然Flex應用運行于FlashPalyer虛擬機之上，但是開發人員仍然會遇到一些內存泄露問題，那么如何分析和定位根源呢？IBM工程師王鵬最近撰文詳細描述了檢測Flex應用內存泄露的方方面面。

　　Flex采用ActionScript語言作為腳本語言，運行在FlashPlayer虛擬機之上，其垃圾回收機制概括如下：

Flex應用的對象在內存中被映射成樹形結構。這很好理解，每個Flex應用總有一個Application的入口被稱為根節點（Root），垃圾收集器從根節點開始遍歷每個對象，對可達對象標記為“有效”（有一種例外就是弱引用）。而在這棵樹之外的孤島對象或者由于循環引用形成的孤島對象集合被標記為“無效”，垃圾收集器會在合適的時間銷毀這些無效對象，完成一次垃圾收集。而垃圾收集器是運行在虛擬機中的一個低優先級的守護進程，為了不影響性能，它只在必要的時候才運行。例如在向操作系統申請新內存空間的時候，發生異常的時候等等，因此內存并不是實時回收的。

　　在Flex應用開發過程中，主要存在兩種泄露情況：

• 顯式引用：由于表達式賦值或者對象參數傳遞等原因，已經“無用”的對象被保持引用，導致虛擬機無法正常回收。
• 隱式引用：由于事件監聽注冊等操作，導致對象之間存在引用，產生泄露風險。

　　針對以上泄露問題，文章建議大家采用Adobe公司在Flex Builder 3中提供的Profiler工具來分析和定位泄露根源：

• 內存快照法：通過對于相同操作做反復內存快照（Profiler工具支持）比較，找出持續增加的對象實例，就可能發現泄露根源。
• 游蕩對象法：當Flex應用特別復雜時，可以利用Profiler 工具中的“Find Loitoring Objects”查找游蕩對象，比較不同狀態轉換之間的對象變化，可能會發現泄露的對象。

　　當然，凡事應以“預防為主”，所以作者最后總結了幾點開發建議：

1. 對于顯式引用，要盡量減少對臨時對象的引用，尤其是全局變量、靜態變量、使用單例模式創建的變量對臨時變量的引用。這些變量包含stage、systemManager、application、MVC框架中Model和Controller，還有以Manager命名的對象等等。另外，臨時變量本身要盡量做到高內聚性，對象內部盡量減少對外部對象尤其是全局對象的依賴。
2. 對于隱式引用，使用弱引用方式注冊事件監聽器，將最后一個參數useWeakReference設置為true：a.addEventListener("Leak", b.leakHandler, false, 0, true); 這樣做的結果是垃圾回收器在做標記時，會忽略a對于b的引用，如果b沒有被其他對象引用，垃圾回收器就把它標記為“無效”進而回收，從而避免內存泄露。

　　內存泄露一直是開發社區普遍關注的問題，即使在虛擬機時代，某些泄露問題仍然值得大家討論和研究。