Node 定时器

Last updated Aug 19, 2022

在介绍child_process模块之前，先来看一个例子。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

const http = require('http');
const longComputation = () => {
  let sum = 0;
  for (let i = 0; i < 1e10; i++) {
    sum += i;
  };
  return sum;
};
const server = http.createServer();
server.on('request', (req, res) => {
  if (req.url === '/compute') {
    const sum = longComputation();
    return res.end(`Sum is ${sum}`);
  } else {
    res.end('Ok')
  }
});

server.listen(3000);

可以试一下使用上面的代码启动Node.js服务，然后打开两个浏览器选项卡分别访问/compute和/，可以发现node服务接收到/compute请求时会进行大量的数值计算，导致无法响应其他的请求（/）。

在Java语言中可以通过多线程的方式来解决上述的问题，但是Node.js在代码执行的时候是单线程的，那么Node.js应该如何解决上面的问题呢？其实Node.js可以创建一个子进程执行密集的cpu计算任务（例如上面例子中的longComputation）来解决问题，而child_process模块正是用来创建子进程的。

child_process提供了几种创建子进程的方式

• 异步方式：spawn、exec、execFile、fork
• 同步方式：spawnSync、execSync、execFileSync

首先介绍一下spawn方法

1
2
3
4
5
6
7
8

child_process.spawn(command[, args][, options])

command： 要执行的指令
args：    传递参数
options： 配置项

const { spawn } = require('child_process');
const child = spawn('pwd');

pwd是shell的命令，用于获取当前的目录，上面的代码执行完控制台并没有任何的信息输出，这是为什么呢？

控制台之所以不能看到输出信息的原因是由于子进程有自己的stdio流（stdin、stdout、stderr），控制台的输出是与当前进程的stdio绑定的，因此如果希望看到输出信息，可以通过在子进程的stdout 与当前进程的stdout之间建立管道实现

1

child.stdout.pipe(process.stdout);

也可以监听事件的方式（子进程的stdio流都是实现了EventEmitter API的，所以可以添加事件监听）

1
2
3

child.stdout.on('data', function(data) {
  process.stdout.write(data);
});

在Node.js代码里使用的console.log其实底层依赖的就是process.stdout

除了建立管道之外，还可以通过子进程和当前进程共用stdio的方式来实现

1
2
3
4

const { spawn } = require('child_process');
const child = spawn('pwd', {
  stdio: 'inherit'
});

stdio选项用于配置父进程和子进程之间建立的管道，由于stdio管道有三个(stdin, stdout, stderr）因此stdio的三个可能的值其实是数组的一种简写

• pipe 相当于[‘pipe’, ‘pipe’, ‘pipe’]（默认值）
• ignore 相当于[‘ignore’, ‘ignore’, ‘ignore’]
• inherit 相当于[process.stdin, process.stdout, process.stderr]

由于inherit方式使得子进程直接使用父进程的stdio，因此可以看到输出

ignore用于忽略子进程的输出（将/dev/null指定为子进程的文件描述符了），因此当ignore时child.stdout是null。

spawn默认情况下并不会创建子shell来执行命令，因此下面的代码会报错

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

const { spawn } = require('child_process');
const child = spawn('ls -l');
child.stdout.pipe(process.stdout);

// 报错
events.js:167
      throw er; // Unhandled 'error' event
      ^

Error: spawn ls -l ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:229:19)
    at onErrorNT (internal/child_process.js:406:16)
    at process._tickCallback (internal/process/next_tick.js:63:19)
    at Function.Module.runMain (internal/modules/cjs/loader.js:746:11)
    at startup (internal/bootstrap/node.js:238:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:572:3)
Emitted 'error' event at:
    at Process.ChildProcess._handle.onexit (internal/child_process.js:235:12)
    at onErrorNT (internal/child_process.js:406:16)
    [... lines matching original stack trace ...]
    at bootstrapNodeJSCore (internal/bootstrap/node.js:572:3)

如果需要传递参数的话，应该采用数组的方式传入

1
2
3

const { spawn } = require('child_process');
const child = spawn('ls', ['-l']);
child.stdout.pipe(process.stdout);

如果要执行ls -l | wc -l命令的话可以采用创建两个spawn命令的方式

1
2
3
4
5

const { spawn } = require('child_process');
const child = spawn('ls', ['-l']);
const child2 = spawn('wc', ['-l']);
child.stdout.pipe(child2.stdin);
child2.stdout.pipe(process.stdout);

也可以使用exec

1
2
3
4

