在后台线程中创建可冻结对象时资源泄漏

Question

在我的应用程序中，我在后台（线程池）线程中创建 Freezable 对象，冻结它们，然后在主线程上显示它们。一切正常，除了一段时间后，整个系统变得迟缓，应用程序最终崩溃。

我已经设法将问题减少到这一行：

var temp = new DrawingGroup();

如果您在不同的后台（非 UI）线程上运行得足够频繁，整个系统就会变得迟缓，最终应用程序崩溃。

（在我的真实应用程序中，然后我在这个对象上绘制一些东西，冻结它，然后在主线程上显示它，但这不是重现问题所必需的。）

重现该问题的完整代码（复制到默认的空白 wpf 应用程序中）：

public partial class MainWindow : Window
{
    private DispatcherTimer dt;

    public MainWindow()
    {
        InitializeComponent();

        dt = new DispatcherTimer();
        dt.Interval = TimeSpan.FromSeconds(0.1);
        dt.Tick += dt_Tick;
        dt.IsEnabled = true;
    }

    private int counter = 0;
    void dt_Tick(object sender, EventArgs e)
    {
        for (int i = 0; i < 100; i++)
        {
            var thread = new Thread(MemoryLeakTest);
            thread.Start();
        }

        Title = string.Format("Mem leak test {0}", counter++);

    }

    private void MemoryLeakTest()
    {
        try
        {
            var temp = new DrawingGroup();
            temp.Freeze();
        }
        catch (Exception e)
        {
            dt.IsEnabled = false;
            MessageBox.Show(e.Message+Environment.NewLine+e.StackTrace);
        }
    }
}

在约 150 次计时器运行后（即在短时间内创建了大约 15000 个线程后），我得到了这个异常：

Not enough storage is available to process this command
   bei MS.Win32.HwndWrapper..ctor(Int32 classStyle, Int32 style, Int32 exStyle, Int32 x, Int32 y, Int32 width, Int32 height, String name, IntPtr parent, HwndWrapperHook[] hooks)
   bei System.Windows.Threading.Dispatcher..ctor()
   bei System.Windows.DependencyObject..ctor()
   bei System.Windows.Media.DrawingGroup..ctor()
   bei WpfApplication5.MainWindow.MemoryLeakTest() in ...

我认为正在发生的事情是这样的：

1. DrawingGroup 派生自DependencyObject，DependencyObject 的构造函数使用Dispatcher.CurrentDispatcher，然后为该线程创建一个新的Dispatcher。
2. 新的调度程序分配了一些 Win32 资源。
3. 在 Reflector 中查看 HwndWrapper 的终结代码，我认为 HwndWrapper 尝试使用 Dispatcher.BeginInvoke 同步它自己的清理。
4. 由于此后台线程从不启动消息循环，因此将永远不会调用清理代码 => 资源泄漏

有没有办法解决或解决这个问题？

到目前为止我所尝试的：

• 显然，使用ThreadPool 或Tasks 而不是手动创建线程会延迟此问题。但是ThreadPool 也会随着时间的推移创建和关闭新线程，因此只会延迟问题，而不是解决方案。
• 在每个线程结束时强制进行完整的 GC 收集并没有改变任何东西。这与垃圾收集的不确定性无关。
• 在后台线程结束时手动调用Dispatcher.InvokeShutdown 似乎可行，但我不知道如何确保在每个ThreadPool 线程结束时调用它。不用写我自己的ThreadPool，那就是……

Answer 1

这是 .NET 中 Dispatcher 系统设计的一个已知缺陷。它会影响依赖于 Dispatcher 的 WPF 和非 WPF 库。 Microsoft 已表示不会修复此问题。

它与使用冻结操作或任何操作无关。任何从DependencyObject 派生的对象（类）都将有一个基础构造函数，它会触发为该线程创建Dispatcher 实例（如果它没有） t 之前创建的。换句话说，Dispatcher 在设计上是一个线程局部单例。

当Dispatcher 的足够多（数万个）实例被泄露时，就会发生崩溃。这意味着在应用程序的生命周期中创建和销毁了相同数量的线程，每个线程都创建了一个或多个DependencyObject。询问任何应用程序开发人员，他们会说不常见，虽然本身还不错，但肯定需要特别小心来设计一个有很多线程的应用程序已被创建和销毁。

---

在开始之前，这是一种查询Dispatcher 的安全方法，如果之前不存在，则不会自动创建它。

Thread currentThread = Thread.CurrentThread;
Dispatcher currentDispatcherOrNull = Dispatcher.FromThread(currentThread);

MSDN: Dispatcher.FromThread method

---

首先，您可以在完成线程后关闭调度程序。

MSDN: Dispatcher.InvokeShutdown method

---

其次，意识到一旦它被一个线程关闭，就不可能为同一个线程重新初始化Dispatcher。换句话说，在InvokeShutdown 之后，不可能在该线程上使用WPF 或任何其他依赖于Dispatcher 的库。线程被有效地毒死了。

---

结合第一点和第二点可以得出结论，您需要自己的线程池，每个线程池都被赋予了Dispatcher。只要控制好线程池的wind down，就没有泄露的危险。

---

有一些流行的开源 .NET 线程池库可以与 .NET 系统线程池一起（独立于）运行。这是解决此特定平台问题的适当方法。

---

如果您同时控制前端（表示层）和后端（图像渲染），则有一个更简单、更严格、更有效 （尽管未充分利用）方法：

• 使调用者必须初始化 Dispatcher 成为一项策略；后端只会检查调度程序已经存在（通过Dispatcher.FromThread），并且拒绝工作 如果不是。

这种方法将负担转移到表示层，具有讽刺意味的是，它往往已经初始化了 Dispatcher。

这种方法也适用于一个线程池。

Answer 2

您使用TPL 或ThreadPool 运行此逻辑是否正确？
如果是这样，并且您可以选择最后一种情况，您可以轻松获取DrawingGroup 的Dispatcher 属性，并在finally 块中调用它的InvokeShutdown 方法。

所以你可以这样写：

DrawingGroup temp;
try
{
    temp = new DrawingGroup();
}
finally
{
    // do the work
    if (temp != null)
    {
        temp.Dispatcher.InvokeShutdown();
    }
}