计算机能同时做多件事的唯一方法是(1)实际上同时做多件事，(2)通过调度任务和在任务之间切换来模拟它。如果async-await两者都不做

It's not that await does neither of those. Remember, the purpose of await is not to make synchronous code magically asynchronous. It's to enable using the same techniques we use for writing synchronous code when calling into asynchronous code. Await is about making the code that uses high latency operations look like code that uses low latency operations. Those high latency operations might be on threads, they might be on special purpose hardware, they might be tearing their work up into little pieces and putting it in the message queue for processing by the UI thread later. They're doing something to achieve asynchrony, but they are the ones that are doing it. Await just lets you take advantage of that asynchrony.

Also, I think you are missing a third option. We old people -- kids today with their rap music should get off my lawn, etc -- remember the world of Windows in the early 1990s. There were no multi-CPU machines and no thread schedulers. You wanted to run two Windows apps at the same time, you had to yield. Multitasking was cooperative. The OS tells a process that it gets to run, and if it is ill-behaved, it starves all the other processes from being served. It runs until it yields, and somehow it has to know how to pick up where it left off the next time the OS hands control back to it. Single-threaded asynchronous code is a lot like that, with "await" instead of "yield". Awaiting means "I'm going to remember where I left off here, and let someone else run for a while; call me back when the task I'm waiting on is complete, and I'll pick up where I left off." I think you can see how that makes apps more responsive, just as it did in the Windows 3 days.

调用任何方法都意味着等待该方法完成

这就是你所缺少的关键。方法可以在其工作完成之前返回。这就是异步的本质。方法返回，它返回一个任务，表示“这项工作正在进行中;完工后告诉我该做什么。”方法的工作没有完成，即使它已经返回。

在使用await操作符之前，您必须编写看起来像意大利面穿过瑞士奶酪的代码，以处理在完成之后还有工作要做，但返回和完成不同步的情况。Await允许您编写看起来像返回和完成是同步的代码，而实际上它们并没有同步。

实际上，async/await并没有那么神奇。整个话题相当广泛，但对于你的问题，我认为我们可以快速而完整地回答。

让我们在Windows窗体应用程序中处理一个简单的按钮点击事件:

public async void button1_Click(object sender, EventArgs e)
{
    Console.WriteLine("before awaiting");
    await GetSomethingAsync();
    Console.WriteLine("after awaiting");
}

我将明确不讨论GetSomethingAsync返回的是什么。假设这是一个在2秒后就能完成的任务。

在传统的非异步环境中，你的按钮点击事件处理程序是这样的:

public void button1_Click(object sender, EventArgs e)
{
    Console.WriteLine("before waiting");
    DoSomethingThatTakes2Seconds();
    Console.WriteLine("after waiting");
}

当您单击表单中的按钮时，应用程序将冻结大约2秒，而我们等待此方法完成。结果是“消息泵”(基本上是一个循环)被阻塞了。

这个循环不断地问窗口“有人做了什么吗，比如移动了鼠标，点击了什么?”我需要重新粉刷吗?如果是，请告诉我!”然后处理这些“事情”。这个循环得到一条消息，用户点击了“button1”(或者来自Windows的等效类型的消息)，并最终调用上面的button1_Click方法。在此方法返回之前，这个循环现在一直在等待。这需要2秒，在此期间，没有消息被处理。

Most things that deal with windows are done using messages, which means that if the message loop stops pumping messages, even for just a second, it is quickly noticeable by the user. For instance, if you move notepad or any other program on top of your own program, and then away again, a flurry of paint messages are sent to your program indicating which region of the window that now suddenly became visible again. If the message loop that processes these messages is waiting for something, blocked, then no painting is done.

那么，如果在第一个例子中，async/await不创建新线程，它是如何做到的呢?

你的方法被分成了两个。这是一个宽泛的主题类型的东西，所以我不会讲得太详细，但足以说明该方法分为以下两部分:

所有导致await的代码，包括对GetSomethingAsync的调用 接下来的所有代码都在等待

说明:

code... code... code... await X(); ... code... code... code...

重新安排:

