IDisposable 与缺少外部程序集的成员在终结器中失败

Question

我有 2 个程序集，A 包含 Main 方法和 Foo 类，它们使用程序集 B 中的 Bar 类：

杆组件（组件 B）：

public sealed class Bar : IDisposable { 
    /* ... */ 
    public void Dispose() { /* ... */ }
}

Foo 类（程序集 A）：

public class Foo : IDisposable {
    private readonly Bar external;
    private bool disposed;
    public Foo()
    { 
        Console.WriteLine("Foo");
        external = new Bar(); 
    }
    ~Foo()
    { 
        Console.WriteLine("~Foo");
        this.Dispose(false); 
    }
    public void Dispose()
    {
        this.Dispose(true);
        GC.SuppressFinalize(this);
    }
    protected virtual void Dispose(bool disposing)
    {
        if (disposed) return;
        if (disposing) external.Dispose();
        disposed = true;
    }
}

入口点（在程序集 A 中）：

class Program
{
    static void Main(string[] args)
    {
        try
        {
            var foo = new Foo();
            Console.WriteLine(foo);
        }
        catch (FileNotFoundException ex) 
        {
            // handle exception
            Console.WriteLine(ex.ToString());
        }
        Console.ReadLine();
    }
}

这个软件的一个要求是它必须优雅地处理缺少 dll 的情况。

因此，当我删除程序集 B 并启动应用程序时，我希望 main 方法中的 try catch 块处理程序集 B 丢失时抛出的 FileNotFoundException。确实如此，但这就是问题开始的地方......

当应用程序继续时（在控制台中输入一行），Foo 类的终结器被调用（？！）虽然没有创建 Foo 的实例 - 构造函数还没有被调用。由于没有该类的实例，因此我无法在外部对实例调用 GC.SupressFinalize。在没有 B 程序集的情况下运行项目时，您在控制台输出中看到的唯一内容是 ~Foo。

所以问题：

• 为什么即使没有创建类的实例，也会调用终结器？ （对我来说这完全没有意义！我很想开悟）
• 如果没有终结器中的 try-catch 块，是否可以防止应用程序崩溃？ （这意味着重构整个代码库...）

一些背景知识：我在编写启用插件的企业应用程序时遇到了这个问题，要求它必须在插件部署文件夹中缺少 dll 并标记故障插件时继续运行。我认为外部插件加载过程周围的 try-catch 块就足够了，但显然它没有，因为在捕获第一个异常之后，终结器仍然被调用（在 GC 线程上），最终导致应用程序崩溃。

备注 上面的代码是我可以编写的用于在终结器中重现异常的最简单的代码。

备注 2 如果我在 Foo 构造函数中设置断点（在删除 Bar 的 dll 之后），它不会被命中。这意味着如果我在构造函数中设置一个创建关键资源的语句（在更新 Bar 之前），它将不会被执行，因此不需要调用终结器：

// in class Foo
public Foo() {
    // ...
    other = new OtherResource(); // this is not called when Bar's dll is missing
    external = new Bar();        // runtime throws before entering the constructor
}

protected virtual void Dispose(bool disposing) {
    // ...
    other.Dispose();    // doesn't get called either, since I am
    external.Dispose(); // invoking a method on external
    // ...
}

备注3 一个明显的解决方案是像下面那样实现 IDisposable，但这意味着破坏参考模式的实现（甚至 FxCop 也会抱怨）。

public abstract class DisposableBase : IDisposable {
    private readonly bool constructed;
    protected DisposableBase() {
        constructed = true;
    }
    ~DisposableBase() {
        if(!constructed) return;
        this.Dispose(false);
    } 
    /* ... */
}   

Answer 1

为什么即使没有创建类的实例，也会调用终结器？

这个问题毫无意义。显然创建了一个实例；如果没有创建实例，终结器将完成什么？您是想告诉我们终结器中没有“this”引用吗？

构造函数没有被调用

构造函数不能被调用，因为jitting构造函数引用了一个类型缺失的字段。连jit都不能调用的构造函数体怎么可能被调用？

您似乎认为仅仅因为无法调用构造函数，就无法创建实例。这根本不符合逻辑。显然，在调用ctor之前必须有一个实例，因为对该实例的引用作为“this”传递给它。所以内存管理器创建了一个实例——垃圾收集器知道分配了内存——然后它调用构造函数。如果调用构造函数引发异常 - 或被异步异常（如线程中止）中断 - 那里仍然有一个实例，垃圾收集器知道，因此在它死亡时需要终结。

由于该对象永远不会被分配给任何活动变量——不可能，因为分配发生在 ctor 之后，并且当 jitter 试图对其进行 jit 时，ctor 抛出了——它将被确定为死在下一代零系列。然后它将被放入终结器队列中，这将使其处于活动状态。

终结器仍然被调用（在 GC 线程上），最终导致应用程序崩溃。

然后修复终结器，使其不会那样做。

请记住，ctor 可以随时被异步异常（例如线程中止）中断。您不能依赖在终结器中维护的对象的 任何 不变量。终结器是非常奇怪的代码；您应该假设它们可以在任意线程上以任意顺序运行，并且对象处于任意不良状态。 您需要在终结器中编写极具防御性的代码。

如果我在 Foo 构造函数中设置断点（在删除 Bar 的 dll 之后），它不会被命中。

