实际上，异步等待链是由CLR编译器生成的状态机。

async await使用的线程是TPL使用线程池执行任务的线程。

应用程序没有被阻塞的原因是状态机可以决定执行哪个协同例程、重复、检查并再次决定。

进一步阅读:

异步和等待生成什么?

异步等待和生成的状态机

异步c#和f# (III.):它是如何工作的?-托马斯·佩特里塞克

编辑:

好的。看来我的阐述是不正确的。然而，我必须指出，状态机是异步等待的重要资产。即使你采用异步I/O，你仍然需要一个助手来检查操作是否完成，因此我们仍然需要一个状态机，并确定哪些例程可以一起异步执行。

实际上，异步等待链是由CLR编译器生成的状态机。

async await使用的线程是TPL使用线程池执行任务的线程。

应用程序没有被阻塞的原因是状态机可以决定执行哪个协同例程、重复、检查并再次决定。

进一步阅读:

异步和等待生成什么?

异步等待和生成的状态机

异步c#和f# (III.):它是如何工作的?-托马斯·佩特里塞克

编辑:

好的。看来我的阐述是不正确的。然而，我必须指出，状态机是异步等待的重要资产。即使你采用异步I/O，你仍然需要一个助手来检查操作是否完成，因此我们仍然需要一个状态机，并确定哪些例程可以一起异步执行。

计算机能同时做多件事的唯一方法是(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允许您编写看起来像返回和完成是同步的代码，而实际上它们并没有同步。

await和异步使用任务而不是线程。

框架有一个线程池，准备以Task对象的形式执行一些工作; 向池提交任务意味着选择一个已经存在的空闲线程来调用任务 操作方法。 创建一个任务就是创建一个新对象，远远快于创建一个新线程。

如果Task可以附加一个Continuation，那么它就是一个要执行的新Task对象 一旦线程结束。

因为async/await使用任务，它们不会创建一个新的线程。

虽然中断编程技术在每个现代操作系统中都被广泛使用，但我不认为它们是 有关。 你可以让两个CPU绑定任务在一个CPU上并行执行(实际上是交错执行) aysnc /等待。 这不能简单地用操作系统支持排队IORP的事实来解释。

上次我检查了编译器将异步方法转换为DFA，工作分为几个步骤， 每一个都以等待指令结束。 await启动它的Task，并为它附加一个continuation以执行下一个任务 的一步。

作为一个概念示例，下面是一个伪代码示例。 为了清晰起见，事情被简化了，因为我不记得所有的细节。

method:
   instr1                  
   instr2
   await task1
   instr3
   instr4
   await task2
   instr5
   return value

它会变成这样

int state = 0;

Task nextStep()
{
  switch (state)
  {
     case 0:
        instr1;
        instr2;
        state = 1;

        task1.addContinuation(nextStep());
        task1.start();

        return task1;

     case 1:
        instr3;
        instr4;
        state = 2;

        task2.addContinuation(nextStep());
        task2.start();

        return task2;

     case 2:
        instr5;
        state = 0;

        task3 = new Task();
        task3.setResult(value);
        task3.setCompleted();

        return task3;
   }
}

method:
   nextStep();

1实际上，一个池可以有自己的任务创建策略。

我试着从下往上解释。也许有人会觉得有用。 我在那里，做了，重新发明了它，在DOS和Pascal中制作简单的游戏(好旧时光…)

所以…每个事件驱动的应用程序内部都有一个类似这样的事件循环:

while (getMessage(out message)) // pseudo-code
{
   dispatchMessage(message); // pseudo-code
}

框架通常对您隐藏这个细节，但它确实存在。 getMessage函数从事件队列中读取下一个事件或等待事件发生:鼠标移动、按下键、按上键、单击等等。然后dispatchMessage将事件分派给适当的事件处理程序。 然后等待下一个事件，依此类推，直到退出事件出现，退出循环并完成应用程序。

事件处理程序应该快速运行，以便事件循环可以轮询更多事件，并且UI保持响应性。 如果单击按钮触发了这样昂贵的操作，会发生什么?

void expensiveOperation()
{
    for (int i = 0; i < 1000; i++)
    {
        Thread.Sleep(10);
    }
}

UI变得无响应，直到10秒操作结束，因为控件停留在函数中。 要解决这个问题，您需要将任务分解为可以快速执行的小部分。 这意味着您不能在一个事件中处理整个事件。 您必须完成一小部分工作，然后将另一个事件发布到事件队列以请求继续。

所以你可以把它改成:

void expensiveOperation()
{
    doIteration(0);
}

void doIteration(int i)
{
    if (i >= 1000) return;
    Thread.Sleep(10); // Do a piece of work.
    postFunctionCallMessage(() => {doIteration(i + 1);}); // Pseudo code. 
}

在这种情况下，只运行第一次迭代，然后它将消息发送到事件队列以运行下一次迭代并返回。 我们的示例postFunctionCallMessage伪函数在队列中放置了一个“调用此函数”事件，因此事件调度程序将在到达队列时调用它。 这允许在连续运行长时间运行的工作的片段的同时处理所有其他GUI事件。

As long as this long running task is running, its continuation event is always in the event queue. So you basically invented your own task scheduler. Where the continuation events in the queue are "processes" that are running. Actually this what operating systems do, except that the sending of the continuation events and returning to the scheduler loop is done via the CPU's timer interrupt where the OS registered the context switching code, so you don't need to care about it. But here you are writing your own scheduler so you do need to care about it - so far.

So we can run long running tasks in a single thread parallel with the GUI by breaking up them into small chunks and sending continuation events. This is the general idea of the Task class. It represents a piece of work and when you call .ContinueWith on it, you define what function to call as the next piece when the current piece finishes (and its return value is passed to the continuation). But doing all this chaining splitting up work into small pieces manually is a cumbersome work and totally messes up the layout of the logic, because the entire background task code basically a .ContinueWith mess. So this is where the compiler helps you. It does all this chaining and continuation for you under the hood. When you say await you tell the compiler that "stop here, add the rest of the function as a continuation task". The compiler takes care of the rest, so you don't have to.

虽然这个任务块链接不涉及创建线程，并且当任务块很小时，它们可以在主线程的事件循环上调度，但实际上有一个工作线程池来运行任务。这允许更好地利用CPU内核，还允许开发人员运行手动编写的长任务(这会阻塞工作线程而不是主线程)。

总结其他答案:

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

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