我在运行一个大型 .NET 4.0 x86 应用程序，使用的是 Windows Server 2003 x64 (2x Xeon 4 核处理器)，发现应用程序每天会出现 ~2-3 次 30 秒的冻结，然后恢复正常。应用程序每周只重新启动一次，并且消耗 400-800 MB 的内存，所以我认为这些冻结是垃圾回收导致的。我只在日志中看到这些冻结，没有在实时情况下看到过，否则我会检查任务管理器来确认。
我正在尝试找出运行的是哪个 .Net 4 GC，并确定如何将 GC 切换到新的并发后台 GC，如果它不是当前正在运行的 GC，或者如何确认这些是否确实是 GC（Procmon 在 Win2k3 服务器中不显示 .Net 工具）。
我已将这个答案重新发布在我的博客上：http://dave-black.blogspot.com/2012/04/how-to-determine-which-garbage.html
你可以通过以下两种方法确定你正在使用的GC版本：
你没有说明你正在运行何种类型的应用程序。如果你运行的是控制台应用程序、WinForm应用程序或Windows服务，则将获得工作站GC。仅仅因为你在服务器操作系统上运行，就不意味着你将获得服务器版本的GC。如果你的应用程序在多处理器机器上非托管运行，则默认会使用工作站GC - 并发方式。如果你的应用程序在多处理器机器上托管运行，则默认将使用ServerGC。
任何IIS或CLR自托管的应用程序都将默认以ServerGC模式运行。
以下适用于任何给定的.NET托管进程：
无论GC模式如何，每个托管进程只有1个Finalizer线程。即使在并发GC期间，管理线程也会被暂停（阻止）两次以执行某些GC阶段。
很少有人知道的事实是，即使您尝试设置GC的服务器模式，您可能仍不是在运行Server GC；GC最终决定哪种模式最适合您的应用程序，并且如果它确定您的ServerGC设置会对您的应用程序产生负面影响，则会覆盖您的设置。此外，在单处理器机器上运行的任何托管CLR应用程序都将覆盖任何手动GC设置-在这种情况下，CLR将始终使用工作站GC模式。
从.NET 4.5开始，所有应用程序都可以使用后台GC，不管它们使用哪个GC。后台GC是一种在多核CPU上运行的垃圾回收器，它可以在不阻止线程执行的情况下进行垃圾回收。
.NET Framework 4.7.1对垃圾回收（GC）进行了改进，以提高分配性能，特别是对于大对象堆（LOH）分配。这是由于架构更改将堆的分配锁分为两部分，针对小对象堆（SOH）和LOH。进行大量LOH分配的应用程序应该会看到减少分配锁争用并获得更好的性能。这些改进允许在后台GC（BGC）正在扫描SOH时进行LOH分配。通常，LOH分配器需要等待整个BGC扫描过程的持续时间才能满足分配内存的请求。这可能会妨碍性能。您可以在PerfView的GCStats中观察到此问题，其中有一个“LOH分配暂停（由于后台GC）>200毫秒事件”表。暂停的原因是“等待BGC线程空闲列表”。这个功能应该有助于缓解此问题。
如果您正在运行的是Windows服务器版本，那么默认会使用服务器版本的垃圾回收器。该版本不支持后台回收，因为垃圾是由多个线程进行收集，因此偶尔出现可观察到的暂停是很正常的。您可以通过使用app.exe.config文件来强制使用工作站版本：
<configuration>
<runtime>
<gcServer enabled="false"/>
</runtime>
</configuration>
还要查看GC.RegisterForFullGCNotification()方法的文档，以处理暂停的副作用。
.NET 4.5版本将支持服务器GC的后台收集。