等待就不是异步了

异步跟线程没有直接关系，只不过经常是用在多线程应用场景。异步是从语法上来说的，以回调、事件方式来组织代码流程。
async/await 在代码上看是同步的语法，不是异步的。
但是假设你的编程技术基于“调试、测试、真实事件时序”，你会发现实践上关心的代码的执行次序是异步的，而不是同步的。这样可以说 async/await 实际上在混淆程序设计师的思路。假设你画应用程序对象之间的时序图、状态图，你敢用 async/await 这种东西来画么？莫非你不应该按照真实的时序去画异步时序图、状态图么？
因此 async/await 主要给刚开始学者使用，用来简化异步回调语法。除此以外并没有什么真正的、在程序流程图设计上好处。

引用 LZ longvslove 的回复:

async await  task  程序到了await后开启一个线程，但是需要等待这个线程的，

严格地说，你这个说法其实是不对的。
async/await 并不是一定是等待“新的线程”。async/await 完全可能会使用当前线程来继续执行后续的代码，而并不启动新的线程。

引用 3 楼 longvslove 的回复:

那为什么说他们是异步呢，  而且这三个一般是组合使用的， async 必定有 await，  而方法一旦有返回值 必须要使用task的

async/await 当然是为了并发多线程执行而设计的。一个好的并发多线程系统，可能同时要执行几十个线程（而不是1、2个）。
假设有人说“调试时也是顺序执行的”，那说明他没有什么并发多线程程序在执行。原因是并发多线程程序其实根本无法手工单步调试，那种在几十个线程中来回、随机跳转代码的情况会让人疯掉，怎么可能还会好好地“调试”？
当你调试时，async/await 就是异步回调形式。
这其实不像是 Linq。对于 Linq 而言我们根本不谈对其内部机制进行调试，所以 Linq 就能成为一个广泛应用的机制。或例如说我们在 c# 应用程序中基本上就不谈什么底层的“寄存器、汇编指令时序”的调试，所以 .net 程序就能成为一个广泛应用的机制。当我们普遍使用高级语言来编程时，我们的设计跟我们的代码风格一致，所以就能用高级的编码形式。但是反过来，假如我们要求在底层设计应用系统，那么我们就不用c#甚至 linq 的思想来想问题了。
因此目前来看，async/await 适合那些根本不把“并发多线程”当回事儿的程序员，可以用这个语法来提高一些代码执行效率。但是假设程序员现在的编程设计层次还必须在意多线程流程设计，反而不应该用 async/await 了，而应该用明确的异步编程语法（例如各种 BeginXXXX 这类语法）。