C#：对象变量应该分配为 null 吗？

Question

在 C# 中，如果您已经使用完一个对象变量，是否有必要将它分配给 null，即使它无论如何都会超出范围？

Answer 1

不，这实际上可能是危险的并且容易出现错误（考虑一下有人可能稍后尝试使用它，而没有意识到它已被设置为空的可能性）。仅当有合理理由将某些内容设置为 null 时，才将其设置为 null。

Answer 2

在把车推到湖边之前你应该关掉它吗？
不，这是一个常见的错误，但没有任何区别。您没有将对象设置为null，而只是对其进行一个引用 - 该对象仍然在内存中，并且仍然必须由垃圾收集器收集。

Answer 3

在我看来，更重要的是对实现了 IDisposable 的对象调用 Dispose。

除此之外，将 null 分配给引用变量仅意味着您明确指示范围的结束 - 大多数时候，这只是早期的一些指令（例如，方法主体中的局部变量）——随着编译器/JIT 优化的时代，运行时很可能会做同样的事情，所以你真的不会从中得到任何东西。在某些情况下，例如静态变量等，其范围是应用程序级别，如果您使用完变量，则应将变量分配为 null ，以便对象将被垃圾收集。

Answer 4

这些回答中的大多数都有正确的答案，但原因却是错误的。

如果它是局部变量，则该变量将在方法结束时从堆栈中退出，因此它指向的对象将少一个引用。如果该变量是对该对象的唯一引用，则该对象可用于 GC。

如果您将变量设置为 null（许多这样做的人被教导在方法结束时这样做），那么您实际上可能会延长对象在内存中保留的时间，因为 CLR 会认为该对象不能被收集直到方法结束，因为它看到了对下面对象的代码引用。但是，如果省略 null 设置，CLR 可以确定在代码中的某个点之后不再出现对该对象的调用，并且即使该方法尚未完成，GC 也可以收集该对象。

Answer 5

分配给 null 通常是一个坏主意：

1. 从概念上讲，它毫无意义。
2. 对于许多变量，您可能有足够的额外赋值为 null，从而明显增加了方法的大小。某些东西的源代码越长，阅读它所花费的精力就越多（即使其中大部分只是可以过滤掉的东西），并且更容易发现错误。仅当这样做更易于理解时，才使代码变得比必要的更加冗长。
3. 您的空分配可能不会被优化掉。在这种情况下，编译后的代码可能不会执行真正的释放，直到它实际达到空赋值为止，而在大多数情况下，一旦变量除了超出范围（有时甚至之前）之外什么也不做。可以被解除分配。因此，您可能会对性能产生非常小的影响。

我唯一一次将某些内容分配给 null 来“清除”将不再使用的变量，而不是因为 null 实际上是我明确想要分配的值，是在两种可能的情况之一

1. ：一个可能寿命较长的对象，将不再被该对象使用，并且具有相当大的大小。这里分配为 null 是一种优化。
2. 它是可能长期存在的对象的成员，将不再被该对象使用，因此已准备好释放其资源。这里分配给 null 是一个安全问题，因为发现意外使用 null 对象的情况比意外使用已处置对象的情况更容易。

这两种情况都不适用于局部变量，仅适用于成员，而且两者都很罕见。

Answer 6

不会。当涉及到局部变量时，是否有对象的引用根本没有区别，重要的是是否会使用该引用。

在代码中放置额外的空赋值不会对性能造成太大影响，也根本不会影响内存管理，但它会在代码中添加无动机的语句，从而降低可读性。

垃圾收集器知道代码中最后一次使用该引用的时间，因此它可以在不再需要该对象时立即收集该对象。

例子：

{
  // 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;
}

Answer 7

对于必须实现 IDisposable 的对象，作为实践，我在 IDisposable 的实现中将所有成员设置为 null。

很久以前，我发现这种做法极大地改善了 Windows Mobile 上运行的 .NET Compact Framework 应用程序的内存消耗和性能。我认为，与主 .NET Framework 相比，当时的 .NET Compact Framework 可能具有非常简约的垃圾收​​集器实现，并且在 IDisposable 实现中解耦对象的行为帮助 .NET Compact Framework 上的 GC 完成了它的任务。

这种做法的另一个原因是在对象上执行 IDisposable 后，实际上不希望任何东西尝试使用已处置对象上的任何成员。当然，理想情况下，您希望在尝试访问某个对象的任何函数时已释放的对象中出现 ObjectDisposeException，但用 NullReferenceException 代替它比没有异常要好。您想了解如何处理已释放对象的代码，因为滥用已释放的非托管资源可能会给应用程序带来很多麻烦。

注意： 我绝对不会提倡在对象上实现 IDisposable，除了将成员设置为 null 之外没有其他原因。我说的是当您出于其他原因需要实现 IDisposable 时，即您有实现 IDisposable 的成员或您的对象包装非托管资源。

Answer 8

我想补充一点，据我所知，这只是 Visual Basic 单点版本的有效模式，甚至这也有些争议。 （IIRC 它仅适用于 DAO 对象。）