const { exec } = require('child_process');
exec('ls -l | wc -l', function(err, stdout, stderr) {
  console.log(stdout);
});

由于exec会创建子shell，所以可以直接执行shell管道命令。spawn采用流的方式来输出命令的执行结果，而exec也是将命令的执行结果缓存起来统一放在回调函数的参数里面，因此exec只适用于命令执行结果数据小的情况。

其实spawn也可以通过配置shell option的方式来创建子shell进而支持管道命令，如下所示

1
2
3
4
5

const { spawn, execFile } = require('child_process');
const child = spawn('ls -l | wc -l', {
  shell: true
});
child.stdout.pipe(process.stdout);

配置项除了stdio、shell之外还有cwd、env、detached等常用的选项

cwd用于修改命令的执行目录

1
2
3
4
5
6

const { spawn, execFile, fork } = require('child_process');
const child = spawn('ls -l | wc -l', {
  shell: true,
  cwd: '/usr'
});
child.stdout.pipe(process.stdout);

env用于指定子进程的环境变量（如果不指定的话，默认获取当前进程的环境变量）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

const { spawn, execFile, fork } = require('child_process');
const child = spawn('echo $NODE_ENV', {
  shell: true,
  cwd: '/usr'
});
child.stdout.pipe(process.stdout);
NODE_ENV=randal node b.js

// 输出结果
randal

如果指定env的话就会覆盖掉默认的环境变量，如下

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

const { spawn, execFile, fork } = require('child_process');
spawn('echo $NODE_TEST $NODE_ENV', {
  shell: true,
  stdio: 'inherit',
  cwd: '/usr',
  env: {
    NODE_TEST: 'randal-env'
  }
});

NODE_ENV=randal node b.js

// 输出结果
randal-env

detached用于将子进程与父进程断开连接

例如假设存在一个长时间运行的子进程

1
2
3
4

// timer.js
while(true) {

}

但是主进程并不需要长时间运行的话就可以用detached来断开二者之间的连接

1
2
3
4
5
6

const { spawn, execFile, fork } = require('child_process');
const child = spawn('node', ['timer.js'], {
  detached: true,
  stdio: 'ignore'
});
child.unref();

当调用子进程的unref方法时，同时配置子进程的stdio为ignore时，父进程就可以独立退出了

execFile与exec不同，execFile通常用于执行文件，而且并不会创建子shell环境

fork方法是spawn方法的一个特例，fork用于执行js文件创建Node.js子进程。而且fork方式创建的子进程与父进程之间建立了IPC通信管道，因此子进程和父进程之间可以通过send的方式发送消息。

注意：fork方式创建的子进程与父进程是完全独立的，它拥有单独的内存，单独的V8实例，因此并不推荐创建很多的Node.js子进程

fork方式的父子进程之间的通信参照下面的例子

parent.js

1
2
3
4
5
6
7
8
9

const { fork } = require('child_process');

const forked = fork('child.js');

forked.on('message', (msg) => {
  console.log('Message from child', msg);
});

forked.send({ hello: 'world' });

child.js

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

process.on('message', (msg) => {
  console.log('Message from parent:', msg);
});

let counter = 0;

setInterval(() => {
  process.send({ counter: counter++ });
}, 1000);
//------------------
node parent.js

// 输出结果
Message from parent: { hello: 'world' }
Message from child { counter: 0 }
Message from child { counter: 1 }
Message from child { counter: 2 }
Message from child { counter: 3 }
Message from child { counter: 4 }
Message from child { counter: 5 }
Message from child { counter: 6 }

回到本文初的那个问题，我们就可以将密集计算的逻辑放到单独的js文件中，然后再通过fork的方式来计算，等计算完成时再通知主进程计算结果，这样避免主进程繁忙的情况了。

compute.js

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

const longComputation = () => {
  let sum = 0;
  for (let i = 0; i < 1e10; i++) {
    sum += i;
  };
  return sum;
};

process.on('message', (msg) => {
  const sum = longComputation();
  process.send(sum);
});

index.js

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

const http = require('http');
const { fork } = require('child_process');

const server = http.createServer();

server.on('request', (req, res) => {
  if (req.url === '/compute') {
    const compute = fork('compute.js');
    compute.send('start');
    compute.on('message', sum => {
      res.end(`Sum is ${sum}`);
    });
  } else {
    res.end('Ok')
  }
});

server.listen(3000);

通过前述几种方式创建的子进程都实现了EventEmitter，因此可以针对进程进行事件监听

常用的事件包括几种：close、exit、error、message

