C＃：应该将对象variables分配给null吗？
在C＃中，是否有必要将对象variables赋值为null如果您已经完成使用，即使它将超出范围？
不，这实际上可能是危险的，并且容易出错（考虑到稍后有人可能会尝试使用它的可能性，而不是意识到它被设置为空）。 如果有逻辑理由将其设置为null，则只设置为null。
更重要的是，对于实现IDisposable的对象调用Dispose。
除此之外，将null分配给引用variables只意味着您明确地指出了范围的末尾 – 大部分时间，只有less数指令提前（例如，方法体中的局部variables） – 带有编译器/ JIT优化时代，很有可能运行时会做同样的事情，所以你真的不能从中得到任何东西。 在less数情况下，如静态variables等（其范围是应用程序级别），如果已经完成使用，则应将variables赋值为null，以便对象将被垃圾回收。
把它推到湖边之前，你应该关掉你的车吗？
不是，这是一个常见的错误，但没有任何区别。 你不是将对象设置为null，只是对它的一个引用 – 对象仍然在内存中，仍然必须由垃圾收集器收集。
这些答复大部分都有正确的答案，但出于错误的原因。
如果它是一个局部variables，则该variables将在方法结束时脱离堆栈，因此它所指向的对象将只有一个引用。 如果该variables是该对象的唯一引用，则该对象可用于GC。
如果你把这个variables设置为null（并且很多人在方法结束时被教导这么做），那么你实际上可以延长对象留在内存中的时间，因为CLR会相信对象不能收集直到该方法结束，因为它看到一个代码引用的对象的方式在那里。 但是，如果您省略了null的设置，则CLR可以确定在代码中的某个点之后不再出现对该对象的调用，并且即使该方法尚未完成，GC也可以收集该对象。
指定为空通常是一个糟糕的主意：
- 从概念上讲，这是毫无意义的。
- 有很多variables，你可以有足够的额外分配空值，你可以大大增加方法的大小。 源代码的时间越长，读取它的精力就越多（即使其中的大部分内容只是可以过滤掉的东西），发现错误也就越容易。 使代码更加冗长，只有这样做才能使其更容易理解。
- 有可能您的空分配不会被优化。 在这种情况下，编译后的代码可能不会真正的解除分配，直到它实际上达到了空分配，而在大多数情况下，一旦variables除了超出范围之外（甚至在之前）可以被释放。 因此，您可以有一个非常小的性能影响。
唯一的时候我会分配一些null来“清除”将不再使用的variables，而不是因为null实际上是我明确要分配的值，是在两种可能的情况之一：
- 它是一个可能长寿的对象的成员，将不再被该对象使用，并且具有相当大的尺寸。 这里分配给null是一个优化。
- 它是一个可能长期存在的对象的成员，将不再被该对象使用，因此被释放其资源。 这里赋值为null是一个安全问题，因为find一个意外使用空对象的情况比偶然使用一个处置对象更容易。
这两种情况都不适用于局部variables，只适用于成员，而且都很less见。
不。当涉及到局部variables时，如果你有一个对象的引用，那么它就没有任何区别，重要的是如果引用将被使用或不被使用。
在代码中添加一个额外的空分配不会影响性能，它根本不会影响内存pipe理，但会将无动力的语句添加到代码中，使其不易读。
垃圾收集器知道在代码中最后一次使用引用的时间，所以只要不再需要，就可以收集对象。
例：
{ // Create an object StringBuilder b = new StringBuilder(); b.Append("asdf"); // Here is the last use of the object: string x = b.ToString(); // From this point the object can be collected whenever the GC feels like it // If you assign a null reference to the variable here is irrelevant b = null; }
我只想补充一点，AFAIK这只是Visual Basic一个版本的有效模式，甚至有些争议。 （IIRC只用于DAO对象。）
