我读过the article on copying streams asynchronously。 我注意到只有一个缓冲区用于读/写。
使用异步调用进行流复制对我有什么好处？
由于只有一个缓冲区，您的异步解决方案在运行时似乎非常同步。 写入必须等待读取，而下一次读取必须等到缓冲区被写入。
一些想法：
我见过使用多个缓冲区的变体。 恕我直言，这只会使事情变得更复杂，使用更多内存并推迟问题。 它允许在一定程度上并行进行多次读取。
对于文件，我可以想象一个更轻松的写入解决方案：读取时写入一个块，并在读取所有文件时修复顺序。 （文件系统必须支持）。
我阅读这篇文章是因为我正在使用 .NET 3.5，但还不能使用 .NET 4 或 4.5。
（Microsoft dot com adres 的 netqa 反弹）
【问题讨论】：
标签： .net file-io asynchronous streaming
当您处理与 CPU 无关的延迟并希望避免那些没有跨越大量线程的延迟时（这不能很好地扩展 - 每个 CPU 不应该有太多线程，因为线程是“昂贵”的资源，丰富的上下文切换会影响你的表现）。
因此，IO 操作是典型的受益者，因为与处理数据所需的计算工作相比，磁盘和网络都“慢”。因此，当您可能有许多并行流（网络和磁盘）时，您应该使用异步操作来处理它们。
也就是说，正确的异步编程很难，尤其是没有新的 .NET 编译器的内置支持。
一个好的异步副本应该至少使用两个缓冲区；一个读取数据（异步），一个同时写入数据（异步）。当然，空闲的写入器只会在读取器完成其块后才会启动，而空闲的读取器只会在至少有一个空闲缓冲区（例如写入器完成写入）时才会启动。当您只有一个缓冲区时，连续读取和写入操作之间会有中断，例如它将始终是“读、写、读、...写”，而不是“读、读+写、读+写、...写”。
【讨论】：
写入必须等待读取
当然可以。如果你还没有读取数据，你会写什么？
下一次读取必须等到缓冲区被写入。
在某些情况下避免这种情况可能是有意义的，但您确实需要对此进行分析。各种缓存以及从硬盘读取和写入数据的方式可能会影响这一点。如果有一些性能优势，它可能不会很大。
现在是您的主要问题：
使用异步调用进行流复制对我有什么好处？
收益来自于您没有阻塞任何线程，而 IO 发生。这对性能很重要，因为线程是昂贵的资源（除此之外，每个都需要 1 MB 的虚拟和物理内存）。这在像 ASP.NET 这样的环境中会产生巨大的差异，每个请求都由不同的线程处理。
如果您正在编写一个只复制几个文件的桌面应用程序，这对您来说可能无关紧要，只要您不阻塞 UI 线程。
【讨论】：