如何分析 Flex 应用的内存泄露问题？

随着 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 没有被其他对象引用，垃圾回收器就把它标记为“无效”进而回收，从而避免内存泄露。

内存泄露一直是开发社区普遍关注的问题，即使在虚拟机时代，某些泄露问题仍然值得大家讨论和研究。