使用概要分析器来检测内存泄漏

　　在此用例中，将运行Chapter 72 Using the Flex Profiler项目的源代码目录中可用的MemoryLeak.mxml应用程序。通过在概要分析会话里启动这一应用程序来开始使用这个案例。
　　（1）当启动概要分析会话的时候请确保Enable memory profiling复选框、Watch live memory data复选框和Generate object allocation stack traces复选框都被选中。
　　（2）使应用程序运行一分钟，观察Memory Usage图。它开始看上去会有点像。内存泄露的第一个警告信号发生在Current Memory总量随着Peak Memory总量一起上升，而没有稳定迹象时。
　　（3）既然可以查看泄漏了，就看一看Live Objects视图。观察Live Objects视图几分钟。所寻找的是活动对象实例数在继续持续增长的对象，这个数量与累积实例数保持一致。例如，可以看到LeakyTitleWindow有135个累积实例和135个实例。与此同时，有135个Popup Data累积实例，并且只有30个活动对象实例。这意味着，可能PoUpData正在正确地回收垃圾，而LeakyTitleWindow没有。
　　（4）由于LeakyTitleWindow是可疑的，因此拍摄1张内存快照并打开它。因为这看上去类似于Live Objects视图，所以这里没有提供屏幕截图。
　　（5）双击内存快照中的LeakyTitleWindow来打开Object References视图。首先看到的是LeakyTitleWindow的第一个对象实例有22个反向引用。展开第一个LeakyTitleWindow反向引用的树。如果查看前两个反向引用，就会发现它们源于Leaky Title Window类本身。这是重要的一点：并不是显示的所有对象引用都将导致泄漏。
　　（6）按列表中从上到下的方式开始工作，展开反向引用来查看它们什么时候终止。如果展开标记为“Function”的反向引用，会看到图中所示的一个反向引用。查看这个特别的后引用链会发现它最终回到同一个LeaktTitleWindow实例。换句话说，一旦Leaky Title Window实例不再可达，这个反向应用链将对垃圾回收期就是无关紧要的，于是不会再被关。
　　（7）返回并再一次选择Function反向引用。看一看右边的Allocation trace窗格。正如您所看到的，这个函数在LeakyTitleWindow的onCreationCompleteO方法中创建。这为我们提供了代码里堵塞泄漏的起点。
　　（8）更改代码后，运行另一个内存概要会话。在等待一小会儿后将在Memory Usage图和Live Object视图上看到类似图。