本文论点主要面向 Node.js 开发语言
>> Show Me Code，目前代码正在 dev 分支，已完成单元测试，尚待测试所有场景。
>> 建议通读 Node.js 官方文档 -【不要阻塞事件循环】
Node.js 即服务端 Javascript，得益于宿主环境的不同，它拥有比在浏览器上更多的能力。比如：完整的文件系统访问权限、网络协议、套接字编程、进程和线程操作、C++ 插件源码级的支持、Buffer 二进制、Crypto 加密套件的天然支持。【相关教程推荐：nodejs视频教程】
Node.js 的是一门单线程的语言，它基于 V8 引擎开发，v8 在设计之初是在浏览器端对 JavaScript 语言的解析运行引擎，其最大的特点是单线程，这样的设计避免了一些多线程状态同步问题，使得其更轻量化易上手。
一、名词定义
学术上说，进程是一个具有一定独立功能的程序在一个数据集上的一次动态执行的过程，是操作系统进行资源分配和调度的一个独立单位，是应用程序运行的载体。我们这里将进程比喻为工厂的车间，它代表 CPU 所能处理的单个任务。任一时刻，CPU 总是运行一个进程，其他进程处于非运行状态。
进程具有以下特性：
在早期的操作系统中并没有线程的概念，进程是能拥有资源和独立运行的最小单位，也是程序执行的最小单位。任务调度采用的是时间片轮转的抢占式调度方式，而进程是任务调度的最小单位，每个进程有各自独立的一块内存，使得各个进程之间内存地址相互隔离。
后来，随着计算机的发展，对 CPU 的要求越来越高，进程之间的切换开销较大，已经无法满足越来越复杂的程序的要求了。于是就发明了线程，线程是程序执行中一个单一的顺序控制流程，是程序执行流的最小单元。这里把线程比喻一个车间的工人，即一个车间可以允许由多个工人协同完成一个任务，即一个进程中可能包含多个线程。
线程具有以下特性：
Node.js 的多进程有助于充分利用 CPU 等资源，Node.js 的多线程提升了单进程上任务的并行处理能力。
在 Node.js 中，每个 worker 线程都有他自己的 V8 实例和事件循环机制 (Event Loop)。但是，和进程不同，workers 之间是可以共享内存的。
二、Node.js 异步机制
Node.js 的单线程是指程序的主要执行线程是单线程，这个主线程同时也负责事件循环。而其实语言内部也会创建线程池来处理主线程程序的 网络 IO / 文件 IO / 定时器 等调用产生的异步任务。一个例子就是定时器 Timer 的实现：在 Node.js 中使用定时器时，Node.js 会开启一个定时器线程进行计时，计时结束时，定时器回调函数会被放入位于主线程的宏任务队列。当事件循环系统执行完主线程同步代码和当前阶段的所有微任务时，该回调任务最后再被取出执行。所以 Node.js 的定时器其实是不准确的，只能保证在预计时间时我们的回调任务被放入队列等待执行，而不是直接被执行。
多執行緒機製配合 Node.js 的 evet loop 事件循環系統讓開發者在一個執行緒內就能夠使用非同步機制，包括定時器、IO、網路請求。但為了實現高響應度的高效能伺服器，Node.js 的 Event Loop 在宏任務上進一步劃分了優先權。
Node.js 巨集任務之間的優先權分割：Timers > Pending > Poll > Check > Close。
Node.js 微任務之間的最佳化與分割：process.nextTick > Promise。
node 11 之前，Node.js 的Event Loop 並不是瀏覽器那種一次執行一個巨集任務，然後執行所有的微任務，而是執行完一定數量的Timers 巨集任務，再去執行所有微任務，然後再執行一定數量的Pending 的巨集任務，然後再去執行所有微任務，剩餘的Poll 、Check、Close 的巨集任務也是這樣。 node 11 之後改為了每個巨集任務都執行所有微任務了。
而Node.js 的宏任務之間也是有優先權的，如果Node.js 的Event Loop 每次都是把目前優先權的所有宏任務跑完再去跑下一個優先權的巨集任務，那麼會導致「飢餓」 狀態的發生。如果某個階段宏任務太多，下個階段就執行不到了，所以每個類型的宏任務有個執行數量上限的機制，剩餘的交給之後的 Event Loop 再繼續執行。
最終表現就是：也就是執行一定數量的Timers 巨集任務，每個巨集任務之間執行所有微任務，再一定數量的Pending Callback 巨集任務，每個巨集任務之間再執行所有微任務。
三、Node.js 的多進程
Node.js 程式透過child_process 模組提供了衍生子程序的能力，child_process 提供多種子程序的建立方式：
const spawn = require('child_process').spawn;
const ls = spawn('ls', ['-lh', '/usr']);
ls.stdout.on('data', (data) => {
console.log(`stdout: ${data}`);
});
ls.stderr.on('data', (data) => {
console.log(`stderr: ${data}`);
});
ls.on('close', (code) => {
console.log(`child process exited with code ${code}`);
});execFile('/path/to/node', ['--version'], function(error, stdout, stderr){
if(error){
throw error;
}
console.log(stdout);
});exec('ls -al', function(error, stdout, stderr){
if(error) {
console.error('error:' + error);
return;
}
console.log('stdout:' + stdout);
console.log('stderr:' + typeof stderr);
});var child = child_process.fork('./anotherSilentChild.js', {
silent: true
});
child.stdout.setEncoding('utf8');
child.stdout.on('data', function(data){
console.log(data);
});其中，spawn 是所有方法的基礎，exec 底層是呼叫了 execFile。
以下是使用 Cluster 模組建立一個 http 服務叢集的簡單範例。範例中建立Cluster 時使用同一個Js 執行文件，在檔案內使用cluster.isPrimary 判斷目前執行環境是在主行程還是子行程，如果是主行程則使用目前執行檔建立子行程實例，如果時子程序則進入子程序的業務處理流程。
/*
简单示例：使用同一个 JS 执行文件创建子进程集群 Cluster
*/
const cluster = require('node:cluster');
const http = require('node:http');
const numCPUs = require('node:os').cpus().length;
const process = require('node:process');
if (cluster.isPrimary) {
console.log(`Primary ${process.pid} is running`);
// Fork workers.
for (let i = 0; i {
console.log(`worker ${worker.process.pid} died`);
});
} else {
// Workers can share any TCP connection
http.createServer((req, res) => {
res.writeHead(200);
res.end('hello world\n');
}).listen(8000);
console.log(`Worker ${process.pid} started`);
}Cluster 模組允許設立一個主進程和若干個子進程，使用child_process.fork() 在內部隱含地建立子進程，由主進程監控和協調子進程的運作。
子進程之間採用進程間通訊交換訊息，Cluster 模組內建一個負載平衡器，採用 Round-robin 演算法（輪流執行）協調各個子進程之間的負載。運行時，所有新建立的連線都由主進程完成，然後主進程再把 TCP 連線分配給指定的子進程。
使用叢集建立的子進程可以使用同一個端口，Node.js 內部對 http/net 內建模組進行了特殊支援。 Node.js 主程序負責監聽目標端口，收到請求後根據負載平衡策略將請求分發給某一個子程序。
PM2 是常用的 node 进程管理工具，它可以提供 node.js 应用管理能力，如自动重载、性能监控、负载均衡等。
其主要用于 独立应用 的进程化管理，在 Node.js 单机服务部署方面比较适合。可以用于生产环境下启动同个应用的多个实例提高 CPU 利用率、抗风险、热加载等能力。
由于是外部库，需要使用 npm 包管理器安装：
$: npm install -g pm2
pm2 支持直接运行 server.js 启动项目，如下：
$: pm2 start server.js
即可启动 Node.js 应用，成功后会看到打印的信息：
┌──────────┬────┬─────────┬──────┬───────┬────────┬─────────┬────────┬─────┬───────────┬───────┬──────────┐ │ App name │ id │ version │ mode │ pid │ status │ restart │ uptime │ cpu │ mem │ user │ watching │ ├──────────┼────┼─────────┼──────┼───────┼────────┼─────────┼────────┼─────┼───────────┼───────┼──────────┤ │ server │ 0 │ 1.0.0 │ fork │ 24776 │ online │ 9 │ 19m │ 0% │ 35.4 MB │ 23101 │ disabled │ └──────────┴────┴─────────┴──────┴───────┴────────┴─────────┴────────┴─────┴───────────┴───────┴──────────┘
pm2 也支持配置文件启动，通过配置文件 ecosystem.config.js 可以定制 pm2 的各项参数：
module.exports = {
apps : [{
name: 'API', // 应用名
script: 'app.js', // 启动脚本
args: 'one two', // 命令行参数
instances: 1, // 启动实例数量
autorestart: true, // 自动重启
watch: false, // 文件更改监听器
max_memory_restart: '1G', // 最大内存使用亮
env: { // development 默认环境变量
// pm2 start ecosystem.config.js --watch --env development
NODE_ENV: 'development'
},
env_production: { // production 自定义环境变量
NODE_ENV: 'production'
}
}],
deploy : {
production : {
user : 'node',
host : '212.83.163.1',
ref : 'origin/master',
repo : 'git@github.com:repo.git',
path : '/var/www/production',
'post-deploy' : 'npm install && pm2 reload ecosystem.config.js --env production'
}
}
};pm2 logs 日志功能也十分强大：
$: pm2 logs
一般我们使用计算机执行的任务包含以下几种类型的任务：
计算密集型任务：任务包含大量计算，CPU 占用率高。
const matrix = {};
for (let i = 0; i IO 密集型任务：任务包含频繁的、持续的网络 IO 和磁盘 IO 的调用。
const {copyFileSync, constants} = require('fs');
copyFileSync('big-file.zip', 'destination.zip');混合型任务：既有计算也有 IO。
一、进程池的适用场景
使用进程池的最大意义在于充分利用多核 CPU 资源，同时减少子进程创建和销毁的资源消耗。
进程是操作系统分配资源的基本单位，使用多进程架构能够更多的获取 CPU 时间、内存等资源。为了应对 CPU-Sensitive 场景，以及充分发挥 CPU 多核性能，Node 提供了 child_process 模块用于创建子进程。
子进程的创建和销毁需要较大的资源成本，因此池化子进程的创建和销毁过程，利用进程池来管理所有子进程。
除了这一点，Node.js 中子进程也是唯一的执行二进制文件的方式，Node.js 可通过流 (stdin/stdout/stderr) 或 IPC 和子进程通信。
通过 Stream 通信
const {spawn} = require('child_process');
const ls = spawn('ls', ['-lh', '/usr']);
ls.stdout.on('data', (data) => {
console.log(`stdout: ${data}`);
});
ls.stderr.on('data', (data) => {
console.error(`stderr: ${data}`);
});
ls.on('close', (code) => {
console.log(`child process exited with code ${code}`);
});通过 IPC 通信
const cp = require('child_process');
const n = cp.fork(`${__dirname}/sub.js`);
n.on('message', (m) => {
console.log('PARENT got message:', m);
});
n.send({hello: 'world'});二、线程池的适用场景
使用线程池的最大意义在于多任务并行，为主线程降压，同时减少线程创建和销毁的资源消耗。单个 CPU 密集性的计算任务使用线程执行并不会更快，甚至线程的创建、销毁、上下文切换、线程通信、数据序列化等操作还会额外增加资源消耗。
但是如果一个计算机程序中有很多同一类型的阻塞任务需要执行，那么将他们交给线程池可以成倍的减少任务总的执行时间，因为在同一时刻多个线程在并行进行计算。如果多个任务只使用主线程执行，那么最终消耗的时间是线性叠加的，同时主线程阻塞之后也会影响其它任务的处理。
特别是对 Node.js 这种单主线程的语言来讲，主线程如果消耗了过多的时间来执行这些耗时任务，那么对整个 Node.js 单个进程实例的性能影响将是致命的。这些占用着 CPU 时间的操作将导致其它任务获取的 CPU 时间不足或 CPU 响应不够及时，被影响的任务将进入 “饥饿” 状态。
因此 Node.js 启动后主线程应尽量承担调度的角色，批量重型 CPU 占用任务的执行应交由额外的工作线程处理，主线程最后拿到工作线程的执行结果再返回给任务调用方。另一方面由于 IO 操作 Node.js 内部作了优化和支持，因此 IO 操作应该直接交给主线程，主线程再使用内部线程池处理。
Node.js 的异步能不能解决过多占用 CPU 任务的执行问题？
答案是：不能，过多的异步 CPU 占用任务会阻塞事件循环。
Node.js 的异步在 网络 IO / 磁盘 IO 处理上很有用，宏任务微任务系统 + 内部线程调用能分担主进程的执行压力。但是如果单独将 CPU 占用任务放入宏任务队列或微任务队列，对任务的执行速度提升没有任何帮助，只是一种任务调度方式的优化而已。
我们只是延迟了任务的执行或是将巨大任务分散成多个再分批执行，但是任务最终还是要在主线程被执行。如果这类任务过多，那么任务分片和延迟的效果将完全消失，一个任务可以，那十个一百个呢？量变将会引起质变。
以下是 Node.js 官方博客中的原文：
“如果你需要做更复杂的任务，拆分可能也不是一个好选项。这是因为拆分之后任务仍然在事件循环线程中执行，并且你无法利用机器的多核硬件能力。 请记住，事件循环线程只负责协调客户端的请求，而不是独自执行完所有任务。 对一个复杂的任务，最好把它从事件循环线程转移到工作线程池上。”
场景：间歇性让主进程 瘫痪
每一秒钟，主线程有一半时间被占用
// this task costs 100ms
function doHeavyTask() { ...}
setInterval(() => {
doHeavyTask(); // 100ms
doHeavyTask(); // 200ms
doHeavyTask(); // 300ms
doHeavyTask(); // 400ms
doHeavyTask(); // 500ms
}, 1e3);场景：高频性让主进程 半瘫痪
每 200ms，主线程有一半时间被占用
// this task costs 100ms
function doHeavyTask() { ...}
setInterval(() => {
doHeavyTask();
}, 1e3);
setInterval(() => {
doHeavyTask();
}, 1.2e3);
setInterval(() => {
doHeavyTask();
}, 1.4e3);
setInterval(() => {
doHeavyTask();
}, 1.6e3);
setInterval(() => {
doHeavyTask();
}, 1.8e3);以下是官方博客的原文摘录：
“因此，你应该保证永远不要阻塞事件轮询线程。换句话说，每个 JavaScript 回调应该快速完成。这些当然对于 await，Promise.then 也同样适用。”
进程池是对进程的创建、执行任务、销毁等流程进行管控的一个应用或是一套程序逻辑。之所以称之为池是因为其内部包含多个进程实例，进程实例随时都在进程池内进行着状态流转，多个创建的实例可以被重复利用，而不是每次执行完一系列任务后就被销毁。因此，进程池的部分存在目的是为了减少进程创建的资源消耗。
此外进程池最重要的一个作用就是负责将任务分发给各个进程执行，各个进程的任务执行优先级取决于进程池上的负载均衡运算，由算法决定应该将当前任务派发给哪个进程，以达到最高的 CPU 和内存利用率。常见的负载均衡算法有：
「 对单一任务的控制不重要，对单个进程宏观的资源占用更需关注 」
进程池架构图参考之前的进程管理工具开发相关 文章，本文只需关注进程池部分。
main.js
const { ChildProcessPool, LoadBalancer } = require('electron-re');
const processPool = new ChildProcessPool({
path: path.join(__dirname, 'child_process/child.js'),
max: 4,
strategy: LoadBalancer.ALGORITHM.POLLING,
);child.js
const { ProcessHost } = require('electron-re');
ProcessHost
.registry('test1', (params) => {
console.log('test1');
return 1 + 1;
})
.registry('test2', (params) => {
console.log('test2');
return new Promise((resolve) => resolve(true));
});processPool.send('test1', { value: "test1"}).then((result) => {
console.log(result);
});processPool.sendToAll('test1', { value: "test1"}).then((results) => {
console.log(results);
});1）基本代理原理：
2）单进程下客户端执行原理：
3）多进程下客户端执行原理：
以上描述的是客户端连接单个节点的工作模式，节点订阅组中的负载均衡模式需要同时启动多个子进程，每个子进程启动 ss-local 执行文件占用一个本地端口并连接到远端一个服务器节点。
每个子进程启动时选择的端口是会变化的，因为某些端口可能已经被系统占用，程序需要先选择未被使用的端口。并且浏览器 proxy 工具也不可能同时连接到我们本地启动的子进程上的多个 ss-local 服务上。因此需要一个占用固定端口的中间节点接收 proxy 工具发出的连接请求，然后按照某种分发规则将 tcp 流量转发到各个子进程的 ss-local 服务的端口上。
之前做過一個支援SMB 協定多檔案分片上傳的客戶端，Node.js 端的上傳任務管理、 IO 操作等都使用多進程實作過一版本，不過是在gitlab 實驗分支自己搞得（逃）。
#為了減少CPU 密集型任務計算的系統開銷，Node.js 引入了新的特性：工作執行緒worker_threads，其首次在v10.5.0 作為實驗性功能出現。透過 worker_threads 可以在進程內建立多個線程，主線程與 worker 線程使用 parentPort 通信，worker 線程之間可透過 MessageChannel 直接通信。 worker_threads 做為開發者使用執行緒的重要特性，在 v12.11.0 穩定版已經能正常在生產環境使用了。
但是線程的創建需要額外的 CPU 和記憶體資源，如果要多次使用一個線程的話，應該將其保存起來，當該線程完全不使用時需要及時關閉以減少記憶體佔用。想像我們在需要使用執行緒時直接創建，使用完後立刻銷毀，可能執行緒本身的創建和銷毀成本已經超過了使用執行緒本身節省下的資源成本。 Node.js 內部雖然有使用線程池，但是對於開發者而言是完全透明不可見的，因此封裝一個能夠維護線程生命週期的線程池工具的重要性就體現了。
為了強化多非同步任務的調度，執行緒池除了提供維護執行緒的能力，也提供維護任務佇列的能力。當發送請求給線程池讓其執行一個非同步任務時，如果線程池內沒有空閒線程，那麼該任務就會被直接丟棄了，顯然這不是想要的效果。
因此可以考慮為執行緒池新增一個任務佇列的調度邏輯：當執行緒池沒有空閒執行緒時，將該任務放入待執行任務佇列(FIFO)，執行緒池在某個時機取出任務交由某個空閒執行緒執行，執行完成後觸發非同步回呼函數，將執行結果傳回給請求呼叫方。但是執行緒池的任務佇列內的任務數量應該考慮限製到一個特殊值，防止執行緒池負載過大影響 Node.js 應用整體運行效能。
「 對單一任務的控制很重要，對單一執行緒的資源佔用無需關注」
呼叫者可透過StaticPool/StaticExcutor/DynamicPool/DynamicExcutor 實例向執行緒池派發任務（以下有關鍵名詞說明），各種實例的之間最大的不同點就是參數動態化能力。
任務由線程池內部生成，生成後任務做為主要的流轉載體，一方面承載用戶傳入的任務計算參數，另一方面記錄任務流轉過程中的狀態變化，例如：任務狀態、開始時間、結束時間、任務ID、任務重試次數、任務是否支援重試、任務類型等。
任務產生後，先判斷目前執行緒池的執行緒數是否已達上限，如果未達上限，則新執行緒並將其放入執行緒儲存區，然後使用該執行緒直接執行當前任務。
如果線程池線程數超限，則判斷是否有未執行任務的空閒線程，拿到空閒線程後，使用該線程直接執行當前任務。
如果沒有空閒線程，則判斷目前等待任務佇列是否已滿，任務佇列已滿則拋出錯誤，第一時間讓呼叫者感知任務未執行成功。
如果任務佇列未滿的話，將該任務放入任務佇列，等待任務循環系統取出執行。
以上 4/5/6 步驟的三種情況下任務執行後，判斷該任務是否執行成功，成功時觸發成功的回呼函數，Promise 狀態為 fullfilled。若失敗，判斷是否支援重試，支援重試的情況下，將該任務重試次數 1 後重新放入任務佇列尾部。任務不支援重試的情況下，直接失敗，並觸發失敗的非同步回呼函數，Promise 狀態為 rejected。
整個線程池生命週期中，存在一個任務循環系統，以一定的周期頻率從任務隊列首部獲取任務，並從線程存儲區域獲取空閒線程後使用該線程執行任務，流程也符合第7 步的描述。
任务循环系统除了取任务执行，如果线程池设置了任务超时时间的话，也会判断正在执行中的任务是否超时，超时后会终止该线程的所有运行中的代码。
execFunction/execString/execFile 执行参数来启动工作线程，执行参数在进程池创建后不能更改。execFunction/execString/execFile 且不可更改。execFunction/execString/execFile 执行参数即可创建线程池。执行参数在调用 exec() 方法时动态传入，因此执行参数可能不固定。null，其它参数比如：任务超时时间、任务重试次数、transferList 等都可以通过 API 随时更改。null。execFunction/execString/execFile，执行参数可以随时改变。worker_threads API。main.js
const { StaticThreadPool } = require(`electron-re`);
const threadPool = new StaticThreadPool({
execPath: path.join(__dirname, './worker_threads/worker.js'),
lazyLoad: true, // 懒加载
maxThreads: 24, // 最大线程数
maxTasks: 48, // 最大任务数
taskRetry: 1, // 任务重试次数
taskLoopTime: 1e3, // 任务轮询时间
});
const executor = threadPool.createExecutor();worker.js
const fibonaccis = (n) => {
if (n {
return fibonaccis(value);
}threadPool.exec(15).then((res) => {
console.log(+res.data === 610)
});
executor
.setTaskRetry(2) // 不影响 pool 的全局设置
.setTaskTimeout(2e3) // 不影响 pool 的全局设置
.exec(15).then((res) => {
console.log(+res.data === 610)
});const { DynamicThreadPool } = require(`electron-re`);
const threadPool = new DynamicThreadPool({
maxThreads: 24, // 最大线程数
maxTasks: 48, // 最大任务数
taskRetry: 1, // 任务重试次数
});
const executor = threadPool.createExecutor({
execFunction: (value) => { return 'dynamic:' + value; },
});
threadPool.exec('test', {
execString: `module.exports = (value) => { return 'dynamic:' + value; };`,
});
executor.exec('test');
executor
.setExecPath('/path/to/exec-file.js')
.exec('test');暂未在项目中实际使用，可考虑在前端图片像素处理、音视频转码处理等 CPU 密集性任务中进行实践。
这里有篇文章写了 web_worker 的一些应用场景，web_worker 和 worker_threads 是类似的，宿主环境不同，一些权限和能力的不同而已。
最開始專案 做為Electron 應用程式開發的工具集提供了 BrowserService / ChildProcessPool / 簡易進程監控UI /進程間通訊 等功能，線程池的加入其實是當初沒有計劃的，而且線程池本身是獨立的，不依賴electron-re 中其它模組功能，之後應該會被獨立出去。
進程池和執行緒池的實作方案上還需完善。
例如進程池未支援子進程空閒時自動退出以解除資源佔用，當時做了另一版監聽 ProcessHost 的任務執行情況來讓子進程空閒時休眠，想透過此方式節省資源佔用。不過由於沒有node.js API 級別的支援以分辨子進程空閒的情況，並且子進程的休眠/ 喚醒功能比較雞肋(有嘗試通過向子進程發送SIGSTOP/SIGCONT 信號實現)，最終這個特性被廢除了。
後面可以考慮支援 CPU/Memory 的負載平衡演算法，目前已經透過專案中的 ProcessManager 模組來實現資源佔用情況採集了。
線程池方面相對的可用度還是較高，提供了pool/excutor 兩個層級的調用管理，支持鍊式調用，在一些需要提升數據傳輸性能的場景支持transferList 方式避免資料克隆。相對於其它開源 Node 執行緒池方案，著重對任務佇列功能進行了加強，支援任務重試、任務逾時等功能。
更多node相關知識，請造訪：nodejs 教學！
以上是聊聊使用Node如何實現輕量化進程池和執行緒池的詳細內容。更多資訊請關注PHP中文網其他相關文章！
