为什么使用JpegBitmapDecoder的LongRunning任务（TPL）资源耗尽？
我们有一个托管的.Net / C＃应用程序，可以创建TPL任务来对JPEG图像执行JPEG元数据编码。 每个任务都使用TaskCreationOptions.LongRunning选项构建，例如，
Task task = new Task( () => TaskProc(), cancelToken, TaskCreationOptions.LongRunning ); TaskProc（）利用JpegBitmapDecoder和JpegBitmapEncoder类添加JPEG元数据并将新图像保存到磁盘。 我们允许在任何时间最多激活2个此类任务，此过程应无限期地继续。
执行上述操作一段时间后，我们得到了足够的存储空间来处理此命令exception时尝试创建JpegBitmapDecoder类的实例：
System.ComponentModel.Win32Exception（0x80004005）：没有足够的存储空间可用于在MS.Win32.UnsafeNativeMethods.RegisterClassEx（WNDCLASSEX_D wc_d）处理此命令
在System.Windows.Threading的MS.Win32.HwndWrapper..ctor（Int32 classStyle，Int32 style，Int32 exStyle，Int3 2 x，Int32 y，Int32 width，Int32 height，String name，IntPtr parent，HwndWrapperHoo k [] hooks） System.Windows上的System.Windows.Threading.Dispatcher.get_CurrentDispatcher（）处于System.Windows的System.Windows.Media.Imaging.BitmapDecoder..ctor（Stream bitmapStream，BitmapC reateOptions createOptions，BitmapCacheOption cacheOption，Guid expectedClsId）中的.Dispatcher..ctor（） .Media.Imaging.JpegBitmapDecoder..ctor（流bitmapStream，Bit mapCreateOptions createOptions，BitmapCacheOption cacheOption）
仅当我们使用JpegBitmapDecoder添加元数据时才会发生错误。 换句话说，如果任务只是编码并将Bitmap图像保存到文件，则不会出现任何问题。 使用Process Explorer，Process Monitor或其他诊断工具时，没有显示任何明显的信息。 根本没有观察到线程，内存或句柄泄漏。 发生此类错误时，不会启动任何新应用程序，例如记事本，文字等。一旦我们的应用程序终止，一切都会恢复正常。
LongRunning的任务创建选项在MSDN中定义为指定任务将是长时间运行的粗粒度操作。 它向TaskScheduler提供了一个提示，即可以保证超额订阅。 这意味着选择运行任务的线程可能不是来自ThreadPool，即，它将为任务的目的而创建。 其他任务创建选项将导致为任务选择ThreadPool线程。
经过一段时间的分析和测试，我们将任务创建选项更改为除LongRunning之外的任何其他选项，例如PreferFairness 。 根本没有对代码进行任何其他更改。 这“解决”了问题，即不再耗尽存储错误。
我们对LongRunning线程成为罪魁祸首的实际原因感到困惑。 以下是我们对此的一些问题：
-
为什么选择执行任务的线程来自ThreadPool？ 如果线程终止，那么它的资源是否应该由GC随时间回收并返回操作系统，而不管其来源如何？
-
LongRunning任务和导致错误的JpegBitmapDecoderfunction的组合有什么特别之处？
System.Windows.Media.Imaging命名空间中的类基于Dispatcher线程体系结构 。 对于更好或更坏的部分默认行为，只要某个组件通过静态Dispatcher.Current属性请求当前调度程序，就会在任何正在执行的线程上启动新的Dispatcher 。 这意味着为线程启动了整个Dispatcher“运行时”，并且分配了所有类型的资源，如果没有正确清理，将导致管理泄漏。 Dispatcher “运行时”还期望其执行的线程是一个STA线程，标准消息泵送正在进行，并且Task运行时默认情况下不启动STA线程。
那么，所有这一切，为什么会发生在LongRunning而不是“常规”基于ThreadPool的线程？ 原因LongRunning意味着您每次都会启动一个新线程，这意味着每次都会有新的Dispatcher资源。 最终，如果让默认任务调度程序（基于ThreadPool的程序）运行得足够长，它也会耗尽空间，因为没有任何东西可以为Dispatcher运行时提供消息，以便能够清理它所需要的东西。
因此，如果你想使用像这样的基于Dispatcher -thread的类，你真的需要使用一个自定义TaskScheduler ，它可以在正确管理Dispatcher “runtime”的线程池上运行那种工作。 好消息是你运气好，因为我已经写了一个你可以抓到的 。 FWIW，我在三个非常大量的生产代码中使用这个实现，每天处理数十万个图像。
实施更新
我最近再次更新了实现，因此它与.NET 4.5的新asyncfunction兼容。 最初的实现与SynchronizationContext概念没有合作，因为它不一定是。 现在您可能在Dispatcher线程上执行的方法中使用C＃中的await关键字，我需要能够与之配合。 之前的实现会在这种情况下陷入僵局，这个最新的实现没有。
我可以自己重现并修复这个问题，同时从Uri构造BitmapSource对象。 与您一样，只有在TaskCreationOptions.LongRunning时才会出现。
为了避免在这种特殊情况下泄漏，我发现您可以在实例化所需的WPF对象后立即关闭Dispatcher。
这是我的TaskProc的工作实现：
private static BitmapImage TaskProc() { var result = new BitmapImage(new Uri(@"c:\test.jpg")); // the following line fixes the problem, no more leaks occur result.Dispatcher.InvokeShutdown(); return result; }