在使用OpenExpressApp进行WPF应用开发过程中遇到多个内存泄漏的地方，昨天在WPF不明内存泄露已解决，白头发也没了中讲到了如何解决由于属性跟踪事件强引用导致的内存泄漏问题，本篇介绍一下由于CollectionViewSource.GetDefaultView导致的内存泄漏问题。
发现问题
还是昨天 WPF不明内存泄露已解决，白头发也没了中说的场景，关闭模块后仍旧保留了对象的引用，ANTS Memory Profiler 5查看对象引用图如下
分析问题
使用Scitech memory profiler查看对象引用路径，
查看ViewRecord对象的调用堆栈，如下：
查看后发现调用了一个CacheView方法，估计是把这个对象缓存起来了，使用Reflector查看源码，
CollectionViewSource.GetDefaultView:
{
ViewRecord record = DataBindEngine.CurrentDataBindEngine.GetViewRecord(source, DefaultSource, null , createView);
return (CollectionView) record.View;
}
其中DataBindEngine.CurrentDataBindEngine是一个静态单例对象
{
get
{
if (_currentEngine == null )
{
_currentEngine = new DataBindEngine();
}
return _currentEngine;
}
}
内部调用了CacheView把对象缓存在单例DataBindEngine的ViewManager对象中。看了一下代码，没有看到如何清除缓存的地方（不知道有谁知道如何在程序中清除这个缓存？）
解决问题
查看GetDefaultCollectionView代码可以发现，其实内部它是根据传入对象的类型来决定生成一个什么CollectionView对象，由于我这边传入的肯定是IList，所以我修改GetDefaultView代码为直接使用ListCollectionView对象，修改代码如下：
//var collectionView = CollectionViewSource.GetDefaultView(viewData); //inter call CacheView make memory leak
ListCollectionView collectionView = new ListCollectionView(viewData);
修改后再使用内存泄漏工具查找对象，这时你就再也找不到对象了：）
另：以上是我的一个分析以及解决办法，虽然有事最好的解决办法就是不用它，但是总感觉使用CollectionViewSource.GetDefaultView不应该产生这个问题，否则谁还敢用，可能是我其它原因导致但我还为发现，上网搜索了也没有查到什么有用资料，不知道谁有更好的办法，请多指教！
本文转自 jingen_zhou 51CTO博客，原文链接：http://blog.51cto.com/zhoujg/517969，如需转载请自行联系原作者
