c# - 为什么C#/xna中的垃圾回收不会自动处理渲染目标？

Question

我发现c＃/ xna中的渲染目标不会自动处理，您必须调用.dispose（）成员才能摆脱它们。

我以为垃圾回收是假定所有引用都消失后自动清除的东西，这有什么用呢？

还有其他没有自动处理的东西吗？

Answer 1

我以为垃圾回收是假定所有引用都消失后自动清除的东西，这有什么用呢？


这有两种错误。

垃圾收集收集可以安全收集并且需要的托管内存。而已。

将垃圾回收视为模拟无限堆内存的一种方式。由于我们可以假装我们拥有无限的内存，所以我们永远不必调用任何东西来释放已经使用完的内存，因为为什么我们要保留无限的资源？*

GC模拟无限堆的最简单方法是不执行任何操作。这适用于例如该进程具有4GiB的可用内存，并使用50MiB。收集永远不会出现。如果应用程序足够小，以至于永远都不会发生收集，这确实会发生。 （尽管它不至于让您不带收集就使用megs，但它会在尝试向操作系统请求更多应用程序内存之前尝试收集，但是当您怀疑“为什么没有GC”时，它仍然很有用。 ..“，在某些时候，什么都不做可能是有效的GC方法，一旦您想到了这种可能性，其他许多问题就会消失。

另一种方法是在可以清除时立即热心清理所有内容。引用计数垃圾收集器会发生这种情况。与.NET无关，但值得一提，因为它与您的问题“在所有引用消失之后”非常匹配。

另一个是，当需要内存，而在已经没有可用内存的存储中不可用时，GC会停止所有线程，标识根（每个线程的堆栈中的静态变量和本地引用），标识由根引用的所有内容，以及这些对象引用的所有内容，依此类推，直到找到仍然可以被应用程序使用的所有内容，然后将其他所有内容占用的内存视为空闲。然后，它压缩所有没有释放内存的对象，这既可以避免在释放更多可用内存时造成碎片，又可以使对象在内存中保持更近的距离（这对性能有较小的好处）。

如果还“提升”了它没有删除的对象，那么很可能是第一次删除它是不正确的，那么下次就不会删除了，因此它将查看那些在此过程中幸免的对象经常。

此时需要注意两件事：


我们无法预测GC何时释放给定对象的内存。
GC唯一要做的就是释放托管内存。它没有做任何其他事情（它对终结器有所帮助，我们将在后面介绍）。


当然，只有在一种情况下，我们可能希望先做某事然后撤消它，然后再获取托管内存。其他示例是：


获取文件句柄，然后释放它。
获取一个Windows句柄，然后释放它。
获取GDI句柄，然后释放它。
打开一个网络连接，然后关闭它。
通过网络连接发送协议定义的握手，然后在关闭之前通过它发送协议定义的签名。
获取一些非托管内存，然后释放它。
从池中获取一个对象（除了分配对象之外，还有一些开销，或者通过使用来“学习”），然后将其返回到池中。


到目前为止，我们已经描述过的GC将无济于事。

它们仍然具有两个共同点。它们具有开始操作和结束操作。

启动操作将很好地映射到对象创建或某个方法调用。

结束操作可以匹配Close()，End()，Free()，Release()方法调用，但是在定义IDisposable.Dispose()时，我们可以为它们提供一个通用接口。该语言还可以通过using†添加一些帮助。

（一个类可能同时具有Close()和Dispose()。在这种情况下，我们既可以选择关闭某些内容，稍后再打开它，也可以在其关闭状态下使用它，还可以选择一种保证清除的方法。完成对象之后）。

因此，以这种方式，存在IDisposable.Dispose()来清理所有需要清理的东西，除了托管内存。

现在，在这种情况下，需要实现IDisposable的三种类型的类：


那些自己拥有诸如句柄之类的非托管资源。
我们正在将其用于某种类型的合并或其他我们自己设计（或其他人的设计，但仍全部在.NET本身之内）之前/之后的场景。
那些具有依次实现IDisposable的字段的对象，因此，当我们处置此类的对象时，它将在这些字段上调用Dispose()。


让我们考虑一下，如果GC释放了此类对象的内存，而没有调用Dispose()会发生什么。

在第三种情况下，对象没有被处置实际上并不重要。真正重要的是，这些字段没有被处置（或者也许无关紧要，但是下面的某些字段很重要）。

在第二种情况下，它的重要性取决于合并的重要性。这可能不是最佳选择，但并非世界末日。

在第一种情况下，这是一场灾难-我们有一个未释放的资源，直到应用程序结束，甚至在此之后，我们都无法释​​放该资源（取决于资源的性质）。

因此，对象可以具有终结器。

当GC即将释放对象的内存时，如果它具有终结器，并且该终结器没有被抑制（Dispose()通常会执行此操作，以表明该对象已被清理干净，并且不再进行任何工作然后将其放入完成队列中，而不是从对象中释放内存。当然，这不仅意味着不收集该对象的内存，而且不通过其字段访问任何对象。

终结器线程通过该队列工作，在每个队列上调用finalizer方法。

发生这种情况有两件事：


我们不知道何时会发生。也许我们会用完资源或无法打开文件进行写入。
这意味着应该释放应该释放其内存的对象，它的寿命不仅比其应有的周期长，而且还可以多得多。


编辑：请注意，我们没有第三种类的终结器，也许没有第二种。在这种情况下，不需要终结器，因为它作为字段具有的真正关键的对象将被称为终结器，它完成了重要的工作。如果您尝试从终结器内部处理finalisable字段，那么也很容易导致严重的错误。如果编写的一次性类包装了它“拥有”的一个或多个一次性字段并负责清理，请实施IDisposable，但不要添加终结器。

总而言之，终结器被调用意味着两件事之一：


该应用程序正在关闭，所有终结器都在运行（太好了，世界一切都很好）。
有人搞砸了，没有清理应该清理的东西。


因此，尽管GC和资源之间没有通过终结器进行托管的交互，但这是万不得已的交互，决不是可靠的。您不应该将终结器视为进行GC清理的一种方法，而应将GC视为如果瑕疵没有发生就不要进行清理的一种方法（以及进行清理的一种方法） -应用程式关闭）。

*当然，如果您认为自己有无限的资源（鱼类，水牛，海洋废物处理能力），但事实证明您没有，那么事情就会变得混乱，因此也许不要将规则应用到生活。

†using使调用Dispose()更简单

using(someDisposableObject)
{
  //Do Stuff
}

等效于：

try
{
  //Do Stuff
}
finally
{
  if(someDisposableObject != null)
    ((IDisposable)someDisposableObject).Dispose();
}

和：

using(var someDisposableObject = someMethodCallOrCallToNew())
{
  //Do Stuff
}

等效于：

var someDisposableObject = someMethodCallOrCallToNew();
try
{
  //Do Stuff
}
finally
{
  if(someDisposableObject != null)
    ((IDisposable)someDisposableObject).Dispose();
}

作为优化，在编译器可以确定someDisposableObject不可能为null的情况下，可以取消null检查。