你能重现这个64位的.NET 4GC错误吗？
更新：微软现在已经复制了这个错误，并正在努力修复。
在评估.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显露出来所需的确切条件。
回答 2
Stack Overflow用户
发布于 2010-10-19 19:53:09
如果以64位运行，在linqpad中运行代码确实会消耗大量内存；以32位运行很好。
我已经安装了Windows7 x64旗舰版(像往常一样打了补丁)，有8 8GB的主内存；安装了VS.NET和其他开发工具，所以可能会有一些奇怪的调试器挂钩，而其他空白机器上没有这些。
奇怪的是，他们没有重现它。你确定那里没有沟通中断吗？
哦，使用"new object()“而不是装箱的值类型会导致同样的问题(意料之中)，因此您可能希望从重现案例中删除装箱的混杂因素。
Stack Overflow用户
发布于 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信息的步骤
- 以管理员身份启动cmd.exe，这需要收集ETW
- 启动您要跟踪的应用程序
- 发出命令“PerfMonitor.exe /process:4180 start”，其中4180是进程id
- 让应用程序运行一段时间<
>H113然后发出“PerfMonitor.exe stop”
- 获取报告“PerfMonitor.exe GCTime”的命令。这将生成一个报告，并使用GC统计数据在浏览器中打开它。
https://stackoverflow.com/questions/3967176
复制相似问题