与node.js VS apache HTTPD混淆
我完全混淆了节点和线程之间的区别。 现在在httpd文档中，他们说他们创build了一个创build一个subprocess的主进程，而这个进程又保持了一个固定数量的线程。
线程池像Apache的预分配一样工作。 线程在程序启动时创build，然后平均分配工作负载。 当有更多的连接比线程，新的连接不得不等待。 但从好的一面来看，您可以节省创build线程的成本。
现在我怀疑这是因为线程可以运行共享内存为什么不能创build任何数量的线程？
谈到节点。 节点完全是事件驱动的。 基本上服务器由一个线程处理一个接一个的事件组成。 一个新的请求进入是一种事件。 服务器开始处理它，当有一个阻塞IO操作时，它不会等到它完成，而是注册一个callback函数。 服务器立即开始处理另一个事件（也许是另一个请求）。 当IO操作完成时，这是另一种事件，服务器将通过执行callback来处理它（即继续处理请求）。
现在如果节点不创build一个新的线程，那么它如何接受一个新的请求。
从博客了解node.js事件循环
Node.js为您的代码保留单个线程…
它确实是一个单线程运行：你不能做任何并行的代码执行; 例如做一个“睡眠”会阻塞服务器一秒钟：
源代码
while(new Date().getTime() < now + 1000) { // do nothing } 所以在代码运行时，node.js不会响应来自客户端的任何其他请求，因为它只有一个执行代码的线程。 或者，如果你有一些CPU密集的代码，例如调整图像的大小，那么仍然会阻止所有其他的请求。
检查博客的更多细节。 这是详细解释事件循环。
编辑
检查这个，一个很好的参考多进程Node.js：动机，挑战和解决scheme
JavaScript的问题是，它是臭名昭着的单线程。 因此，线程不能简单地存在（有一些复杂的解决scheme，但最终往往是非常复杂的）。 Node.js使用非阻塞的IO方法来规避这种限制，最后是避免任何阻塞，并让这些任务经常停顿一秒钟，让别人也做一些工作，最终巧妙地利用单线程。 类似于Windows 95-ME中的旧单核多任务仿真。
现在最大的问题是：如果这些处理线程中的任何一个处于暂停状态，则整个服务器处于暂停状态。 只要你小规模工作，这不是一个问题，但是对于一个大的服务器环境来说，这是绝对不行的。 另外现代服务器有8个或者更多的核心，保持7个空闲是硬件的大浪费。
工作者configuration中的HTTPD派生自己的一个分支（原来的可执行文件充当备份以防万一），然后根据configuration的值产生线程。 它理论上可以同时运行1000个线程，但是如果你的CPU只有8个内核，显然这些线程不能超过8个。 所以其他992个线程需要等待，这可以 – 根据任务 – 甚至会导致客户端运行超时，因为他们必须等待超过30秒。
有多less线程a是一个很好的价值主要取决于你的线程做什么。 如果他们从不阻止，而是花费100％的时间来真正解决问题，那么对于httpd来说，核心* 2是一个很好的价值，因为上面的核心限制。 如果你的线程阻塞了很多（磁盘访问，TCP通信），那么更高或更高的值可能会导致更好的吞吐量。 最后，要find的唯一方法是针对服务器启动testing数据，并测量各种configuration中的吞吐量。
然而，现代Web服务器（httpd已有数百年的历史）结合了这两种方法：一个非阻塞单个接收器线程，读取数据，然后将其分发到可用的线程。 这有利于IO操作快如闪电（如果代码是本地代码，甚至比node.js快），但是仍然可以同时使用所有内核。 Java可以通过NIO （new IO）来完成，然后将Runnables分发给执行者 。