C#调用IDisposable.Dispose()vs使对象为null

时间:2015-05-27 06:59:55

标签: c# memory-leaks garbage-collection idisposable

请考虑以下代码:

一个。玩具类

class Toy
{
    private string name;
    public string Name
    {
        get { return name; }
        set { name = value; }
    }

    private ToyAddon addOn;
    public ToyAddon AddOn
    {
        get { return addOn; }
        set { addOn = value; }
    }

    public void RemoveAddons()
    {
        /*
         * someone said: this could lead to possible memory leak
         * if this class implements IDisposable,
         * then we are not disposing any of the resource 
         * */
        //this.addOn = null; 

        /* instead use this */
        var disposableToyAddOn = this.addOn as IDisposable;
        if (disposableToyAddOn != null)
            disposableToyAddOn.Dispose();

        this.addOn = null;

    }
    public override string ToString()
    {
        return String.Format("{0}, {1}",
            this.name, 
            (this.AddOn == null) ? "" : addOn.AddOnName);
    }
}

B中。玩具插件

class ToyAddon
{
    private string addOnName;

    public string AddOnName
    {
        get { return addOnName; }
        set { addOnName = value; }
    }

}

℃。主程序

class Program
{
    static void Main(string[] args)
    {
        ToyAddon tAdd = new ToyAddon();
        tAdd.AddOnName = "Amazing AddOn";
        Toy t = new Toy();

        t.Name = "Amazing Toy";
        t.AddOn = tAdd;
        t.RemoveAddons();

        Console.WriteLine(t.ToString());


    }
}

现在我建议检查一个“having-a”对象是否正在实现IDisposable然后调用它的dispose方法。 (请查看玩具类中的评论)

恕我直言,如果我将引用设为null,那么堆上的对象将被GC标记为Collection。

如果这个推理可以在,堆和堆栈上发生什么,以及GC的作用,如果类(如ToyAddOn)实现IDisposable vs,如果它没有,那将是值得赞赏的。 / EM>

4 个答案:

答案 0 :(得分:2)

  

现在有人向我建议检查一下" a-a"对象是   实现IDisposable然后调用它的dispose方法。

IDisposable是一种模式,用于释放需要明确释放的非托管资源,因为GC不了解它们。通常,一个持有非托管资源的类也将实现一个终结器,为此,它实际上是对对象的生命周期的贡献,而不是必要的。 Dispose在这些情况下通常会调用GC.SupressFinalize,以便从终结队列中删除所述对象。

如果你有一个IDisposable对象,通常是一个很好的模式,你自己实现IDisposable以确保底层资源被处置掉。

  

恕我直言,如果我将引用设为null,那么堆上的对象就是   标记为GC收集。

如果您想要成员"退出"不是static成员,那么(通常)没有理由这样做。编译器非常智能,可以对其进行优化,并且GC非常智能,可以知道不再有对变量的引用并对其进行清理。

修改

正如@ScottChamberlain指出的那样,有些情况下,一次性物体仍然被引用,因此GC不会为GC计算它。处理它并将其归零时,你提示GC它已经准备好收集"。

答案 1 :(得分:1)

如果您没有手动处理类,那么只有当GC检测到有足够的内存压力需要进行垃圾回收并且对象获得GCed并结束时,才会清除它所保存的非托管资源(如果有)

并非所有需要处理的东西都会增加内存压力,他们可能会坚持像Window Handles这样的东西。

如果内存压力永远不会变得足够高,那么在耗尽dispose释放的资源之前,你可能永远不会垃圾收集这些值。当人们把Bitmap放在一个紧凑的循环但不处理它们时,你经常会看到这一点,每个位图都使用GDI +句柄而不会计入托管内存压力并且不会触发GC。这通常会导致人们在仍然拥有大量内存时获取OutOfMemoryExceptions,因为他们用完的真实内容是GDI +处理。

通过明确处理您的资源,您不需要"希望您获得幸运"并且在用完它所持有的非托管资源之前让你的对象得到终结。

堆栈和堆与此无关。

答案 2 :(得分:1)

尝试向IDisposable尝试某些东西并在实现该接口时处置它的模式高度指示了设计缺陷。如果参考代码的类型保持不实现IDisposable,那么这是一个非常强烈的迹象:

  1. 该类型的参考的持有者不应该处置它;即使派生类型实现Disposable,它们的清理责任应该是创建这些类型实例的代码(并保存这些类型的引用)。

  2. 基本类型应该已经实现IDisposable(即使99%的实现都不会做任何事情),因为某些实例的生命周期不在任何知道他们是否真正需要的人的控制之下清理。后一种情况的一个主要例子是IEnumerator<T>。虽然IEnumerator省略IDisposable,但在发布后不久就显现出来了;当Microsoft添加IEnumerator<T>时,他们直接包含IDisposable。虽然大多数IEnumerator<T>的实现都可以在没有清理的情况下放弃,但是在集合上调用GetEnumerator的代码无法知道IEnumerator<T>的实现是否可能是其中之一需要清理的罕见的,并且没有实际的方法IEnumerable<T> GetEnumerator方法创建IEnumerator<T>可以预期知道客户端何时完成它,所以除客户端之外的任何人都不会处于Dispose IEnumerator<T>。{/ p>

  3. ToyAddOn位置

    确定实现Disposable的{​​{1}}实例是否完全可能在其生命周期结束时,而只有引用由不知道是否需要清理的代码保留。如果是,请ToyAddOn实施Disposable。如果没有,请将清理保留给知道它是必需的代码。

答案 3 :(得分:1)

我同意这三个答案。只是为了简化你的问题的答案:

  

/ *            *有人说:这可能会导致内存泄漏            *如果此类实现IDisposable,            *然后我们没有处置任何资源            * * /           //this.addOn = null;

有人说的不太适合你的例子。但总的来说,这绝对是正确的。

假设玩具类的寿命比ToyAddon长得多。 ToyAddon类有玩具类的活动订阅。如果是这样,ToyAddon应该在其Dispose方法中取消订阅这些订阅。如果你从Toy实例中删除后没有调用ToyAddon的Dispose方法,只要Toy实例存在,ToyAddon instace就会存在于内存中。

而且,即使你在上面的情况下调用Dispose,仍然通过'addOn'引用ToyAddon。所以需要将addOn设置为null才能完全摆脱它。

  

恕我直言,如果我将引用设为null,那么堆上的对象就是   标记为GC收集。

在你的情况下纠正,一般错误,如上所述。