为什么使用 APM 而不是使用单独的线程？答案

【问题标题】：Why use the APM instead of using a separate thread?为什么使用 APM 而不是使用单独的线程？
【发布时间】：2009-04-10 05:42:38
【问题描述】：

如果我想读取或写入文件，我可以使用 stream.BeginRead 和 stream.EndRead，但这需要回调和大量使用异步编程模型的丑陋、复杂的代码。 p>

我为什么要使用这些异步 IO 方法（在后台使用 .NET 线程池）而不是以同步方式编写相同的代码，然后将那个传递给线程池。（而不是用回调来分割我的方法。）

更新：

一些（好的）响应表明使用 APM 使我免于创建线程 - 我同意这一点，因为每个新线程都有自己的 2MB 堆栈。但是“BeginRead”和“Endread”在哪里执行？线程池？重用已经分配的线程是唯一的好处吗？

【问题讨论】：

【解决方案1】：

首先，您还应该查看Event-based APM。

要回答您的问题，您可能正在考虑使用单独的线程并进行同步调用。另一个线程会阻塞等待调用完成。

使用 APM，根本没有线程阻塞。没有从线程池中抽取。这对于像 ASP.NET 这样的服务器应用程序尤其重要，因为这意味着阻塞线程不会阻止请求被处理。

【讨论】：

我不太明白，你是说一旦我启动 APM 的“BeginOperation”就没有实际使用线程？但是“BeginOperation”的代码实际上在哪里执行呢？此外，“EndOperation”回调必须在某个地方执行 - 如果不是单独的线程，在哪里？
Begin* 代码在调用它的线程上执行，对一些操作进行排队，然后返回。操作完成后，将在池线程上调用回调。在开始和回调之间，不使用线程。做什么的？线程在等待时什么都不做； “没有线程”也没有任何作用。

【解决方案2】：

Jeff Richter 有一个非常聪明和干净的way 来使用 APM。

【讨论】：

【解决方案3】：

使用异步调用的好处是您不会在 I/O 上浪费线程阻塞。线程可能很昂贵，因此在执行大量 I/O 的情况下，明智地使用线程是关键。

也就是说，是的，Begin-End APM 非常难用。如果您确实需要非阻塞 I/O 并且可以灵活地为您的应用程序的一部分使用另一种语言，请尝试 F#。 “异步工作流程”让编写异步代码变得轻而易举。

【讨论】：