问Nodejs的内部线程池究竟是如何工作的？

EN

libuv提供的单个进程线程池默认创建4个线程。UV_THREADPOOL_SIZE环境变量可用于更改启动node进程时创建的线程数，最高值为1024 (截至libuv1.30.0)。

当所有这些线程被阻塞时，使用它们的进一步请求将排队。请求线程的API方法称为uv_queue_work。

此线程池用于将导致阻塞IO的任何系统调用，其中包括本地文件系统操作。它还可以用于减少CPU密集型操作的影响，正如@Andrey提到的那样。

大多数网络操作所支持的非阻塞IO不需要使用线程池。

如果您正在使用的数据库驱动程序的源代码是可用的，并且您能够找到对uv_queue_work的引用，那么它可能正在使用线程池。

如果需要，libuv 线程池文档提供了更多的技术细节。

在下面的映像中，所有内部工作线程都是充满任务的，假设所有这些线程都需要从数据库中检索大量数据，并且主单线程一直在驱动对这些工作人员的新请求。

这不是node.js使用这些线程的方式。

根据Node.js文档，线程的使用方式如下：

​

​

所有请求和响应都在主线程中“处理”。await**)的回调(以及后的代码)只需轮流执行。javascript解释器和“事件循环”之间的“循环”通常只是一个while**循环。

除了您自己启动的worker_threads之外，node.js只使用4种线程:等待DNS响应、磁盘I/O、内置加密库和内置zip库。Worker_threads是node.js在主线程之外执行javascript的唯一地方。所有其他线程的使用都执行C/C++代码。

如果你想知道更多，那么我已经写了几个相关问题的答案：

节点js体系结构与性能

node.js服务器如何优于基于线程的服务器

节点js -回调执行期间传入的事件发生了什么？

使用弹性跑道算法进行javascript处理吗？

在没有无限时间循环的情况下，还有其他方法来实现“监听”函数吗？

不是，线程池的主要用例是卸载CPU密集型操作。IO是在一个线程中执行的--如果您正在并行地等待外部数据，则不需要多个线程，而事件循环正是一种组织执行流的技术，以便尽可能多地并行等待。

例如:你需要发送100封带有问题(y/n)的电子邮件，另一封电子邮件的答案是"y“。写电子邮件大约需要30秒，回复平均需要两个小时+10秒才能读取回复。你首先写完100封电子邮件( 50分钟)，然后等待警报声，每次回复都会唤醒你，当你收到答案时，你会增加"y“的数量。再过2小时50分钟你就完事了。这是异步IO和事件循环(没有线程池)的例子。

阻塞示例:发送电子邮件，等待答复，重复。需要4天(两天如果你可以克隆另一个你)

异步线程池示例:每个响应都使用您不知道的语言。你有4个翻译朋友。你给他们发电子邮件，他们把翻译好的文本发回给你(或者，更准确地说:你打印文本并把它放到“需要翻译”文件夹中)。只要有翻译器，就会从文件夹中提取文本)