如何处理异步 I/O 方法

Question

在阅读了大量有关 async-await 的内容后，我只能找到在 GUI 线程（WPF/WinForms）中使用它的好处。

它在哪些场景下会减少 WCF 服务中线程的创建？ 程序员是否必须通过选择在 Web 服务中实现 async-await 来对服务中的每个方法使用 async-await ？在充满 async-await 的服务中制作一些非 async-await 方法会降低我的服务效率吗？如何？

最后一个问题 - 有人说使用 'await Task.Run(()=>...)' 不是“真正的异步等待”。他们这样说是什么意思？

提前致谢，斯塔夫。

编辑：

两个答案都很好，但对于 async-await 的工作原理，我建议您阅读 @Stephen Cleary 的答案：https ://stackoverflow.com/a/7663734/806963

理解他的回答需要以下主题：SynchronizationContext,SynchronizationContext.Current,TaskScheduler,TaskScheduler.Current,Threadpool。

Answer 1

服务器应用程序（如 WCF）中 async/await 的真正好处是异步 I/O。

当您调用同步 I/O 方法时，调用线程将被阻塞，等待 I/O 完成。该线程不能被其他请求使用，它只是等待结果。当更多请求到达时，线程池将创建更多线程来处理它们，浪费大量资源 - 内存，等待线程被解除阻塞时的上下文切换......

如果使用异步 IO，线程不会被阻塞。启动异步 IO 操作后，它再次可供线程池使用。当异步操作完成后，线程池分配一个线程继续处理请求。没有浪费资源。

来自MSDN（关于文件 I/O，但也适用于其他）

在同步文件 I/O 中，线程开始 I/O 操作并立即进入等待状态，直到 I/O 请求完成。执行异步文件 I/O 的线程通过调用适当的函数向内核发送 I/O 请求。如果请求被内核接受，调用线程将继续处理另一个作业，直到内核向线程发出 I/O 操作已完成的信号。然后它会中断其当前作业并根据需要处理来自 I/O 操作的数据。

现在您可能会明白，await Task.Run()如果任务中的 IO 是同步完成的，为什么不会带来任何好处。一个线程无论如何都会被阻塞，只是不是调用Task.Run().

您不需要异步实现每个方法来查看性能的改进（尽管始终异步执行 I/O 应该成为一种习惯）。