WPF DataBinding中的内存泄漏 [英] Memory leak in WPF DataBinding

问题描述

您好，



我在WPF中创建了一个应用程序，其中有一个用于添加/编辑客户信息的表单。当在添加模式窗口打开时，它显示一个空白文本框，在编辑模式下，文本框将包含来自数据库的信息。





我正在使用绑定功能如下。

Hello,

I have created a application in the WPF in which I have a form for add/edit customer information. When in add mode window opens, it shows a blank textbox and in edit mode textbox will contain information from database.


I am using binding functionality like below.

<Grid x:Name="MainGrid" DataContext="{Binding CurrentCustomer,Mode=TwoWay}" >
	<TextBox x:Name="txtCustomerName" Text="{Binding CustomerName,UpdateSourceTrigger=PropertyChanged,ValidatesOnDataErrors=True}"></TextBox>
	<TextBox x:Name="txtCustomerAddress" Text="{Binding Address,UpdateSourceTrigger=PropertyChanged,ValidatesOnDataErrors=True}"></TextBox>
</Grid>

这里 CurrentCustomer 是对象属性类客户



以下是客户类的一个样本

Here CurrentCustomer is the object of the property class Customer

Following is one sample of the Customer class

public class Customer 
{

	private string customerName;
	public string CustomerName
	{
		get 
		{
			return this.customerName; 
		}

		set 
		{
			this.customerName = value;
			this.OnPropertyChanged("CustomerName");
		}
	}
}

所以现在我的问题是，如果我绑定文本框的文本属性，它会泄漏任何内存以上？



根据以下链接，如果使用数据绑定，它可能会泄漏内存。

链接



WPF对我来说是新鲜事，在这种情况下不了解内存泄漏的问题，所以任何人都可以帮助我，在上述情况下它会泄漏内存吗？



并且有没有简单的方法可以检查此代码是否泄漏内存？



请帮我整理一下。



提前致谢。

So now my question is will it leak any memory if I bind the text propery of text box like above?

According below link it may leak the memory if use data binding.
Link

WPF is something new for me and do not understand the concern with memory leak in this situation, so can anybody help me on this will it leak memory in above case?

and is there any easy way to check this code leaking memory or not?

Please help me to sort out this.

Thanks in advance.

推荐答案

请参阅我的评论。检测泄漏并不容易，甚至在了解托管内存时，甚至不了解泄漏是不是那么简单。请查看我过去解释托管和非托管内存泄漏的答案：

Garbage collectotion负责所有内存管理 [ ^ ]，

推迟循环中的变量会导致内存泄漏？ [ ^ ]，

最佳方式摆脱导致内存不足的公共静态列表 [ ^ ]，

MDI表单中的内存管理 [ ^ ]。



我们真的不知道你有什么样的内存泄漏，坦率地说，我不确定你是否有泄漏。泄漏的实际检测并非如此简单，您不仅不应该信任任务管理器，甚至不应该信任性能计数器。有可能，你需要一个内存调试器。请参阅文章和内存调试器列表：

http://en.wikipedia.org/ wiki / Memory_debugger [ ^ ]。



请参阅Microsoft微软有关调试的文章，包括内存问题： http://msdn.microsoft.com/en-us/library/ee817660.aspx [ ^ ]。



请参阅此CodeProject文章：入门：使用WinDBG和SOS调试.Net应用程序中的内存相关问题 [ ^ ]。







在WPF窗口和控件中，没有特别需要完全使用处理。



垃圾收集本身可以处理托管内存。您根本不需要使用 GC 类;而且我建议不要触摸它（好吧，根据经验）。内存自动回收。如果通过引用无法访问来驱动。这里有很好的解释：

http://en.wikipedia.org/wiki/ Garbage_collection_％28computer_science％29 [ ^ ]。



由于无法预测析构函数的调用顺序，因此析构函数在.NET编程中也相对较少。



和 IDisposable.Dispose 仍然有用，但您可以使用使用语句更多地使用它：

http://msdn.microsoft .com / zh-CN / library / yh598w02％28v = vs.80％29.aspx [ ^ ]。



有趣的例子，请参阅我的文章：

使用使用语句：DisposalAccumulator [ ^ ]，

沙漏鼠标光标始终更改回原始图像。怎么样？ [ ^ ]。



实施 RAII 是好的：http://en.wikipedia.org/wiki/RAII [ ^ ]。



请参阅此替代方案：沙漏鼠标光标总是变回原始图像。怎么样？ [ ^ ]。

-SA

Please see my comment. Detecting a leak is not easy, and even understanding what a leak is is not so simple when it comes to managed memory. Please see my past answers explaining managed and unmanaged memory leaks:
Garbage collectotion takes care of all the memory management[^],
deferring varirable inside the loop can cuase memory leak?[^],
Best way to get rid of a public static List Causing an Out of Memory[^],
Memory management in MDI forms[^].

We don''t really know what kind of memory leak you have, and, frankly, I don''t sure if you have a leak at all or not. The actual detection of the leak is no so simple, and you should not trust not only Task Manager, but even the Performance Counter. Chances are, you would need a memory debugger. Please see the article and the list of the memory debuggers:
http://en.wikipedia.org/wiki/Memory_debugger[^].

Please see this Microsoft article on debugging, including memory issues: http://msdn.microsoft.com/en-us/library/ee817660.aspx[^].

Please see also this CodeProject article: Get Started: Debugging Memory Related Issues in .Net Application Using WinDBG and SOS[^].



In WPF windows and controls, there is no a special need to use disposal at all.

Garbage collection copes with the managed memory by itself. You don''t need to use GC class at all; and I recommend not touching it, ever (well, as a rule of thumb). Memory is reclaimed automatically. If is driven by making references unreachable. This is well explained here:
http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29[^].

As you cannot predict order of calling of your destructors, the destructors are also relatively rare in .NET programming.

And IDisposable.Dispose is still useful, but you can use it more with the using statement:
http://msdn.microsoft.com/en-us/library/yh598w02%28v=vs.80%29.aspx[^].

For an interesting example, please see my articles:
Using "using" Statements: DisposalAccumulator[^],
Hourglass Mouse Cursor Always Changes Back to its Original Image. How?[^].

It''s good to implement RAII: http://en.wikipedia.org/wiki/RAII[^].

Please see this alternative: Hourglass Mouse Cursor Always Changes Back to its Original Image. How?[^].

—SA

这篇关于WPF DataBinding中的内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！