在中框架自带一个【部门管理】模块，其中【功能权限】设置时用了DataGrid，并且使用了DataGrid的分组功能，UI如下：

用户反应在使用过程中，来回切换【业务对象】进行功能权限设置时，切换多次后会发现允许速度慢的和蜗牛一样。既然这么明显，打开任务管理器，未设置功能权限时内存消耗如下图为50496：

来回切换20次后，发现内存飚升为94580，如果模块负责一些的话，估计会涨得更多：

为了找到具体是哪个类的泄露，我使用了ANTS Memory Profiler 5进行跟踪，发现点击多少次后就回出现多少个BoInfoOperationSelected[]对象

随便找一个对象，查看对象图，发现都是DataGridRow对象：

网上google一下，找到了DataGrid开源项目中的一个问题：

里面解释了一下可能的原因：

It looks like in Grouping mode, the row's row.Tracker.StopTracking method is never called, because ClearContainerForItemOverride is never called by the WPF ItemsControl implementation. The result is that you just end up with an ever growing chain of ContainerTracking instances.

{zh1}还附上一句：

Note that Microsoft has acknowledged that this is a bug, being fixed in .NET 4.0. No fix for .NET 3.5 at this time.

把OpenExpressApp更新到Net4后，发现内存还真的不上去了，狂切换业务对象后再用ANTS Memory Profiler 5跟踪一下对象看看，发现就两个，内存泄露问题也没有了！

这只是WPF内存泄露的一个地方，在中专门对WPF内存泄露问题进行了一些描述，估计后续会把Net4的内容加上。

欢迎转载，转载请注明：转载自 [ ]