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

Question

这个话题在我心中已经存在了很长时间。
假设我们有一台典型的Web服务器，一台服务器使用Node.js，另一台服务器使用Java(或任何其他带线程的语言)。
为什么仅由于 Node 使用异步/等待，其性能会比Java服务器更好(每秒处理更多基于IO/网络的请求)？不仅仅是在后台利用java/C#/c++使用的相同线程的语法糖吗？

Answer 1

没有理由期望Node会比用Java编写的服务器更快。为什么会这样呢？
到目前为止，似乎这里的其他答案是在解释JS中的异步编程与单线程同步操作相比的好处-显而易见，但不是问题。
每个人都同意的关键点是，某些操作本来就很慢(例如:WAITING网络请求，等待磁盘/数据库访问)，并且在此类操作进行期间让CPU做其他事情是很有效的。在应用程序中使用多个线程是一种行之有效的方法。但是，当然，只有在为您提供线索的语言中才有可能。许多传统的服务器实现(使用Java，C，C++等)在每个请求中使用一个线程(或等效地，在线程池中分配传入的请求)。这些线程可能会阻塞等待数据库的等待，这没关系，操作系统会将等待线程置于 sleep 状态，同时让CPU在另一个线程上工作(处理另一个请求)。最终结果与通过Node获得的结果非常相似。
当然，JavaScript不会使线程可供程序员使用。但是，它具有通过JavaScript引擎调度请求并提供在请求完成时要调用的回调的概念。这就是整个系统的行为类似于传统的线程编程语言:用户代码可以说“先做这些事情，然后安排数据库访问，然后在结果可用时，在此处继续此[回调]代码”，然后等待数据库请求后，CPU将执行其他一些代码。您要避免的是，CPU闲置地等待，而还有其他工作在等待CPU有时间，而这两种方法(Java线程和JavaScript回调)都可以做到这一点。
最后，异步/等待(就像Promises一样)实际上只是语法糖，使编写基于回调的代码更容易。使用async/await的代码并没有比直接使用回调的老式代码快，只是更漂亮，更不容易出错。它也没有比(编写良好的)基于Java的服务器更快。
Node.js之所以受欢迎，是因为在应用程序的客户端和服务器部分使用相同的语言很方便。从性能的角度来看，它并没有比传统的替代方法更好，也没有更糟(或者至少没有太多；实际上，设计应用程序的效率比用Java或JavaScript实现更重要)。不要迷恋炒作:-)