close事件当子进程的stdio流关闭的时候才会触发，并不是子进程exit的时候close事件就一定会触发，因为多个子进程可以共用相同的stdio。

close与exit事件的回调函数有两个参数code和signal，code代码子进程最终的退出码，如果子进程是由于接收到signal信号终止的话，signal会记录子进程接受的signal值。

先看一个正常退出的例子

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

const { spawn, exec, execFile, fork } = require('child_process');
const child = exec('ls -l', {
  timeout: 300
});
child.on('exit', function(code, signal) {
  console.log(code);
  console.log(signal);
});

// 输出结果
0
null

再看一个因为接收到signal而终止的例子，应用之前的timer文件，使用exec执行的时候并指定timeout

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

const { spawn, exec, execFile, fork } = require('child_process');
const child = exec('node timer.js', {
  timeout: 300
});
child.on('exit', function(code, signal) {
  console.log(code);
  console.log(signal);
});
// 输出结果
null
SIGTERM

注意：由于timeout超时的时候error事件并不会触发，并且当error事件触发时exit事件并不一定会被触发

error事件的触发条件有以下几种：

• 无法创建进程
• 无法结束进程
• 给进程发送消息失败

注意当代码执行出错的时候，error事件并不会触发，exit事件会触发，code为非0的异常退出码

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

const { spawn, exec, execFile, fork } = require('child_process');
const child = exec('ls -l /usrs');
child.on('error', function(code, signal) {
  console.log(code);
  console.log(signal);
});
child.on('exit', function(code, signal) {
  console.log('exit');
  console.log(code);
  console.log(signal);
});

// 输出结果
exit
1
null

message事件适用于父子进程之间建立IPC通信管道的时候的信息传递，传递的过程中会经历序列化与反序列化的步骤，因此最终接收到的并不一定与发送的数据相一致。

1
2
3
4
5
6
7
8
9

//sub.js
process.send({ foo: 'bar', baz: NaN });
//main.js
const cp = require('child_process');
const n = cp.fork(`${__dirname}/sub.js`);

n.on('message', (m) => {
  console.log('got message:', m);   // got message: { foo: 'bar', baz: null }
});

关于message有一种特殊情况要注意，下面的message并不会被子进程接收到

1
2
3
4
5
6
7
8

const { fork } = require('child_process');

const forked = fork('child.js');

forked.send({
  cmd: "NODE_foo",
  hello: 'world'
});

当发送的消息里面包含cmd属性，并且属性的值是以NODE_开头的话，这样的消息是提供给Node.js本身保留使用的，因此并不会发出message事件，而是会发出internalMessage事件，开发者应该避免这种类型的消息，并且应当避免监听internalMessage事件。

message除了发送字符串、object之外还支持发送server对象和socket对象，正因为支持socket对象才可以做到多个Node.js进程监听相同的端口号。

未完待续……

单个 Node.js 实例运行在单个线程中。 为了充分利用多核系统，有时需要启用一组 Node.js 进程去处理负载任务。

集群有以下两种常见的实现方案，而node自带的cluster模块，采用了方案二。

1. 方案一：多个node实例+多个端口

集群内的node实例，各自监听不同的端口，再由反向代理实现请求到多个端口的分发。

• 优点：实现简单，各实例相对独立，这对服务稳定性有好处。
• 缺点：增加端口占用，进程之间通信比较麻烦。

2. 方案二：主进程向子进程转发请求

集群内，创建一个主进程(master)，以及若干个子进程(worker)。由master监听客户端连接请求，并根据特定的策略，转发给worker。

• 优点：通常只占用一个端口，通信相对简单，转发策略更灵活。
• 缺点：实现相对复杂，对主进程的稳定性要求较高。

cluster 模块可以创建共享服务器端口的子进程。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

const cluster = require('cluster');
const http = require('http');
const numCPUs = require('os').cpus().length;

if (cluster.isMaster) {
  console.log(`主进程 ${process.pid} 正在运行`);

  // 衍生工作进程。
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`工作进程 ${worker.process.pid} 已退出`);
  });
} else {
  // 工作进程可以共享任何 TCP 连接。
  // 在本例子中，共享的是 HTTP 服务器。
  http.createServer((req, res) => {
    res.writeHead(200);
    // res.end('你好世界\n');
    res.end(`response from worker ${process.pid}`);
  }).listen(8000);

  console.log(`工作进程 ${process.pid} 已启动`);
}

运行代码，则工作进程会共享 8000 端口：

1
2
3
4
5
6

