问如何为多个文件处理选择最佳的I/O策略？

EN

最好的方法是编写一个简单的Task类，它可以独立完成整个操作(读、处理、写)，这样就不会与外部的、线程不安全的操作有任何联系。然后使用一个任务队列，其中固定数量的线程可以获取这些任务并处理它们。很多线程通常是核心* 2。

可以从数学上证明，选项2总是等于或慢于基于任务的解决方案，而且在任何情况下都会更加复杂。唯一选项2更可行的情况是线程切换成为实际的瓶颈。也就是说，如果您的服务器具有类似于1000个并发但有状态的连接，但只有一个网卡，那么让一个网络线程为1000个处理线程提供信息，而不是唤醒通过行发送的每一个字节上的1000个线程，就更有效了。

基于任务的解决方案还使度量吞吐量和比较其他线程如何影响吞吐量变得更加容易，因为您可以简单地以任务/秒来度量。

最简单的有效解决方案可能是只有一个读取器线程，其优先级低于默认优先级。如果有一个免费的CPU核心，它就可以运行。这将创建一个工作线程(处理一个输入文件并将其写回)。当这些线程以默认优先级运行时，这将实现自平衡。当所有CPU都忙于处理文件时，读取器线程将没有多少CPU时间，因此生成的新工作线程不多。

分离文件处理并将它们写回磁盘没有真正的意义；这只会产生大量未写入的工作排队在内存中的可能性。

这两种方法各有优缺点。

单读取器

1. pro:从处理中提供良好的学术抽象层，并可能最终形成一个更好的编程模型。
2. pro:而且，如果您可以为所有其他线程提供作业(如果处理过程比读取操作慢得多)，并且文件系统不是零碎的，那么您就可以更好地利用系统。
3. con：#2很难实现，所以最有可能的是这个优势不会存在。
4. con:更难编程，您需要一个fifo或其他队列和顶部的同步。

处理线程中的读取：

1. 支持:易于实现，不需要队列或同步。
2. pro:更好的工作在碎片化的文件系统中:多个io请求可以通过os或硬件进行优化，以减少延迟。此外，延迟较低的请求将更快地启动处理，无论在单个阅读器中，无论发生什么情况，您都必须等待。
3. pro:读取操作本身有一个非系统部分，它也可以在线程中运行，并且是并行处理的一部分。
4. con:可能会在非碎片化系统中松散，因为它增加了一些类似碎片的行为。

顺便说一句，有更多可能的处理方案。您忘记提到的一个是有一个编写线程，其中您的处理转储将导致队列，并让后台进程编写它。这可能会给你带来额外的刺激。没有必要让每个线程都等待写入。

您还可以使用在一个队列中写入的并行读取器，而不是这个队列中的处理(甚至更复杂的编程:-)，但在某些情况下可以工作。

平行作家也可以工作。

此外，还可以在不同的本地磁盘(不是目录，而是物理磁盘)之间分发文件。如果并行执行，这肯定会提高您的读/写性能。