我对async/await的理解，它的工作原理和好处，是否正确？
我对async/await的理解，它的工作原理和好处，是否正确？
我已经多次表达了我对async/await的理解，但往往有一些争论，关于我是否正确。如果有人能证实或否认我的理解，并澄清任何误解，这样我就不会传播错误信息了，我将非常感激。
高级理解
async/await是一种避免在编写异步代码时出现回调地狱的方法。执行异步方法的线程在遇到await时将返回到线程池，并在等待操作完成后继续执行。
低级理解
JIT会将异步方法在await点周围分割成离散的部分，允许重新进入方法并保留方法的状态。在底层，这涉及某种状态机。
与并发的关系
async/await不意味着任何形式的并发。使用async/await编写的应用程序可以完全单线程，同时获得所有好处，就像node.js使用回调一样。与node.js不同，.NET是多线程的，所以通过使用async/await，您可以在不使用回调的情况下获得非阻塞IO的好处，同时具有多个执行线程。
好处
async/await在等待IO完成时释放线程以做其他事情。它还可以与TPL结合使用，以在多个线程上执行CPU密集型工作，或者在UI线程之外执行。
为了从非阻塞IO中获益，异步方法需要构建在实际利用非阻塞IO的API之上，这些API最终由操作系统提供。
误用
这是我理解中最大的争议点。很多人认为将阻塞操作包装在一个Task中，并使用async/await会带来性能提升。通过创建一个额外的线程来处理操作，将原始线程返回到线程池，然后在任务完成后恢复原始方法，所有这些只是在不真正释放线程以做其他工作的情况下进行不必要的上下文切换。虽然这不像对async/await的误用那样严重，但这种思维方式似乎源于对async/await的误解。
async/await是一种在.NET中处理异步操作的模式。它允许程序在等待异步操作完成时不阻塞线程，从而提高程序的性能和响应能力。
async/await的工作原理如下：当程序遇到一个await表达式时，它会暂停当前方法的执行，并立即返回到调用方。调用方可以继续执行其他操作，而不必等待异步操作完成。一旦异步操作完成，程序会恢复执行await表达式之后的代码。
async/await的好处是它可以简化异步编程的过程，使代码更易读和维护。它避免了使用回调函数或显式的线程管理来处理异步操作，而是使用类似于同步代码的结构来处理异步操作。
async/await并不一定意味着并发，因为它可以在单个线程上执行多个异步操作。通过同时启动和等待多个异步操作，程序可以在单个线程上执行多个操作，从而实现并发。这是通过异步操作不需要线程来执行的特性实现的。
async/await是建立在TPL(Task Parallel Library)之上的，它是一种处理并行和异步编程的框架。通过使用TPL和async/await，可以更方便地处理异步操作，提高程序的性能和可维护性。
虽然大多数异步操作都涉及到I/O操作，但并不是所有的异步操作都是I/O操作。使用Task.Delay或异步同步构造（如SemaphoreSlim.WaitAsync）可以实现异步延迟和异步同步。
总之，async/await是一种在.NET中处理异步操作的模式，它通过不阻塞线程并允许并发执行多个操作，提高了程序的性能和响应能力。它建立在TPL之上，简化了异步编程的过程。