$ node server.js
主进程 3596 正在运行
工作进程 4324 已启动
工作进程 4520 已启动
工作进程 6056 已启动
工作进程 5644 已启动

在 Windows 上，尚无法在工作进程中设置命名管道服务器。

创建批处理脚本：./req.sh。

1
2
3
4
5
6
7

#!/bin/bash

# req.sh
for((i=1;i<=4;i++)); do   
  curl http://127.0.0.1:3000
  echo ""
done 

输出如下。可以看到，响应来自不同的进程。

1
2
3
4

response from worker 23735
response from worker 23731
response from worker 23729
response from worker 23730

这个问题比较简单。master进程通过 cluster.fork() 来创建 worker进程。cluster.fork() 内部 是通过 child_process.fork() 来创建子进程。

也就是说：

1. master进程、worker进程是父、子进程的关系。
2. master进程、woker进程可以通过IPC通道进行通信。（重要）

在前面的例子中，多个woker中创建的server监听了同个端口3000。通常来说，多个进程监听同个端口，系统会报错。

为什么我们的例子没问题呢？

秘密在于，net模块中，对 listen() 方法进行了特殊处理。根据当前进程是master进程，还是worker进程：

1. master进程：在该端口上正常监听请求。（没做特殊处理）
2. worker进程：创建server实例。然后通过IPC通道，向master进程发送消息，让master进程也创建 server 实例，并在该端口上监听请求。当请求进来时，master进程将请求转发给worker进程的server实例。

归纳起来，就是：master进程监听特定端口，并将客户请求转发给worker进程。

如下图所示：

每当worker进程创建server实例来监听请求，都会通过IPC通道，在master上进行注册。当客户端请求到达，master会负责将请求转发给对应的worker。

具体转发给哪个worker？这是由转发策略决定的。可以通过环境变量NODE_CLUSTER_SCHED_POLICY设置，也可以在cluster.setupMaster(options)时传入。

默认的转发策略是轮询（SCHED_RR）。

当有客户请求到达，master会轮询一遍worker列表，找到第一个空闲的worker，然后将该请求转发给该worker。

文档

process 对象是一个全局变量，它提供有关当前 Node.js 进程的信息并对其进行控制。 作为一个全局变量，它始终可供 Node.js 应用程序使用，无需使用 require()。 它也可以使用 require() 显式地访问：

1

const process = require('process');

process.env 属性返回包含用户环境的对象。

此对象的示例如下所示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{
  TERM: 'xterm-256color',
  SHELL: '/usr/local/bin/bash',
  USER: 'maciej',
  PATH: '~/.bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin',
  PWD: '/Users/maciej',
  EDITOR: 'vim',
  SHLVL: '1',
  HOME: '/Users/maciej',
  LOGNAME: 'maciej',
  _: '/usr/local/bin/node'
}

可以修改此对象，但这些修改不会反映到 Node.js 进程之外，或者（除非明确请求）反映到其他 Worker 线程。 换句话说，以下示例不起作用：

1

$ node -e 'process.env.foo = "bar"' && echo $foo

以下示例则起作用：

1
2

process.env.foo = 'bar';
console.log(process.env.foo);

在 process.env 上分配属性将隐式地将值转换为字符串。 不推荐使用此行为。 当值不是字符串、数字或布尔值时，Node.js 的未来版本可能会抛出错误。

1
2
3
4
5
6

process.env.test = null;
console.log(process.env.test);
// => 'null'
process.env.test = undefined;
console.log(process.env.test);
// => 'undefined'

使用 delete 可以从 process.env 中删除属性。

1
2
3
4

process.env.TEST = 1;
delete process.env.TEST;
console.log(process.env.TEST);
// => undefined

在 Windows 操作系统上，环境变量不区分大小写。

1
2
3

process.env.TEST = 1;
console.log(process.env.test);
// => 1

除非在创建 Worker 实例时明确指定，否则每个 Worker 线程都有自己的 process.env 副本，基于其父线程的 process.env，或者指定为 Worker 构造函数的 env 选项的任何内容。 对于 process.env 的更改将在 Worker 线程中不可见，并且只有主线程可以进行对操作系统或本机加载项可见的更改。

资源使用指运行此进程所消耗的机器资源。例如内存、cpu

1
2
3
4
5
6
7

process.memoryUsage())

{ rss: 21848064,
  heapTotal: 7159808,
  heapUsed: 4431688,
  external: 8224 
 }

rss(常驻内存)的组成见下图

code segment 对应当前运行的代码

external 对应的是C++对象（与V8管理的JS对象绑定）的占用的内存，比如Buffer的使用

