backgroundworker执行久后，里面调用函数的处理速度会变慢，如何调整？

[黎大]

背景及问题：

1、winform应用程序。
2、实时大量数据写入，因此后台调用多个backgroundworker对数据进行处理。
3、定时器扫描写入目录，非空后针对每一个子目录处理（子目录中是大量文件，每个文件的处理函数都有try，为防止单个文件处理时间过长，试用task并配置了cancellationToken，超时取消），每个子目录分配一个backgroundworker，每个backgroundworker在处理完子目录中的文件后删除这些文件。
4、刚开始运行这个程序的时候一切都还正常，处理速度挺快，单机每小时处理能力能够达到100GB左右，但是backgroundworker的处理效率会逐渐明显降低，降低的症状会在一天左右显现，日志显示，目录中大量文件不能够及时的处理，被取消处理。

这个问题怎么样才能够解决呢？是backgroundworker的固有问题，还是我业务流程设计的问题呢？
求各位大神指点。谢谢。

[xian_wwq]

1.首先得评估下数据处理能力是否能满足要求， 在没有异常的情况下，生产的数据能否被及时处理； 2.lz强调都加了try...catch 其实在测试期最好不要太多try...catch，很多代码bug会被掩盖， 难以发现或定位问题 backgroudworker本质上就是线程 除非出现异常，否则没有运行越来越慢的道理

[exception92]

每个子目录分配一个backgroundworker，每个backgroundworker在处理完子目录中的文件后删除这些文件。 -》上百个，上千个子目录 就要创建上百，上千个backgroundworker了，这。。。。。。。

[xian_wwq]

除非迫不得已，不要使用多线程轮训， 事件触发是高效简洁的做法

[以专业开发人员为伍]

.net 使用 FileSystemWatcher 来获取目录以及目录下文件改动事件通知。你可以另外弄一个轮询来保证不遗漏任务，但是每10分钟轮询一次所有目录就够了，其它的及时、高效率的处理都应该由 FileSystemWatcher 驱动。

[以专业开发人员为伍]

另外，处理文件内容时应该使用异步方式（跟 FileSystemWatcher 触发事件时所用的线程异步，而不是阻塞它），这样能利用好你的机器资源。

[xuzuning]

问题就在这里： 为防止单个文件处理时间过长，试用task并配置了cancellationToken，超时取消 如果一个文件的处理，会被某个线程做 超时取消 的话，那么对于其他线程，也不会好到哪里去 总是在 处理、超时取消，处理、超时取消，处理、超时取消.... 你说能快的起来吗？ 这是个调度策略问题！ 处理到 超时取消 时，可将未处理完的文件： 1、 移动到特殊处理目录，以后设法处理 2、切割成若干小文件 3、已处理的部分删去，只保留未处理部分

[黎大]

引用 6 楼 xuzuning 的回复:

问题就在这里： 为防止单个文件处理时间过长，试用task并配置了cancellationToken，超时取消 如果一个文件的处理，会被某个线程做 超时取消 的话，那么对于其他线程，也不会好到哪里去 总是在 处理、超时取消，处理、超时取消，处理、超时取消.... 你说能快的起来吗？ 这是个调度策略问题！ 处理到 超时取消 时，可将未处理完的文件： 1、 移动到特殊处理目录，以后设法处理 2、切割成若干小文件 3、已处理的部分删去，只保留未处理部分

切割小文件不太可行啊。。。因为是邮件。调用了cdo组件来处理。 用了adodb的stream，这个close以后还有其他的清理步骤要做吗？

[黎大]

task 使用完毕后，是否需要手动销毁或者清理呢？ 我处理的文件是eml文件，用了windows的cdo类库，stream调用了close后，是否还要自己dispose？

[xuzuning]

超时取消 本身就有蛇足的嫌疑 其实只要做到：正在处理的文件不会再被别人处理，就行了。并不需要限制处理时间

[sunylf]

xuzuning 大神， 麻烦帮我看看　多边形槽切削点算法。 https://bbs.csdn.net/topics/392360519 目前还存在问题。

[bbjiabcd]

很显然，大量硬盘操作时间久了会产生大量文件碎片，导致执行速度下降，建议进行磁盘碎片整理

[大鱼>]

你需要了解一个task的工作机制并用它代替你目前这种工作方式