正确。正如我所说，构造函数体甚至不能被 jitted。你怎么能在一个甚至不能被 jitted 的方法中打断点？

这意味着如果我在构造函数中设置一个创建关键资源的语句（在更新 Bar 之前），它将不会被执行，因此不需要调用终结器。

您是否认为需要调用终结器与垃圾收集器完全无关。终结器可能具有其他语义，而不仅仅是清理资源。垃圾收集器不会尝试从心理上确定开发人员的意图并决定是否需要调用终结器。 对象已分配并具有终结器，而您没有抑制终结器，因此它将被终结。如果您不喜欢这样，那么 不要制作终结器。 em> 你做了一个终结器，因为大概你希望对象的所有实例都被终结，所以它们将会被终结。

坦率地说，我会重新审视您的基本情况。您可以安全地恢复并继续在缺少所需 DLL 的应用程序域中执行代码的想法对我来说似乎是一个非常糟糕的想法。做到这一点将非常困难。

Answer 2

我认为这里的抱怨是对象构造失败，但终结器仍然被调用，并且因为终结器线程正在捕获异常，所以您无法自己捕获它？

这是完全合法的行为。假设类部分构建，并且在它抛出之前已经打开了一些关键资源？如果终结器没有运行会发生什么？这方面的案例在 C# 中得到了简化，但在 C++ 中，它是许多帖子和书籍的主题（Sutter：Exceptional C++）。

SO: Is Finalizer Called if constructor throws (C++/c#)

隐含问题的答案是，我如何在运行时处理丢失/可选程序集的绑定失败？，是你不知道。最好的解决方案是轮询目录，手动加载程序集，并根据程序集公开的接口和您的约定检索包含的类型。

终结器线程内部绑定失败的屏幕截图。如果注释掉 Bar 的 disposing 行，异常就会消失，但绑定失败不会。

Answer 3

您可能希望将您的Foo 类放在第三个程序集AssemblyC 中，然后首先在您的主函数中为AppDomain.CurrentDomain.AssemblyResolve 事件设置一个处理程序。然后尝试通过Reflection加载并执行Foo类；这样，您可以检查文件是否存在并正确反应。之后，只要缺少程序集，事件处理程序就会触发（从 AssemblyC 的直接依赖项开始，在本例中为 Bar 类）。

Answer 4

这是一个猜测，但我尝试过这样的事情：

public class Foo : IDisposable {
private Bar external;
private bool disposed;

public static Foo CreateFoo() {
    Foo foo = new Foo();
    foo.external = new Bar();
    return foo;
}

private Foo() {
}

~Foo() {
    Console.WriteLine("~Foo");
    this.Dispose(false);
}
public void Dispose() {
    this.Dispose(true);
    GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing) {
    if (disposed) return;
    if (disposing) external.Dispose();
    disposed = true;
}

}

该示例将按您的预期工作。

现在我的猜测是：

我认为构造函数不是第一个被调用的方法，当一个对象被创建时。看起来我们无法控制的事情是在调用构造函数之前为创建的对象分配空间，或者类似的事情。 这就是我认为 GC 开始工作的地方。它正在获取 ClassInfo 并知道终结器可用。因此它启动 Finalizer-Thread 并创建分配内存的句柄。 知道将调用构造函数，并且将从该句柄创建对象。 但是在调用构造函数（甚至是方法）之前，会检查此代码块中所有引用类型的可用性。这就是引发 FileNotFoundException 的地方。请注意，这是在您看到调试器进入构造函数之前。 现在我们进入 Finalizer-Thread，它查看它的 Foo 句柄，发现这个句柄不再使用（实际上它从未使用过）。它开始最终确定。这是调用终结器的地方。您访问其中的 Dispose(bool) 方法，这就是将引发第二个 FileNotFoundException 的点，因为您正在访问该方法中的 Bar 类。该异常将在调用它之前引发该晦涩的方法检查。我认为它与一些优化有关，可能引用的类型是延迟加载的。

奇怪的是，当构造函数不会直接抛出异常时，就像在我的例子中一样，GC 会检查这个并且不会调用该对象的终结器。也许我错了，该对象仍在使用中，没有被 GC 收集。

编辑：

最好的解决方案相当简单。从您的课程中删除终结器。您没有使用非托管资源，因此您根本不需要终结器或 Dispose(bool)。

Answer 5

我认为你将不得不重构一些东西。如果不在您的座位上，我们很难知道它在哪里是最合适的 :-) 例如，向所有终结器添加 try catch 对我来说似乎没什么大不了的（例如，您可以使用正则表达式搜索终结器)，但它可能是给你的。

.NET Framework 确实假定您引用的程序集和您使用的类型在运行时就在那里。如果您想要一个更动态的系统，一个插件类型的架构，您需要以不同的方式构建您的程序集和您的类型，例如使用 System.Addin 命名空间或其他库（如 MEF）（参见 SO：Choosing between MEF and MAF (System.AddIn)）

因此，在您的情况下，您可以像这样解决 Foo 中的问题：

public class Foo : IDisposable
{
    // use another specific interface here, like some IBar,
    // this is a sample, so I use IDisposable which I know is implemented by Bar
    private readonly IDisposable external;
    public Foo()
    {
        Console.WriteLine("Foo");
        external = Activator.CreateInstance(Type.GetType("AssemblyB.Bar, AssemblyB")) as IDisposable;
    }

    ... same code    
}

但这也意味着重构......