1
2
3
4
5
6
7
8

Buffer.allocUnsafe(1024 * 1024 * 1000);
console.log(process.memoryUsage());

{ rss: 22052864,
  heapTotal: 6635520,
  heapUsed: 4161376,
  external: 1048584224 }
复制代码

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

const startUsage = process.cpuUsage();
console.log(startUsage);

const now = Date.now();
while (Date.now() - now < 500);

console.log(process.cpuUsage());
console.log(process.cpuUsage(startUsage)); //相对时间

// { user: 59459, system: 18966 }
// { user: 558135, system: 22312 }
// { user: 498432, system: 3333 }

user对应用户时间，system代表系统时间

运行环境指此进程运行的宿主环境包括运行目录、node环境、CPU架构、用户环境、系统平台

1
2
3

console.log(`Current directory: ${process.cwd()}`);

// Current directory: /Users/xxxx/workspace/learn/node-basic/process

1
2
3

console.log(process.version)

// v9.1.0

如果不仅仅希望获得node的版本信息，还希望v8、zlib、libuv版本等信息的话就需要使用process.versions了

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

console.log(process.versions);
{ http_parser: '2.7.0',
  node: '9.1.0',
  v8: '6.2.414.32-node.8',
  uv: '1.15.0',
  zlib: '1.2.11',
  ares: '1.13.0',
  modules: '59',
  nghttp2: '1.25.0',
  openssl: '1.0.2m',
  icu: '59.1',
  unicode: '9.0',
  cldr: '31.0.1',
  tz: '2017b' }

1
2
3

console.log(`This processor architecture is ${process.arch}`);

// This processor architecture is x64

支持的值包括：'arm', 'arm64', 'ia32', 'mips', 'mipsel', 'ppc', 'ppc64', 's390', 's390x', 'x32' 'x64'

1
2
3

console.log(process.env.NODE_ENV); // dev

NODE_ENV=dev node b.js

除了启动时的自定义信息之外，process.env还可以获得其他的用户环境信息（比如PATH、SHELL、HOME等），感兴趣的可以自己打印一下试试

1
2
3

console.log(`This platform is ${process.platform}`);

This platform is darwin

支持的系统平台包括：'aix' 'darwin' 'freebsd' 'linux' 'openbsd' 'sunos' 'win32'

android目前还处于试验阶段

运行状态指当前进程的运行相关的信息包括启动参数、执行目录、主文件、PID信息、运行时间

获取启动参数有三个方法，execArgv获取Node.js的命令行选项（见 官网文档）

argv获取非命令行选项的信息，argv0则获取argv[0]的值（略有差异)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

console.log(process.argv)
console.log(process.argv0)
console.log(process.execArgv)

node --harmony  b.js foo=bar --version

// 输出结果
[ '/Users/xiji/.nvm/versions/node/v9.1.0/bin/node',
  '/Users/xiji/workspace/learn/node-basic/process/b.js',
  'foo=bar',
  '--version' ]
node
[ '--harmony' ]

1
2
3

console.log(process.execPath);

// /Users/xxxx/.nvm/versions/node/v9.1.0/bin/node

1
2
3

var date = new Date();
while(new Date() - date < 500) {}
console.log(process.uptime()); // 0.569

除了require.main之外也可以通过process.mainModule来判断一个模块是否是主文件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

//a.js
console.log(`module A: ${process.mainModule === module}`);

//b.js
require('./a');
console.log(`module B: ${process.mainModule === module}`);

node b.js
// 输出
module A: false
module B: true

PID信息

1

console.log(`This process is pid ${process.pid}`); //This process is pid 12554

process是EventEmiiter的实例对象，因此可以使用process.on(’eventName’, () => {})来监听事件。 常用的事件类型分两种：

• 进程状态 比如：beforeExit、exit、uncaughtException、message
• 信号事件 比如：SIGTERM、SIGKILL、SIGUSR1

beforeExit与exit的区别有两方面：

• beforeExit里面可以执行异步代码、exit只能是同步代码
• 手动调用process.exit()或者触发uncaptException导致进程退出不会触发beforeExit事件、exit事件会触发。

因此下面的代码console都不会被执行

1
2
3
4
5
6
7
8
9

process.on('beforeExit', function(code) {
  console.log('before exit: '+ code);
});
process.on('exit', function(code) {
  setTimeout(function() {
    console.log('exit: ' + code);
  }, 0);
});
a.b();

