非阻塞IO + fork / join VS标准多线程管理

Question

我将在Java和NodeJS的例子中比较这两种方法。当然，如果你愿意，你可以使用其他语言。

我们拥有什么： 如您所知，非阻塞IO成为编写高负载系统的主流。如您所知，NodeJS是具有clustering possibilities的单线程非阻塞IO。这意味着我们可以拥有许多单线程服务器而不是一个多线程服务器。而Java同时具有：非阻塞IO库（Netty和基于它的框架，如Play框架）和传统多线程（不是基于事件），它们在程序员中进行所有线程管理。

我的困惑：我听到很多关于传统多线程的抱怨，关于调试这些程序有多难，而且与非阻塞IO相比，它们相当慢。另一方面，我听到很多关于非阻塞IO的恭维，比如Node，以及使用fork / join libs将它扩展到多线程程序是多么容易。

因此，如果非阻塞IO非常好 问题：与非阻塞IO相比，我们何时仍可以从传统（非基于事件的）多线程中获得优势？

P.S。有人写过应用程序，你有很多单线程非阻塞IO服务器，只是分配它们之间的负载吗？

Answer 1

最好的解决方案是使用nodejs来处理I / O（数据库查询，对Web服务的请求，与其他应用程序的套接字连接，......），让我们说Apache来处理需要计算的请求。

想象一下需要回答I / O部分和计算部分的请求：例如，从db中检索大量记录以及在这些记录上执行一些cpu消耗任务。 我能想象到的最适合上述需求的最佳应用程序是由nodejs Web服务器处理请求的应用程序，该服务器查询数据库然后将记录传递给Apache Web服务器以执行计算部分。 最后，nodejs执行2个I / O任务（db查询和查询Apache Web服务），而Apache使用完全使用的专用线程处理计算部分。

Answer 2

非阻止IO - NodeJS
所有请求都由一个线程处理，该线程不断循环并且必须处理多个请求。那怎么不被淹没呢？通常需要最长时间的操作是I / O操作（读取文件/数据库）。 Node将这些传递给另一个进程并继续围绕它的循环。当I / O完成时，回调发生并且主循环处理它。

只要主循环不会在计算任务中陷入困境，这就很有效。

传统阻止服务器
每个请求都有自己的线程，它执行自己的计算和I / O操作。计算在其自己的线程上执行，而I / O被传递到OS或其他进程。线程将在执行I / O时阻塞，但无关紧要，因为每个请求都有一个单独的线程。

因为每个请求都有自己的线程，所以计算密集型任务不会影响其他请求，例如节点。