在采访中 我被要求提出一种方法来确保c＃中的代码块能够在一致的时间内运行以满足假设的时间要求。 访问者提到，一种方法是在执行代码块之前调用垃圾收集器进行收集，这样可以显着降低GC在该代码块中再次运行的可能性。它被应用于医疗设备的准确的基于时间的测量，其中垃圾收集可以影响这些测量。
这对我有意义，但我找不到任何支持这方面的信息。我审查的一般共识是永远不要调用GC.Collect（），并且例外不包括这种情况。
运行GC.Collect（）能否真正降低它很快就能运行的概率？这是使用.net框架执行此操作的正确方法吗？ GC.Collect（）是否也收集其他CLR程序，或者它是否仅适用于当前进程？
答案 0 :(得分：13)
贾里德的答案当然很棒。添加一些其他要点：
运行GC.Collect（）能否真正降低它很快就能运行的概率？
是
这是使用.net框架执行此操作的正确方法吗？
我不希望具有人类生命安全关键功能的软件的正确性依赖于关于收集器的未记录的行为的概率猜测。
那说：你应该在收集后做一个WaitForPendingFinalizers。请记住，终结器在自己的线程上运行，这可能会占用处理器时间。
GC.Collect（）是否也为其他CLR程序收集，或者它是否仅适用于当前进程？
收集在当前进程中清理托管内存，因此如果您在一个进程中有多个appdomains，则收集在一个appdomain中会收集其他appdomain。它不会跨越过程。
答案 1 :(得分：12)
绝对可能运行GC.Collect会降低在紧随其后的代码中发生的可能性。有许多确定的方案你可以根据这些方案制定出具有这种确切行为的方案。例如，如果下一次分配将导致收集并且GC.Collect至少释放了在场景期间分配的内存量。
然而，这是我从不依赖于真实的东西。绝对不能保证会出现这种情况。实际上，在场景期间可能不会发生集合，并且运行强制GC.Collect的时间可能超过场景时间本身。
保证GC.Collect在给定方案中不会运行的唯一方法是
GC.Collect 非常难以保证。
答案 2 :(得分：0)
您可以做的是指定通过app.config禁用并发/后台垃圾回收： Concurrent Garbage Collection on MSDN