在 C# 中推动垃圾收集器
有谁知道是否显式取消引用对象；
finalResults = null;
给垃圾收集器更多的推动来清理吗？我有一个相当大的对象（不是很大，但足够大，我不希望它在使用后停留太久）
上面的内容会有所帮助还是毫无意义的代码？我特别避免以编程方式与 GC 本身对话，我只需要知道上面的内容是否会充当任何类型的提示/提示。
Possible Duplicate:
Garbage Collection: Is it necessary to set large objects to null in a Dispose method?
Does anyone know if explicitly de-referencing an object;
finalResults = null;
gives the garbage collector any more of a nudge to clean up? I have a rather large object (not huge, but big enough that I don't want it hanging around for too long after it's been used)
Would the above help or is it pointless code? I am specifically avoiding programatically talking to the GC itself, I just need to know if the above would act as any sort of prompt/hint to it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
信息不足。
如果
finalResults是一个局部变量，那么它是毫无意义的，甚至可能有害。你只是干扰了优化器。如果它是类成员（属性或字段），它可能会有用。不是很常见，但如果您可以非常确定该值不会再被使用，那么将其设置为 null 也没什么坏处。
Not enough information.
If
finalResultsis a local variable then it is pointless and potentially even harmful. You're just interfering with the optimizer.If it is a class-member (property or field) it may be useful. Not very often but if you have a point in time where you can be very sure the value won't be used anymore then it won't hurt to set it to null.
据我所知，事实并非如此。
垃圾收集器使用的主要规则（确定是否需要进行收集）是确定 Gen-0 堆中是否有足够的空间来在需要时分配新对象。如果它无法分配该对象，则会执行收集。
集合是混乱且嘈杂的（由于堆压缩、对象从 Gen--0 提升到 Gen-1、Gen-1 提升到 Gen-2），因此最好让 GC 来处理它。
GC 将在需要时完成您的对象，因此不必担心它闲置。
如果您真的很担心，那么在调试构建中尝试调用“
Where you'd set the object to Null”，看看它会产生什么影响，但实际上我最好的建议是不要为此失眠。
As far as I know, not really.
The main rule the garbage collector uses (to work out if it needs to do a collection) is to work out if there is enough space in the Gen-0 heap to allocate a new object when it's asked for. If it can't allocate the object, it then performs a collection.
Collections are messy and noisy (because of heap compression, promotion from objects from Gen--0 to Gen-1 and Gen-1 to Gen-2) so it's best to leave the GC to worry about it.
The GC will finalize your object when it needs to, so don't worry about it sitting around.
If you're really concerned, then in a debug build try putting a call to
Where you'd set the object to Null, and see what affect it has, but really my best advise is to not lose any sleep about it.
不要花任何时间将变量设置为 null。它对“推动”垃圾收集器没有任何作用。
拥有 GC 的全部意义在于您无需担心对象的生命周期。
Don't spend any time setting variables to null. It does nothing to "nudge" the garbage collector.
The whole point of having a GC is that you don't need to worry about object lifetime.
将变量设置为 null 仅具有 C# 编译器的价值，无法确定它不会再次使用。
在编写良好、清晰的代码中，很少有 C# 编译器无法跟踪局部变量上次使用的情况。
现在，如果 FinalResults 是一个字段，情况就会有所不同。
Setting a variable to null is only of value of the C# compiler can not work out it's self that it is not going to be used again.
In well writen clear code there are very few cases when the c# compiler can not track the last time a local variable is used it's self.
Now if finalResults was a field, it would be a different case.
上面的答案是正确的，但似乎没有人做出这种区分，所以我会：
这取决于
finalResults是如何声明的。如果它是在方法中声明的局部变量，则根本没有效果；在任何情况下，当该方法超出范围时，它所引用的对象都将有资格进行垃圾收集（并且仍然由垃圾收集器来确定何时要清理）。但是，如果
finalResults是一个类字段或属性，那么情况会略有不同（尽管小“f”似乎表明事实并非如此）。在这种情况下，它构成的对象将保存对 FinalResults 引用的对象的引用，直到它本身可以被垃圾回收（反过来，当没有任何东西保存对其的引用时，就会发生这种情况） 。在这种情况下，您可能实际上希望将其设置为 null，以允许该对象能够更早地进行 GC（假设引用对象仍将存在相当长的时间）时间）。The answers above are correct, but nobody seems to be making this distinction, so I will:
It depends on how
finalResultswas declared. If it's a local variable that was declared in a method, then there will be no effect at all; the object it was referencing would be eligible for garbage collection when the method goes out of scope in any case (and it will still be up to the garbage collector to figure out when it wants to clean up).If, however,
finalResultswas a class field, or property, then it's a slightly different scenario (although the small "f" seems to suggest that it is not). In this case, the object it forms part of will hold a reference to the object referenced byfinalResults, until it can be garbage collected itself (which happens when there's nothing holding a reference to it, in turn). In a situation like this, you may actually want to set it to null, to allow for the object to be eligible for GC earlier (assuming the referencing object is still going to be around for a significant amount of time).检查生成的IL；您可能会发现编译器知道该变量永远不会再次被引用，因此不必费心为该行生成任何代码，在这种情况下您知道行为不会有差异。
Check the generated IL; you may well find that the compiler knows the variable is never referenced again, so doesn't bother to generate any code for that line, in which case you know there won't be a difference in behaviour.