当我们有默认工作池时为什么要使用“worker_threads”？

Question

我清楚地看到集群方法，因为它部署了不同的整个流程。我猜专业程序员出于某种充分的原因创建了“worker_threads”库......但我仍然需要澄清这一点以加深我的理解：

在正常的单线程进程中，事件循环线程借助默认工作池来卸载其繁重的 I/O 任务，因此主线程不会被阻塞。

同时，出于同样的原因，用户定义的“工作线程”将与它们自己的事件循环和 NodeJS 实例一起使用。

当这些事件循环和 Nodejs 实例不是瓶颈时，生成这些事件循环和 Nodejs 实例有什么意义，因为 libuv 旨在设法生成工作线程。

这是否意味着默认工作池可能不够？我的意思只是数量问题还是概念？

Answer 1

Nodejs中有两种类型的操作（调用）：阻塞和非阻塞

非阻塞

Nodejs使用Libuv进行IO非阻塞操作。网络、文件和 DNS IO 操作由 Libuv 异步运行。Nodejs 使用以下方案：

Node.js 尽可能使用异步系统 API，但在不存在异步系统 API 的情况下，Libuv 的线程池用于基于同步系统 API 创建异步节点 API。使用线程池的 Node.js API 有：

• 所有 fs API，文件观察器 API 和以下 API 除外：

• 显式同步异步加密 API，例如 crypto.pbkdf2()、crypto.scrypt()、crypto.randomBytes()、crypto.randomFill()、crypto.generateKeyPair()

• dns.lookup() 所有 zlib *API，显式同步的 API 除外。

所以我们无法直接访问Libuv线程池。我们可以使用C++ 附加组件定义我们自己对线程池的使用。

阻止来电

Nodejs 在主线程中执行阻塞代码。fs.readfileSync()、压缩算法、加密数据、图像调整大小、计算大范围的素数是分块操作的一些示例。Nodejs 的黄金法则是永远不会阻塞事件循环（主线程）。我们可以通过使用clustermodule 或child-processmodule 创建子进程来异步执行这些操作。但就操作系统资源而言，创建子进程是一项繁重的任务，这就是它worker-thread诞生的原因。

使用worker-thread您可以在工作线程中执行阻塞的javascript代码，从而解除对主线程的阻塞，并且您可以通过消息传递与父线程（主线程）进行通信。与子进程相比，工作线程仍然是轻量级的。

在这里阅读更多内容：

https://nodesource.com/blog/worker-threads-nodejs

https://blog.insiderattack.net/deep-dive-into-worker-threads-in-node-js-e75e10546b11