当异常一直没有被捕获处理的话，最后就会触发’uncaughtException’事件。默认情况下，Node.js会打印堆栈信息到stderr然后退出进程。不要试图阻止uncaughtException退出进程，因此此时程序的状态可能已经不稳定了，建议的方式是及时捕获处理代码中的错误，uncaughtException里面只做一些清理工作。

注意：node的9.3版本增加了process.setUncaughtExceptionCaptureCallback方法

当process.setUncaughtExceptionCaptureCallback(fn)指定了监听函数的时候，uncaughtException事件将会不再被触发。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

process.on('uncaughtException', function() {
  console.log('uncaught listener');
});

process.setUncaughtExceptionCaptureCallback(function() {
  console.log('uncaught fn');
});

a.b();
// uncaught fn

message适用于父子进程之间发送消息，关于如何创建父子进程请参见 child_process模块解读。

SIGTERM信号虽然也是用于请求终止Node.js进程，但是它与SIGKILL有所不同，进程可以选择响应还是忽略此信号。 SIGTERM会以一种友好的方式来结束进程，在进程结束之前先释放已分配的资源（比如数据库连接），因此这种方式被称为优雅关闭(graceful shutdown) 具体的执行步骤如下：

• 应用程序被通知需要关闭（接收到SIGTERM信号）
• 应用程序通知负载均衡不再接收新的请求
• 应用程序完成正在进行中的请求
• 释放资源（例如数据库连接）
• 应用程序正常退出，退出状态码为0

SIGUSR1 Node.js当接收到SIGUSR1信号时会启动内置的调试器，当执行下列操作时

1

kill -USR1 PID_OF_THE_NODE_JS_PROCESS

可以看到node.js会启动调试器代理，端口是9229

1
2
3

server is listening 8089
Debugger listening on ws://127.0.0.1:9229/7ef98ccb-02fa-451a-8954-4706bd74105f
For help, see: https://nodejs.org/en/docs/inspector

也可以在服务启动时使用–inspect 来启动调试代理

1

node --inspect index.js

详见目录 定时器

process.nextTick(fn)

通过process.nextTick调度的任务是异步任务，EventLoop是分阶段的，每个阶段执行特定的任务，而nextTick的任务在阶段切换的时候就会执行，因此nextTick会比setTimeout(fn, 0)更快的执行，关于EventLoop见下。

Node.js是单线程的，除了系统IO之外，在它的事件轮询过程中，同一时间只会处理一个事件。你可以把事件轮询想象成一个大的队列，在每个时间点上，系统只会处理一个事件。即使你的电脑有多个CPU核心，你也无法同时并行的处理多个事件。但也就是这种特性使得node.js适合处理I／O型的应用，不适合那种CPU运算型的应用。在每个I／O型的应用中，你只需要给每一个输入输出定义一个回调函数即可，他们会自动加入到事件轮询的处理队列里。当I／O操作完成后，这个回调函数会被触发。然后系统会继续处理其他的请求。

在这种处理模式下，process.nextTick()的意思就是定义出一个动作，并且让这个动作在下一个事件轮询的时间点上执行。我们来看一个例子。例子中有一个foo()，你想在下一个时间点上调用他，可以这么做：

1
2
3
4
5
6

function foo() {
    console.error('foo');
}

process.nextTick(foo);
console.error('bar');

运行上面的代码，你从下面终端打印的信息会看到，“bar"的输出在“foo”的前面。这就验证了上面的说法，foo()是在下一个时间点运行的。

1
2

bar
foo 

你也可以使用setTimeout()函数来达到貌似同样的执行效果：

1
2

setTimeout(foo, 0);
console.log('bar');

但在内部的处理机制上，process.nextTick()和setTimeout(fn, 0)是不同的，process.nextTick()不是一个单纯的延时，他有更多的 特性。

更精确的说，process.nextTick()定义的调用会创建一个新的子堆栈。在当前的栈里，你可以执行任意多的操作。但一旦调用netxTic k，函数就必须返回到父堆栈。然后事件轮询机制又重新等待处理新的事件，如果发现nextTick的调用，就会创建一个新的栈。

1
2
3
4
5
6

process.emitWarning('Something warning happened!', {
  code: 'MY_WARNING',
  type: 'XXXX'
});

// (node:14771) [MY_WARNING] XXXX: Something warning happened!

当type为DeprecationWarning时，可以通过命令行选项施加影响

• --throw-deprecation 会抛出异常
• --no-deprecation 不输出DeprecationWarning
• --trace-deprecation 打印详细堆栈信息

1
2
3
4
5
6
7
8

