什么可以解释托管堆上超过 5,000,000 个 System.WeakReference 实例？
我一直在针对生产 ASP.NET Web 应用程序运行负载测试，并且看到在堆上创建了大量 System.WeakReference。在大约 15 分钟内，负载管理堆内存已飙升至大约 3GB，并且我有大约 5,000,000 个对 System.WeakReference 的引用。对所有代执行强制垃圾回收不会释放这些引用。
我看过有关 __ENCLIST 帮助程序类的帖子，如果在调试中编译程序集，可以为创建的所有对象创建弱引用，起初我认为这是问题所在，但已验证所有部署的程序集都是在发行版中构建的。
我一直在使用 WinDbg 来调试该进程，这是 !dumpheap -stat 的最后几行，
000007fef788e0c0 39253 18510000 System.Collections.Hashtable+bucket[] 00000000021bf120 94336 151023192 Free 000007fef7887e98 5959 189838752 System.Char[] 000007fef7874390 517429 589750224 System.Object[] 000007fef78865a0 1531190 1230824112 System.String 000007fef787dab8 51723338 1655146816 System.WeakReference
您可以看到这些 System.WeakReference 消耗了大约 1.5GB 内存。
有谁知道什么可能创建所有这些弱引用？
I have been running load tests against a production ASP.NET web application and am seeing a huge number of System.WeakReferences created on the heap. Within about 15 minutes under load managed heap memory has shot up to about 3GB and I have approximately 5,000,000 references to System.WeakReference. Performing a forced garbage collection of all generations does not release these references.
I have seen posts about the __ENCLIST helper class which if assemblies are compiled in debug can create WeakReferences to all objects which are created, at first I thought this was the problem, but have verified all deployed assemblies are built in release.
I have been using WinDbg to debug the process, here's the final few lines of !dumpheap -stat
000007fef788e0c0 39253 18510000 System.Collections.Hashtable+bucket[] 00000000021bf120 94336 151023192 Free 000007fef7887e98 5959 189838752 System.Char[] 000007fef7874390 517429 589750224 System.Object[] 000007fef78865a0 1531190 1230824112 System.String 000007fef787dab8 51723338 1655146816 System.WeakReference
As you can see about 1.5GB of memory has been consumed by these System.WeakReferences.
Does anyone have any idea what could be creating all these WeakReferences?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
事实证明，由于动态创建大量 System.Diagnostics.TraceSwitch 实例，导致 System.WeakReference 泄漏，在内部 TraceSource/TraceSwitch 为新的 TraceSource/TraceSwitch 分配 WeakReference 并将 WeakReference 放入列表中。虽然 WeakReference 允许 TraceSource/TraceSwitch 被垃圾收集，但 WeakReference 本身永远不会被释放，从而导致内存泄漏。
可以在此处找到更多信息
http ://msdn.microsoft.com/en-us/library/system.diagnostics.tracesource(VS.80).aspx
So it turns out I had a System.WeakReference leak due to dynamically creating large numbers of System.Diagnostics.TraceSwitch instances, internally TraceSource/TraceSwitch allocates a WeakReference to the new TraceSource/TraceSwitch and puts the WeakReference into a list. Although the WeakReference allows the TraceSource/TraceSwitch to be garbage collected, the WeakReference itself will never be freed resulting in a memory leak.
A little more info can be found here
http://msdn.microsoft.com/en-us/library/system.diagnostics.tracesource(VS.80).aspx