使用 Dispose() 或终结器来清理托管线程？

Question

假设我有一个 C++0x 中的消息泵类，如下所示（注意，SynchronizedQueue 是函数的队列，当您在队列上调用 receive() 并且它是空的时，它会阻塞调用线程直到有一个项目要返回）：

class MessagePump
{
 private:
    bool done_;
    Thread* thread_;
    SynchronizedQueue queue_;

    void Run()
    {
        while (!done)
        {
            function<void()> msg = queue_.receive();
            msg();
        }
    }
 public:
    MessagePump(): 
        done_(false)
    {
        thread_ = new thread ([=] { this->Run(); } ) );
    }

    ~MessagePump()
    {
        Send( [&]{ done = true; } );
        thread_->join();
    }

    void Send (function<void()> msg)
    {
        queue_.send(msg);
    }
};

我已将此类转换为 C#，但我对析构函数中的代码有疑问。根据 IDisposable 模式，我应该只提供一个 Dispose() 方法来释放托管和非托管资源。

我应该将 C++ 析构函数代码放入：

1. 应用程序退出时客户端需要调用的自定义 CleanUp() 方法吗？如果客户忘记了怎么办？
2. IDisposable 的 Dispose() 方法以便客户端也可以调用它？但话又说回来，如果客户忘记了怎么办？
3. 在 C# 终结器方法中，它总是会执行？我读到，如果您没有任何非托管资源，则不应包含终结器方法，因为它会损害性能。
4. 无处？既然Thread对象是托管资源，就忽略标记done_标志并让GC自然处理它？这样线程会被强制中止吗？

我还发现，如果我不将构造函数内创建的消息泵线程标记为后台线程，我的 MessagePump 对象永远不会被 GC 处理，并且应用程序在退出时只会挂起。这是什么原因呢？

Answer 1

在较高级别上，我只是建议使用 .NET 线程池 (System.Threading.ThreadPool）用于排队和执行多个工作项，因为这就是它的设计目的（假设允许工作项异步执行）。具体来说，请查看 QueueUserWorkItem 方法。

不过，要回答你的问题：

我应该将 C++ 析构函数代码放入：

应用程序退出时客户端需要调用的自定义 CleanUp() 方法？如果客户忘记了怎么办？

IDisposable 的 Dispose() 方法以便客户端也可以调用它？但话又说回来，如果客户忘记了怎么办？

始终更喜欢实现 IDisposable 而不是自定义 CleanUp 方法（在 BCL 中，某些 Stream 类具有一个 Close 方法，该方法是实际上只是 Dispose 的别名）。 IDisposable 模式是使用 C# 进行确定性清理的方法。客户端忘记调用Dispose始终是一个问题，但这通常可以通过静态分析工具（例如FxCop）检测到。

在 C# 终结器方法中，它总是会执行？我读到，如果您没有任何非托管资源，则不应包含终结器方法，因为它会影响性能。

不保证终结器一定会执行（请参阅 这篇文章），因此正确的程序不能假设它们会执行。性能在这里不会成为问题。我猜您最多会有几个 MessagePump 对象，因此拥有终结器的成本微不足道。

无处可去？既然Thread对象是托管资源，就忽略标记done_标志并让GC自然处理它？这样线程会被强制中止吗？

该线程由 CLR 管理，并且会被正确清理。如果线程从其入口点（这里是Run）返回，它不会被中止，它只会干净地退出。不过，这段代码仍然需要到达某个地方，因此我将通过 IDisposable 提供显式清理。

我还发现，如果我不将构造函数内创建的消息泵线程标记为后台线程，我的 MessagePump 对象永远不会被 GC 回收，并且应用程序在退出时只会挂起。这是什么原因？

.NET 应用程序将一直运行，直到所有前台（非后台）线程终止。因此，如果您不将 MessagePump 线程标记为后台线程，它将使您的应用程序在运行时保持活动状态。如果某个对象仍然引用您的 MessagePump，则 MessagePump 将永远不会被 GC 处理或最终确定。不过，再次参考上面的文章，您不能假设终结器将会运行。

Answer 2

一种可能有用的模式是让消息泵的外部用户持有对“仍在使用”标志对象的强引用，泵本身仅持有一个弱引用（一旦对象的“仍在使用”，该引用就会失效）使用中”有资格最终确定）。该对象的终结器可能能够向消息泵发送消息，并且消息泵可以检查其弱引用的持续有效性；如果它变得无效，则消息泵可能会关闭。

请注意，消息泵的一个常见困难是操作消息泵的线程往往会保持大量对象处于活动状态，而这些对象除了该线程之外什么都没有使用。我们需要一个单独的对象，线程将避免对该对象保留强引用，以确保可以清理事物。