需要帮助消除我的应用程序中的弱引用
我正在尝试解决我的应用程序中的内存泄漏问题。 我已经下载并运行了 RedGate 的 ANTS Memory Profiler 5.0，内存分析器告诉我泄漏与 WeakReferences 有关。
我遇到的问题是我从未听说过 WeakReference，也没有在我的应用程序中明确声明它们。 根据我所做的阅读，我相信当您有一个试图被销毁但由于太多其他对象不断引用它而无法销毁的对象/资源时，就会创建弱引用。 我认为与无法删除文件的方式大致相同，因为它仍在使用中。
所以我的问题是如何确定这些弱引用来自哪里？ 我怀疑可能是使用了ByRef？ 另一位同事建议使用哈希表。
希望得到一些关于弱引用检测和消除的澄清以及我的怀疑的一些澄清。
谢谢。
I am trying to resolve a memory leak(s) in my app. I've downloaded and ran RedGate's ANTS Memory Profiler 5.0 and the memory profiler tells me the leak has to do with WeakReferences.
The problem I am running into is that I've never heard of a WeakReference nor are they explicitly declared in my app. From the reading I've done I believe weak reference's are created when you have an object/resource that is trying to be destroyed but cant because too many other objects keep referencing it. I assume much the same way that a file can't be deleted because it is still in use.
So my question is how do I determine where these weak references are coming from? I have suspicions that it might be the use of ByRef? Another collegue suggested hashtables.
Hoping to get some clarification on weakreference detection and elimination and some clarification on my suspicions.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在与 .NET 资源泄漏（内存/句柄/线程/等）的斗争中，我们发现了一个最重要的罪魁祸首：挥之不去的事件处理程序。 如果我有一个想要处理的对象，但我仍然有一个事件处理程序注册到该对象的事件，那么该对象不会真正消失 - 这些僵尸会繁殖并串成链，直到 繁荣！您托管的应用程序确实存在资源泄漏。
我们采取了霰弹枪方法，搜索我们最常用和最重的事件类，我们手动添加并通过 VB.NET 的“Handles”关键字添加事件，并确保在 Dispose 期间为每个事件调用RemoveHandler / -=。 我们还明确尽可能地丢弃。
ANTS 是一个很好的追踪这些问题的工具，但它不是一个简单的工具（但它是我发现的解决这些问题的最简单的工具）。 花一些时间熟悉它，如果您使用的是版本 5，那么请使用这些新的过滤器。
不幸的是，没有灵丹妙药，这是我对 .NET 最大的不满之一，因为通常你不知道自己遇到了问题，直到问题非常普遍且难以控制。
In the battles with .NET resource leaks (memory/handles/threads/etc) we've found one culprit that rises above all else: lingering event handlers. If I have an object I'd like to dispose of, but I still have an event handler registered to an event of that object, then the object won't really go away--these zombies multiply and string together in chains until boom! you're managed app has what is for all intents and purposes a resource leak.
We've taken the shotgun approach and scour our most heavily used, and heaviest, classes for events we add both manually and by means of VB.NET's "Handles" keyword and ensure that RemoveHandler / -= is called for each during Dispose. We also explicitly Dispose of as much as possible.
ANTS is a great tool for tracking these down, but it's not a simple tool (but it is the simplest of the tools I've found for these issues). Spend some time getting familiar with it, and if you're on version 5 then make use of those new filters.
Unfortunately there's no silver bullet, it's one of my largest aggrivations with .NET because typically you don't know you have a problem until it's terribly wide-spread and hard to reign in.
使用 WeakReference 不应导致内存泄漏。 它会导致对象被收集，但您仍然可以在最后一刻选择访问它。
我没有使用内存分析器，但是：
.Net 应用程序中的所有内存泄漏都与事件/委托有关。
添加侦听事件的方法时，您将创建从包含事件（关键字）的对象到具有要调用的方法的对象的引用。
如果对包含该方法的对象的所有其他引用都消失了，您可能认为它将被收集，但仍然存在通过事件的（不可见的）引用。
Using a WeakReference should not cause a memory leak. It would cause an object to be collected, but you still have a last minute option to access it.
I have not worked the the Memory profiler but:
All my memory leaks in .Net application have to do with events/delegates.
When you add a method to listen to an event, you create a reference from the object that contains the event (keyword) to the object that has the method you want to call.
If all other references to the object that contains the method are gone, you might think it will be collected, but there is still an (invisible) reference via the event.
我发现我的 WeakReferences 是由 System.Diagnostics.TextWriterTraceListener 类创建的。 我仍然没有解决我的内存泄漏问题，而且我深陷其中，我开始怀疑我是否有内存泄漏，但知道弱引用来自哪里，我感到很欣慰。
感谢所有发帖的人！
I discovered my WeakReferences were being created by the System.Diagnostics.TextWriterTraceListener class. I still havent resolved my memory leak and I'm so deep in it I'm starting to question whether I have a memory leak or not but I'm relieved to know where the WeakReferences are coming from.
Thanks to all who posted!
此内存泄漏是 .NET 框架中的一个已知错误。 __ENCList 是一个内部 .NET 类，用于提供编辑和继续功能。 解决此问题的唯一方法是在发布模式下重新编译。 （如果您一直使用调试模式在生产环境中提供详细的异常报告，这将是不幸的。）
http ://support.microsoft.com/?kbid=919481
莫阿塔兹
电脑工程师
This memory leak is a known bug in the .NET frameworks. __ENCList is an internal .NET class that is used to provide Edit and Continue functionality. The only resolution to this issue is to recompile in Release mode. (Which is unfortunate if you had been using the debug mode to provide detailed exception reporting in production environments.)
http://support.microsoft.com/?kbid=919481
Moataz
Computer Engineer