process.emitWarning('Something warning happened!', {
  type: 'DeprecationWarning'
});
console.log(4);

node --throw-deprecation index.js
node --no-deprecation index.js
node --trace-deprecation index.js

JavaScript 是单线程运行，异步操作特别重要。

只要用到引擎之外的功能，就需要跟外部交互，从而形成异步操作。由于异步操作实在太多，JavaScript 不得不提供很多异步语法。这就好比，有些人老是受打击， 他的抗打击能力必须变得很强，否则他就完蛋了。

Node 的异步语法比浏览器更复杂，因为它可以跟内核对话，不得不搞了一个专门的库 libuv 做这件事。这个库负责各种回调函数的执行时间，毕竟异步任务最后还是要回到主线程，一个个排队执行。

为了协调异步任务，Node 居然提供了四个定时器，让任务可以在指定的时间运行。

• setTimeout()
• setInterval()
• setImmediate()
• process.nextTick()

前两个是语言的标准，后两个是 Node 独有的。它们的写法差不多，作用也差不多，不太容易区别。

你能说出下面代码的运行结果吗？

1 2 3 4 5 6

// test.js setTimeout(() => console.log(1)); setImmediate(() => console.log(2)); process.nextTick(() => console.log(3)); Promise.resolve().then(() => console.log(4)); (() => console.log(5))();

运行结果如下。

1 2 3 4 5 6

$ node test.js 5 3 4 1 2

如果你能一口说对，可能就不需要再看下去了。本文详细解释，Node 怎么处理各种定时器，或者更广义地说，libuv 库怎么安排异步任务在主线程上执行。

首先，同步任务总是比异步任务更早执行。

前面的那段代码，只有最后一行是同步任务，因此最早执行。

1	(() => console.log(5))();

异步任务可以分成两种。

• 追加在本轮循环的异步任务
• 追加在次轮循环的异步任务

所谓"循环”，指的是事件循环（event loop）。这是 JavaScript 引擎处理异步任务的方式，后文会详细解释。这里只要理解，本轮循环一定早于次轮循环执行即可。

Node 规定，process.nextTick和Promise的回调函数，追加在本轮循环，即同步任务一旦执行完成，就开始执行它们。而setTimeout、setInterval、setImmediate的回调函数，追加在次轮循环。

这就是说，文首那段代码的第三行和第四行，一定比第一行和第二行更早执行。

1 2 3 4 5 6

// 下面两行，次轮循环执行 setTimeout(() => console.log(1)); setImmediate(() => console.log(2)); // 下面两行，本轮循环执行 process.nextTick(() => console.log(3)); Promise.resolve().then(() => console.log(4));

process.nextTick这个名字有点误导，它是在本轮循环执行的，而且是所有异步任务里面最快执行的。

Node 执行完所有同步任务，接下来就会执行process.nextTick的任务队列。所以，下面这行代码是第二个输出结果。

1	process.nextTick(() => console.log(3));

基本上，如果你希望异步任务尽可能快地执行，那就使用process.nextTick。

根据语言规格，Promise对象的回调函数，会进入异步任务里面的"微任务"（microtask）队列。

微任务队列追加在process.nextTick队列的后面，也属于本轮循环。所以，下面的代码总是先输出3，再输出4。

1 2 3 4

process.nextTick(() => console.log(3)); Promise.resolve().then(() => console.log(4)); // 3 // 4

注意，只有前一个队列全部清空以后，才会执行下一个队列。

1 2 3 4 5 6 7 8

process.nextTick(() => console.log(1)); Promise.resolve().then(() => console.log(2)); process.nextTick(() => console.log(3)); Promise.resolve().then(() => console.log(4)); // 1 // 3 // 2 // 4

上面代码中，全部process.nextTick的回调函数，执行都会早于Promise的。

至此，本轮循环的执行顺序就讲完了。

1. 同步任务
2. process.nextTick()
3. 微任务

下面开始介绍次轮循环的执行顺序，这就必须理解什么是事件循环（event loop）了。

Node 的 官方文档是这样介绍的。

“When Node.js starts, it initializes the event loop, processes the provided input script which may make async API calls, schedule timers, or call process.nextTick(), then begins processing the event loop.”

这段话很重要，需要仔细读。它表达了三层意思。

首先，有些人以为，除了主线程，还存在一个单独的事件循环线程。不是这样的，只有一个主线程，事件循环是在主线程上完成的。

其次，Node 开始执行脚本时，会先进行事件循环的初始化，但是这时事件循环还没有开始，会先完成下面的事情。

