如果异步/等待只是线程的包装，为什么异步/等待比线程更好？

如何解决如果异步/等待只是线程的包装，为什么异步/等待比线程更好？

这个话题在我心中已经很久了。

假设我们有一个典型的Web服务器，一个在Node.js中，另一个在Java（或其他任何带线程的语言）中。

为什么仅仅因为节点使用async / await，它的性能会比Java服务器更好（每秒处理更多基于IO /网络的请求）？不仅仅是在后台利用java / c＃/ c ++使用的相同线程的语法糖吗？

解决方法

没有理由期望Node会比用Java编写的服务器更快。为什么会这样呢？

到目前为止（看来），这里的其他答案似乎是在解释JS中的异步编程与单线程同步操作相比的好处-显而易见，但不是问题。

每个人都同意的关键点是某些操作本来就很慢（例如：等待网络请求，等待磁盘/数据库访问），并且在进行此类操作时让CPU做其他事情非常有效。在应用程序中使用多个线程是一种行之有效的方法。但是，当然只有在提供线程的语言中才有可能。许多传统的服务器实现（使用Java，C，C ++等）在每个请求中使用一个线程（或等效地，在线程池中分配传入的请求）。这些线程可以阻止等待数据库的工作，这没关系，操作系统会将等待线程置于睡眠状态，同时让CPU在另一个线程上工作（处理另一个请求）。最终结果与通过Node获得的结果非常相似。

当然，JavaScript不会使线程可供程序员使用。但是，它具有通过JavaScript引擎调度请求并提供在请求完成时要调用的回调的概念。这就是整个系统的行为类似于传统的线程编程语言：用户代码可以说“先做这些事情，然后安排数据库访问，然后在结果可用时，在这里继续此[回调]代码”，然后等待数据库请求后，CPU将执行其他一些代码。您要避免的是，CPU闲置地等待，而还有其他工作在等待CPU有时间，而这两种方法（Java线程和JavaScript回调）都可以做到这一点。

最后，异步/等待（就像Promises一样）实际上只是语法糖，使编写基于回调的代码更容易。使用async / await的代码并不比直接使用回调的老式代码快，只是更漂亮，更不易出错。它也没有比（编写良好的）基于Java的服务器快。

Node.js之所以受欢迎，是因为在应用程序的客户端和服务器部分使用相同的语言很方便。从性能的角度来看，它不比传统的替代方法好，也并不差（或者至少没有很多；实际上，设计应用程序的效率更加重要）而不是用Java还是JavaScript来实现）。不要迷恋炒作：-）

,

异步（asyn / await）对于可能阻塞的活动（例如，当您的应用程序访问Web时）至关重要。对Web资源的访问有时很慢或延迟。如果在同步进程中阻止了此类活动，则整个应用程序必须等待。

在异步进程（线程）中，应用程序可以继续执行不依赖于Web资源的其他工作，直到潜在的阻止任务完成为止。

https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2012/hh191443(v=vs.110)?redirectedfrom=MSDN#threads尽管您应该了解线程与异步/等待编程之间的区别。

,

关于异步编程，可用性是关键。例如，一个请求可以分解为较小的任务，即获取内部结果，读取，写入，建立连接等...因此，一半时间浪费在等待相关任务上。异步模型利用这段时间来处理其他传入请求，同时保留回调函数，在队列中注册以保存状态并可以用于其他请求。因此，他们可以处理更多请求。

进一步了解如何处理请求：https://www.youtube.com/watch?v=cCOL7MC4Pl0