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

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

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

　　在Flex應(yīng)用開發(fā)過程中，主要存在兩種泄露情況：

• 顯式引用：由于表達式賦值或者對象參數(shù)傳遞等原因，已經(jīng)“無用”的對象被保持引用，導(dǎo)致虛擬機無法正常回收。
• 隱式引用：由于事件監(jiān)聽注冊等操作，導(dǎo)致對象之間存在引用，產(chǎn)生泄露風(fēng)險。

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

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

　　當(dāng)然，凡事應(yīng)以“預(yù)防為主”，所以作者最后總結(jié)了幾點開發(fā)建議：

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

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

it知識庫：如何分析Flex應(yīng)用的內(nèi)存泄露問題？，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。