• 同步任务
• 发出异步请求
• 规划定时器生效的时间
• 执行process.nextTick()等等

最后，上面这些事情都干完了，事件循环就正式开始了。

事件循环会无限次地执行，一轮又一轮。只有异步任务的回调函数队列清空了，才会停止执行。

每一轮的事件循环，分成六个阶段。这些阶段会依次执行。

1. timers
2. I/O callbacks
3. idle, prepare
4. poll
5. check
6. close callbacks

每个阶段都有一个先进先出的回调函数队列。只有一个阶段的回调函数队列清空了，该执行的回调函数都执行了，事件循环才会进入下一个阶段。

下面简单介绍一下每个阶段的含义，详细介绍可以看 官方文档，也可以参考 libuv 的 源码解读。

（1）timers

这个是定时器阶段，处理setTimeout()和setInterval()的回调函数。进入这个阶段后，主线程会检查一下当前时间，是否满足定时器的条件。如果满足就执行回调函数，否则就离开这个阶段。

（2）I/O callbacks

除了以下操作的回调函数，其他的回调函数都在这个阶段执行。

• setTimeout()和setInterval()的回调函数
• setImmediate()的回调函数
• 用于关闭请求的回调函数，比如socket.on('close', …)

（3）idle, prepare

该阶段只供 libuv 内部调用，这里可以忽略。

（4）Poll

这个阶段是轮询时间，用于等待还未返回的 I/O 事件，比如服务器的回应、用户移动鼠标等等。

这个阶段的时间会比较长。如果没有其他异步任务要处理（比如到期的定时器），会一直停留在这个阶段，等待 I/O 请求返回结果。

（5）check

该阶段执行setImmediate()的回调函数。

（6）close callbacks

该阶段执行关闭请求的回调函数，比如socket.on('close', …)。

下面是来自官方文档的一个示例。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

const fs = require('fs'); const timeoutScheduled = Date.now(); // 异步任务一：100ms 后执行的定时器 setTimeout(() => { const delay = Date.now() - timeoutScheduled; console.log(`${delay}ms`); }, 100); // 异步任务二：文件读取后，有一个 200ms 的回调函数 fs.readFile('test.js', () => { const startCallback = Date.now(); while (Date.now() - startCallback < 200) { // 什么也不做 } });

上面代码有两个异步任务，一个是 100ms 后执行的定时器，一个是文件读取，它的回调函数需要 200ms。请问运行结果是什么？

脚本进入第一轮事件循环以后，没有到期的定时器，也没有已经可以执行的 I/O 回调函数，所以会进入 Poll 阶段，等待内核返回文件读取的结果。由于读取小文件一般不会超过 100ms，所以在定时器到期之前，Poll 阶段就会得到结果，因此就会继续往下执行。

第二轮事件循环，依然没有到期的定时器，但是已经有了可以执行的 I/O 回调函数，所以会进入 I/O callbacks 阶段，执行fs.readFile的回调函数。这个回调函数需要 200ms，也就是说，在它执行到一半的时候，100ms 的定时器就会到期。但是，必须等到这个回调函数执行完，才会离开这个阶段。

第三轮事件循环，已经有了到期的定时器，所以会在 timers 阶段执行定时器。最后输出结果大概是200多毫秒。

由于setTimeout在 timers 阶段执行，而setImmediate在 check 阶段执行。所以，setTimeout会早于setImmediate完成。

1 2	setTimeout(() => console.log(1)); setImmediate(() => console.log(2));

上面代码应该先输出1，再输出2，但是实际执行的时候，结果却是不确定，有时还会先输出2，再输出1。

这是因为setTimeout的第二个参数默认为0。但是实际上，Node 做不到0毫秒，最少也需要1毫秒，根据 官方文档，第二个参数的取值范围在1毫秒到2147483647毫秒之间。也就是说，setTimeout(f, 0)等同于setTimeout(f, 1)。

实际执行的时候，进入事件循环以后，有可能到了1毫秒，也可能还没到1毫秒，取决于系统当时的状况。如果没到1毫秒，那么 timers 阶段就会跳过，进入 check 阶段，先执行setImmediate的回调函数。

但是，下面的代码一定是先输出2，再输出1。

1 2 3 4 5 6

const fs = require('fs'); fs.readFile('test.js', () => { setTimeout(() => console.log(1)); setImmediate(() => console.log(2)); });

上面代码会先进入 I/O callbacks 阶段，然后是 check 阶段，最后才是 timers 阶段。因此，setImmediate才会早于setTimeout执行。