code... code... code... var x = X(); await X; code... code... code...
^                                  ^          ^                     ^
+---- portion 1 -------------------+          +---- portion 2 ------+

基本上这个方法是这样执行的:

It executes everything up to await It calls the GetSomethingAsync method, which does its thing, and returns something that will complete 2 seconds in the future So far we're still inside the original call to button1_Click, happening on the main thread, called from the message loop. If the code leading up to await takes a lot of time, the UI will still freeze. In our example, not so much What the await keyword, together with some clever compiler magic, does is that it basically something like "Ok, you know what, I'm going to simply return from the button click event handler here. When you (as in, the thing we're waiting for) get around to completing, let me know because I still have some code left to execute". Actually it will let the SynchronizationContext class know that it is done, which, depending on the actual synchronization context that is in play right now, will queue up for execution. The context class used in a Windows Forms program will queue it using the queue that the message loop is pumping. So it returns back to the message loop, which is now free to continue pumping messages, like moving the window, resizing it, or clicking other buttons. For the user, the UI is now responsive again, processing other button clicks, resizing and most importantly, redrawing, so it doesn't appear to freeze. 2 seconds later, the thing we're waiting for completes and what happens now is that it (well, the synchronization context) places a message into the queue that the message loop is looking at, saying "Hey, I got some more code for you to execute", and this code is all the code after the await. When the message loop gets to that message, it will basically "re-enter" that method where it left off, just after await and continue executing the rest of the method. Note that this code is again called from the message loop so if this code happens to do something lengthy without using async/await properly, it will again block the message loop

There are many moving parts under the hood here so here are some links to more information, I was going to say "should you need it", but this topic is quite broad and it is fairly important to know some of those moving parts. Invariably you're going to understand that async/await is still a leaky concept. Some of the underlying limitations and problems still leak up into the surrounding code, and if they don't, you usually end up having to debug an application that breaks randomly for seemingly no good reason.

使用Async和Await进行异步编程(c#和Visual Basic) SynchronizationContext类 Stephen Cleary -没有一篇文章值得一读! 频道9 - Mads Torgersen: c# Async内幕值得一看!

---

那么，如果GetSomethingAsync启动一个将在2秒内完成的线程呢?是的，很明显有新的线索。然而，这个线程并不是因为这个方法的异步性，而是因为这个方法的程序员选择了一个线程来实现异步代码。几乎所有的异步I/O都不使用线程，它们使用不同的东西。Async /await本身不会启动新的线程，但显然“我们等待的东西”可以使用线程实现。

.NET中有许多东西不一定会自己启动线程，但仍然是异步的:

Web请求(以及许多其他需要时间的与网络相关的事情) 异步文件读写 还有更多，如果有问题的类/接口有名为SomethingSomethingAsync或BeginSomething和EndSomething的方法，并且有一个IAsyncResult涉及，这是一个好迹象。

通常这些东西在引擎盖下不使用线程。

---

好吧，所以你想要一些“广泛话题的东西”?

好吧，让我们问问Try Roslyn关于我们的按钮点击:

尝试Roslyn

我不打算在这里链接完整的生成类，但这是相当血腥的东西。

以下是我对这一切的看法，它在技术上可能不是超级准确，但至少对我有帮助:)。

机器上基本上有两种类型的处理(计算):

发生在CPU上的处理 在其他处理器(GPU，网卡等)上发生的处理，让我们称之为IO。

因此，当我们编写一段源代码时，在编译之后，根据我们使用的对象(这是非常重要的)，处理将受到CPU或IO的限制，事实上，它可以绑定到两者的组合。

一些例子:

如果我使用FileStream对象(它是一个流)的Write方法，处理将会说，1%的CPU绑定和99%的IO绑定。 如果我使用NetworkStream对象(它是一个流)的写方法，处理将会说，1%的CPU绑定，和99%的IO绑定。 如果我使用Memorystream对象(这是一个流)的写方法，处理将是100% CPU的限制。

因此，如您所见，从面向对象程序员的角度来看，尽管我总是访问Stream对象，但下面发生的事情可能在很大程度上取决于对象的最终类型。

现在，为了优化事情，如果可能和/或必要的话，有时能够并行运行代码(注意我不使用异步这个词)是有用的。

一些例子:

在桌面应用程序中，我想打印一个文档，但我不想等待它。 我的web服务器同时为许多客户端提供服务，每个客户端并行获取他的页面(不是序列化的)。

在async / await之前，我们基本上有两个解决方案:

线程。它相对容易使用，有Thread和ThreadPool类。线程只受CPU限制。 “旧的”Begin/End/AsyncCallback异步编程模型。这只是一个模型，它并没有告诉你你将会受到CPU或IO的限制。如果你看一下Socket或FileStream类，它是IO绑定的，这很酷，但我们很少使用它。

async / await只是一个基于Task概念的通用编程模型。对于CPU绑定的任务，它比线程或线程池更容易使用，而且比旧的Begin/End模型更容易使用。 然而，它“只是”一个超级复杂的功能齐全的包装。

因此，真正的胜利主要是在IO绑定任务上，不使用CPU的任务，但async/await仍然只是一个编程模型，它不能帮助你确定处理最终如何/在哪里发生。

这意味着它不是因为一个类有一个方法“DoSomethingAsync”返回一个任务对象，你可以假设它将是CPU绑定(这意味着它可能非常无用，特别是如果它没有取消令牌参数)，或IO绑定(这意味着它可能是必须的)，或两者的组合(因为模型是相当病毒式传播的，绑定和潜在的好处可以，最终，超级混合，不那么明显)。

所以，回到我的例子，在MemoryStream上使用async/await进行写操作将保持CPU限制(我可能不会从中受益)，尽管我肯定会从文件和网络流中受益。

我真的很高兴有人问这个问题，因为很长一段时间以来，我也认为线程对于并发性是必要的。当我第一次看到事件循环时，我以为它们是谎言。我对自己说:“如果这段代码在一个线程中运行，它就不可能是并发的”。请记住，这是在我已经经历了理解并发性和并行性之间区别的斗争之后。

经过我自己的研究，我终于找到了缺失的部分:select()。具体来说，IO多路复用，由不同的内核以不同的名称实现:select()， poll()， epoll()， kqueue()。这些是系统调用，尽管实现细节不同，但允许您传入一组文件描述符进行监视。然后，您可以进行另一个调用，该调用将阻塞，直到被监视的文件描述符之一发生变化。

因此，可以等待一组IO事件(主事件循环)，处理第一个完成的事件，然后将控制权交还给事件循环。清洗并重复。

这是如何工作的呢?简而言之，这是内核和硬件级的魔力。计算机中除了CPU之外还有许多组件，这些组件可以并行工作。内核可以控制这些设备，并直接与它们通信以接收特定的信号。

这些IO多路复用系统调用是单线程事件循环(如node.js或Tornado)的基本构建块。当您等待一个函数时，您正在观察某个事件(该函数的完成)，然后将控制权交还给主事件循环。当您正在观看的事件完成时，函数(最终)从它停止的地方开始。允许像这样暂停和恢复计算的函数称为协程。

我在我的博客文章《There Is No Thread》中详细解释了这一点。

In summary, modern I/O systems make heavy use of DMA (Direct Memory Access). There are special, dedicated processors on network cards, video cards, HDD controllers, serial/parallel ports, etc. These processors have direct access to the memory bus, and handle reading/writing completely independently of the CPU. The CPU just needs to notify the device of the location in memory containing the data, and then can do its own thing until the device raises an interrupt notifying the CPU that the read/write is complete.

一旦操作在运行中，CPU就没有工作要做，因此没有线程。

总结其他答案:

Async/await通常是为IO绑定任务创建的，因为通过使用它们，调用线程不需要被阻塞。这在UI线程的情况下特别有用，因为我们可以确保它们在执行后台操作时保持响应(比如从远程服务器获取数据)。

Async不创建自己的线程。调用方法的线程用于执行异步方法，直到它找到一个可等待对象。然后，同一线程继续执行异步方法调用之外的调用方法的其余部分。注意，在被调用的async方法中，从awaitable返回后，该方法的提醒可以使用线程池中的线程执行——这是唯一出现单独线程的地方。