BackgroundWorker ReportProgress 事件队列答案

【问题标题】：BackgroundWorker ReportProgress event queueBackgroundWorker ReportProgress 事件队列
【发布时间】：2012-07-16 17:52:02
【问题描述】：

我有一个 BackgroundWorker，它以 1 秒的间隔监控文件夹中的文件。如果找到文件，则为每个找到的文件引发 ReportProgress(0, fileName)。

在主线程上，我订阅该事件并处理每个文件。

这是：一个找到的文件 = 一个引发的事件 = 一个已处理的文件

如果主线程很慢，我的问题是关于排队事件。例如，“文件观察者”每秒可以找到并引发 1000 个事件，但在处理每个文件的主线程上需要 1 秒。所以事件是排队的。

.NET 中的这种排队有什么限制吗？

谢谢，巴特克

【问题讨论】：

您可以使用FileSystemWatcher class 代替后台工作人员吗？
FileSystemWatcher 在发生频繁/重大变化时不可靠。更改它的内部缓冲区可能会有所帮助，但它也有一个硬性限制。

标签： c# .net backgroundworker

【解决方案1】：

没有主线程会最终处理所有文件。但是，如果您有某种 GUI，我建议您在单独的线程上进行处理。

【讨论】：

这是一个 Windows 服务，所以应该没问题。我只是想知道是否不会错过任何事情，但正如你所说，这看起来还可以。谢谢
@bodziec 您的所有事件都应该得到处理，除非在处理过程中当然发生异常。但是，有几种方法可以处理这种情况。

【解决方案2】：

BackgroundWorker 在内部使用 SynchronizationContext 到 Post 异步消息。如果是 GUI 线程启动 BW，它会使用专门的 WinForms SynchronizationContext 并使用消息循环向该主线程报告进度。

在您的情况下，它是一个 Windows 服务线程，因此没有 SynchronizationContext。发生的情况是默认 SynchronizationContext 被实例化并使用。然后行为完全不同，新的ThreadPool 用于异步消息。因此，您的文件处理将在由该内部ThreadPool 启动的单独线程中进行，而不是在 WinForms 中的主线程中。

虽然ThreadPool 应该正确处理大型队列（无法立即找到任何对 ThreadPool 队列大小的硬性限制 - 有人知道吗？），但要知道在这种模式下您不能假设确定性顺序文件处理。

【讨论】：

据我所知，ThreadPool 队列没有硬性限制。唯一的限制是机器有足够的资源来处理负载。