没有代码手动创建控件 - 一切都是通过数据绑定完成的。
为什么我会看到这种行为？我该怎么办才能修复它？请帮忙！
更新： 我发现问题不是内存泄漏。这里的问题是列表框正在创建对象以显示员工的图像，并且在listboxitem离开窗口后不会为垃圾收集器发布。 CleanUpVirtualizedItem事件按我的预期发生，但内存仍未释放。有什么想法吗？
答案 0 :(得分：6)
冒着油腻的风险，你有内存泄漏。为什么不尝试像ANTS *这样的工具来追踪它。他们有免费试用，我从未使用它，但它有良好的声誉。
*可以使用其他分析工具。
如果您不想使用其他工具，可以尝试在每次创建类时增加静态成员，并在每次处理实例时减少静态成员。这将帮助您跟踪未被正确销毁的实例。
答案 1 :(得分：3)
LOL 200MB启动和1GB运行..对x64的更常见的惩罚（你需要它的膨胀）是启动时大约64MB的惩罚和半高级功能的另一个120MB，这仍然是巨大的，当然GC将继续增加更多。
这必须立即杀死CPU及其周围的所有外围设备。现在想象一切都在那个，所有应用程序，以及整个操作系统和堆栈上运行（因为VS2010肯定会尝试朝这个方向移动）。
我会说：欢迎使用现代的英国式臃肿狂热方式及其易用性。无论你做什么，你都会花更多的时间找到解决方法，然后遵循一些“通用”框架，以快速，酷，风格和可定制的应用程序。当然WPF在纸面上是好的，但在任何实际使用中浪费资源（大量的资源和陡峭的学习曲线）。
他们说它过去了，现在仍然是未来（JDK应用也是如此普遍）。
简单地说N.U.T.S +最优秀的例子，它不是关于速度（因为CLR防御者将通过简单的例子进入）托管代码。它与每个GC和对象根环境一样，具有巨大的可伸缩性和机器清除能力。
投下来......去找门徒，你知道你想要。
（并写信给奥巴马反对二氧化碳排放不会发生;如果这个潮流继续前进，可能会乘以1003120x。即使是Cray Jaguar也不会在未来20年内随时运行这种运营环境）。答案 2 :(得分：3)
您可以使用
Optimizing WPF Application Performance
类似的问题困扰着我...... (something like)
在应用程序启动时，我查询数据库并检索要在ListBox中显示的所有员工和相关信息。这一直保存在记忆中。
您可以修改代码以遵循WPF: Data Virtualization
答案 3 :(得分：1)
它似乎真的是内存泄漏。可能，DataTemplate中的一些UI元素会保留对其他对象的引用，即使在UI元素被销毁时也应该保持活动状态。
Image控件可能存在一些内存泄漏。尝试从模板中删除它并查看结果。此外，您是否订阅了控件'加载事件或类似事件中的任何事件？
只是猜测一下......正如人们已经在这里说过的那样，你可能真的想用性能和内存分析器来看你的应用程序。
答案 4 :(得分：0)
我注意到在看似无害的情况下WPF和.NET 3.5 SP1 w.r.t内存问题存在一些问题。
我确实找到了一些资源，但我不确定它们会对你有所帮助：
http://blog.ramondeklein.nl/?p=58
该博客文章描述了
时的情况
- 样式在应用程序的ResourceDictionary中定义。
- 该样式使用使用媒体效果的控件模板（即 DropShadowEffect）。
- 应使用StaticResource
引用媒体效果
简而言之，我认为您的解决方案是确保任何媒体效果（阴影等）都使用静态资源。
答案 5 :(得分：0)
对我有很大帮助的一件事是使用包装Stream类的类。详细解释了here，我确实通过使用这种方法节省了大量内存。 WPF确实保留了对每个图片的底层byte []和流的引用。