更新:微软现在已经复制了这个错误,并正在努力修复。
在评估.NET平台用于低延迟软件开发的可行性时,我们在.NET 4并发工作站垃圾收集器中发现了一个严重的错误,该错误可导致应用程序一次挂起长达几分钟。
在我们的三台机器上,下面这个简单的C#程序会导致GC泄漏内存,直到一个巨大的GC周期启动,使程序停顿几分钟(!)同时回收了11 is的堆:
static void Main(string[] args)
{
var q = new System.Collections.Generic.Queue<System.Object>();
while (true)
{
q.Enqueue(0);
if (q.Count > 1000000)
q.Dequeue();
}
}
您需要在装有.NET 4的64位Windows上为x64编译,并使用默认(交互式)延迟设置在默认(并发工作站) GC下运行。
下面是在此计算机上运行此程序时任务管理器的外观:
请注意,当此程序需要的内存不超过100Mb时,这里已经泄漏了11 no的堆。
我们现在已经积累了大约12个关于这个bug的报告,都是用F#和C#编写的,它似乎与大多数gen0幸存下来时GC写屏障中的一个bug有关。然而,微软还没有能够复制它。你能?如果是这样的话,请您尽可能准确地描述您的设置,以便我们可以尝试缩小这个bug显露出来所需的确切条件。
发布于 2010-10-19 19:53:09
如果以64位运行,在linqpad中运行代码确实会消耗大量内存;以32位运行很好。
我已经安装了Windows7 x64旗舰版(像往常一样打了补丁),有8 8GB的主内存;安装了VS.NET和其他开发工具,所以可能会有一些奇怪的调试器挂钩,而其他空白机器上没有这些。
奇怪的是,他们没有重现它。你确定那里没有沟通中断吗?
哦,使用"new object()“而不是装箱的值类型会导致同样的问题(意料之中),因此您可能希望从重现案例中删除装箱的混杂因素。
发布于 2010-10-21 22:28:58
我不能复制它。我在一个有4 as内存的x64上试过了&编译为ANY。最大内存使用量约为2.5 at。最大GC暂停时间约为1084ms。
以下是我的GC ETW统计数据的输出。
您还可以按时间获取GC事件
您运行的类似跟踪输出可能有助于理解幕后发生的事情。
在Windows4.0中,提供.NET跟踪信息的Windows事件跟踪(ETW)。这是一个特定于GC的代码。
为了获取这些信息,有一个叫做PerfView的工具
下面是使用该工具获取GC信息的步骤
>H113然后发出“PerfMonitor.exe stop”
https://stackoverflow.com/questions/3967176
复制相似问题