强制GC.Collect()减少时间敏感代码中运行的机会？

Question

在一次采访中,我被要求提出一种方法来确保c#中的代码块能够在一致的时间内运行以满足假设的时间要求.访问者提到,一种方法是在执行代码块之前调用垃圾收集器进行收集,这样可以显着降低GC在该代码块中再次运行的可能性.它被应用于医疗设备的准确的基于时间的测量,其中垃圾收集可以影响那些测量.

这对我来说很有意义,但我找不到支持它的任何信息.我审查的一般共识是永远不要调用GC.Collect(),并且例外不包括这种情况.

可以运行GC.Collect()真正降低它很快就会运行的概率吗？这是使用.net框架执行此操作的正确方法吗？GC.Collect()是否也为其他CLR程序收集或仅适用于当前进程？

Answer 1

贾里德的答案当然很棒.要添加其他几点:

可以运行GC.Collect()真正降低它很快就会运行的概率吗？

是.

这是使用.net框架执行此操作的正确方法吗？

我不希望具有人类生命安全关键功能的软件的正确性依赖于关于收集器的无证行为的概率猜测.

那就是说:你应该在收集后做一个WaitForPendingFinalizers.请记住,终结器在自己的线程上运行,这可能会占用处理器时间.

GC.Collect()是否也为其他CLR程序收集或仅适用于当前进程？

收集在当前进程中清理托管内存,因此如果您在一个进程中有多个appdomains,则收集在一个appdomain中会收集其他appdomain.它不会跨越过程.

Answer 2

运行a 肯定有可能GC.Collect降低在紧随其后的代码中发生的可能性.有许多确定的方案你可以根据这些方案制定出具有这种确切行为的方案.例如,如果下一次分配将导致收集并且GC.Collect释放至少在场景期间分配的内存量.

然而,这是我永远不会依赖于真实的东西.绝对不能保证会出现这种情况.事实上,在场景中可能不会发生收集,并且运行强制的时间GC.Collect可能超过场景时间本身.

保证GC.Collect在给定方案期间不运行的唯一方法是

1. 不要分配任何内存
2. 不要让别人打电话 GC.Collect

非常难以保证.