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也可以收集该对象。

指定为空通常是一个糟糕的主意:

  1. 从概念上讲,这是毫无意义的。
  2. 有很多variables,你可以有足够的额外分配空值,你可以大大增加方法的大小。 源代码的时间越长,读取它的精力就越多(即使其中的大部分内容只是可以过滤掉的东西),发现错误也就越容易。 使代码更加冗长,只有这样做才能使其更容易理解。
  3. 有可能您的空分配不会被优化。 在这种情况下,编译后的代码可能不会真正的解除分配,直到它实际上达到了空分配,而在大多数情况下,一旦variables除了超出范围之外(甚至在之前)可以被释放。 因此,您可以有一个非常小的性能影响。

唯一的时候我会分配一些null来“清除”将不再使用的variables,而不是因为null实际上是我明确要分配的值,是在两种可能的情况之一:

  1. 它是一个可能长寿的对象的成员,将不再被该对象使用,并且具有相当大的尺寸。 这里分配给null是一个优化。
  2. 它是一个可能长期存在的对象的成员,将不再被该对象使用,因此被释放其资源。 这里赋值为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对象。)