1

只是想知道这是否是从内部终止对象的可接受方式？自从

this = null;

不可能。我通常只设置一个名为disposed 的布尔值或其他东西，如果在我终止它后访问该对象，则抛出异常。但后来这发生在我身上，我认为这可能是一个更清洁的解决方案，但它似乎有点 hacky，所以我想要第二个意见。我应该坚持设置一个布尔值还是继续这个。这也将允许垃圾收集器清理我的对象。

public class A
{
    public A()
    {

    }

    public void Method()
    {
        try
        {
            //Do Something.
        }
        catch
        {
            //If it fails destroy the object
            Destroy(this);
        }
    }

    private static void Destroy(A a)
    {
        a = null;
    }
}
4

2 回答 2

7

a是参考的副本。设置为null你喜欢的，它不会影响原始参考。现在当然你可以改变方法签名来接受它的参数ref，但是你为什么要这样做呢？我无法想象您要在这里解决什么问题。

这也将允许垃圾收集器清理我的对象。

GC 不需要你设置对 的引用null，你没有用这个想法完成任何事情。你在捣乱参考文献的副本；该对象仍在内存中，并且 GC 足够聪明，可以知道给定引用是否有效，无论其当前值是否为null.

有关更多详细信息，请参阅此 SO 线程。

于 2012-07-23T00:39:11.863 回答
2

如果您想要显式的确定性销毁，请实现接口 IDisposable 并在处理完对象后调用 Dispose。否则，一旦最后一个引用超出范围，垃圾收集器就会销毁该对象。null一个特定的 ref 不会触发集合。除非您确定必须这样做，否则不要再猜测垃圾收集器。

你的物品中有什么让你如此渴望尽快将其销毁？您绝对无法承受超过必要时间的资源很少而且介于两者之间 - 数据库连接、套接字、几百 MB 的内存块。对于那些，IDisposable 存在。其余的对象会在 GC 到达它们之前存活几毫秒；这就是垃圾收集世界的生活。在 2012 年，这被认为是可接受的折衷方案。

于 2012-07-23T00:45:21.760 回答