内存管理101 [英] Memory Management 101
问题描述
我们一直存在内存管理问题。我已经在很多地方读过这篇文章并大致了解其中的一些问题。过去，我天真的理解是当垃圾收集器完成
时，垃圾收集器（GC）将获取管理的资源。跟他们。因此，没有理由使普通类实现IDisposable。
We have ongoing memory management problems. I've read up on this in many places and roughly understand some of the issues. In the past, my naïve understanding was that managed resources will get picked up by the Garbage Collector (GC) when it's done with them. Therefore, there was no reason to make normal classes implement IDisposable.
正如我现在所理解的那样实现IDisposable，而MSDN指出的是"提供释放非托管资源的机制"。 （ http://msdn.microsoft.com/en-us/库/ System.IDisposable的（v = vs.110）的.aspx ）。
但是，我们很少有非托管资源，但内存仍然存在泄漏。
The point of implementing IDisposable as I now understand it, and as MSDN points out is to "Provide a mechanism for releasing unmanaged resources." (http://msdn.microsoft.com/en-us/library/system.idisposable(v=vs.110).aspx). But, we have very few unmanaged resources, and yet memory still leaks.
很容易找到有关为什么Silverlight内存泄漏发生的信息，即使你已经'仅使用托管代码。以下是红门的一些提示：
It's easy enough to find information on why memory leaks in Silverlight occur even when you're only using managed code. Here are some tips from Red Gate:
其中两个大的是未注册的事件和数据绑定。例如，如果对象A 侦听对象B上的事件，则在对象A删除引用之前，对象B将永远不会被垃圾回收。因此，代码必须在
的末尾实现对象的生命周期，以删除对其他对象的引用。这些引用可以是数据绑定，事件处理程序等。
Two of the big ones are unregistered events and data binding. For example, if Object A listens to an event on Object B, Object B will never be garbage collected until Object A drops the reference. So, code must be implemented at the end of the lifespan of the object to drop its references to other objects. These references could be data bindings, event handlers and so on.
因此，问题确实成为一个战略问题。 了解何时可以清理对象以进行垃圾回收的最佳策略是什么？因此，例如，如果我实现了一个控件。假设控件继承自ComboBox。
并且，UI使用存储在数据库中的Xaml进行编码。 从ComboBox代码的角度来看，我怎么知道它的使用寿命何时结束？数据绑定将像对象之间的胶水一样，直到调用代码强制删除
它们。其他人如何处理这个问题？
So, the question really becomes a question of strategy. What is the best strategy for knowing when an object can be cleaned up for garbage collection? So, for example, if I implement a control. Let's say that the control inherits from ComboBox. And, the UI is encoded with Xaml which is stored in the database. How can I know, from the point of view of the ComboBox code, when its useful life has finished? Data Bindings will act like glue between objects until code is called to forcibly remove them. How are other people dealing with this problem?
推荐答案
这里有文章谈过关于如何追捕Silverlight中的内存泄漏，请看看：
Here has article talked about how to hunting down memory leaks in silverlight,please have a see:
http://viswaug.wordpress.com/2009/07/13/hunting-down-memory-leaks-in-silverlight/
http://thatextramile.be/blog/2009 / 08 / find-memory-leaks-in-silverlight-with-windbg /
此外，下面的主题讨论了如何避免silverlight应用程序中的内存泄漏
Besides, threads below talked about how to avoid the memory leak in silverlight application
http://www.telerik.com/forums/silverlight-应用程序内存泄漏检测器
最好的问候，
这篇关于内存管理101的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
