Process模块 (Features of Process)
process is a global variable which indicates the current Node.js process.
It is actually an instance of EventEmiter, which is used to subscribe events and emit messages to specific events, for more information, you may refer to offical docs.
'process' includes several common used features, we will have an outline below.
process.argv
process.argv returns an array containing the command line arguments, it's quite useful when we need to identify some special conditions.
We firstly create a file below and run it in the command line:
const {argv} = process;
argv.forEach((value, index) => {
console.log(`${index}: ${value}`);
});
$ node argv.js test name=scott --dev
The code will demonstrates how we obtain the actual arguments from command line:
0: /usr/local/bin/node
1: /Users/scott/process/argv.js
2: test
3: name=scott
4: --dev
The first element indicates the absolute pathname of the executable that started the Node.js process, it's identical to process.execPath. And the second one is the absolute pathname of JavaScript file being executed. For the rest, they are additional command line arguments.
process.execArgv
process.execArgv will hold the set of Node.js-specific command-line options passed when the Node.js process was launched. These options are useful in order to spawn child processes with the same execution environment as the parent, and they are prior to the JavaScript file in command line:
$ node --harmony script.js --version
Results in 'process.execArgv':
['--harmony']
process.nextTick(callback[, ...args])
The process.nextTick() method adds the callback to the 'next tick queue'. Once the current turn of the event loop turn runs to completion, all callbacks currently in the next tick queue will be called.
This is not a simple alias to 'setTimeout(fn, 0)'. It is much more efficient. It runs before any additional I/O events (including timers) fire in subsequent ticks of the event loop.
It should be noted that, the next tick queue is completely drained on each pass of the event loop before additional I/O is processed. As a result, recursively setting nextTick() callbacks will block any I/O from happening, just like a 'while(true);' loop.
process.exit([code]);
process.exit() method instructs Node.js to terminate the process synchronously with an exit status of code. If code is omitted, exit uses either the 'success' code '0' or the value of 'process.exitCode' if it has been set. Node.js will not terminate until all the 'exit' event listeners are called.
Calling 'process.exit()' will force the process to exit as quickly as possible even if there are still asynchronous operations pending that have not yet completed fully, including I/O operations to 'process.stdout' and 'process.stderr'.
In most situations, it is not actually necessary to call 'process.exit()' explicitly. The Node.js process will exit on its own if there is no additional work pending in the event loop. The 'process.exitCode' property can be set to tell the process which exit code to use when the process exits gracefully.
Note that, Calling 'process.exit()' will force the process to exit before some asynchronous work can be performed, so rather than calling 'process.exit()' directly, the code should set the 'process.exitCode' and allow the process to exit naturally by avoiding scheduling any additional work for the event loop.
If it is necessary to terminate the Node.js process due to an error condition, throwing an uncaught error and allowing the process to terminate accordingly is safer than calling 'process.exit()'.
Event: 'exit'
The exit event is emitted when the Node.js process is about to exit as a result of either:
The
process.exit()method being called explicitly;The Node.js event loop no longer having any additional work to perform.
There is no way to prevent the exiting of the event loop at this point, and once all 'exit' listeners have finished running the Node.js process will terminate.
The listener callback function is invoked with the exit code specified either by the 'process.exitCode' property, or the exitCode argument passed to the 'process.exit()' method.
Listener functions must only perform synchronous operations. The Node.js process will exit immediately after calling the 'exit' event listeners causing any additional work still queued in the event loop to be abandoned. In the following example, for instance, the timeout will never occur:
process.on('exit', code => {
setTimeout(() => {
console.log('This will not run');
}, 0);
console.log(`About to exit with code: ${code}`);
});
Event: 'beforeExit'
The beforeExit event is emitted when Node.js empties its event loop and has no additional work to schedule. Normally, the Node.js process will exit when there is no work scheduled, but a listener registered on the 'beforeExit' event can make asynchronous calls, and thereby cause the Node.js process to continue.
The listener callback function is invoked with the value of 'process.exitCode' passed as the only argument, let's take this code for an example:
process.on('beforeExit', code => {
console.log(`beforeExist invoked, code: ${code}`);
});
process.exitCode = 1;
The command-line message will be:
beforeExist invoked, code: 1
Note that, The 'beforeExit' event is not emitted for conditions causing explicit termination, such as calling 'process.exit()' or uncaught exceptions, the following two event handlers will not get a chance to run:
process.on('beforeExit', code => {
console.log(`beforeExist invoked, code: ${code}`);
});
process.exit();
process.on('beforeExit', code => {
console.log(`beforeExist invoked, code: ${code}`);
});
callNonExistentFunc();
'beforeExit' will be prior to 'exit' event, the following code shows the invocation order:
process.on('beforeExit', code => {
console.log(`beforeExist invoked, code: ${code}`);
});
process.on('exit', (code) => {
setTimeout(() => {
console.log('This will not run');
}, 0);
console.log(`About to exit with code: ${code}`);
});
// beforeExist invoked, code: 0
// About to exit with code: 0
Event: 'uncaughtException'
In above code, calling an nonexistent function will cause an exception, by default, Node.js will print the stack trace to stderr and exit the current process. Adding a 'uncaughtException' handler will override this default behavior. The 'uncaughtException' event will be emitted when an uncaught JavaScript exception bubbles all the way back to the event loop. And the handler function is called with the 'Error' object passed as the only argument.
process.on('uncaughtException', err => {
console.log(`Caught exception: ${err}`);
process.exitCode = 1;
});
process.on('beforeExit', code => {
console.log(`beforeExist invoked, code: ${code}`);
});
setTimeout(() => {
console.log('This will still run.');
}, 500);
callNonexistentFunc();
console.log('This will not run.');
Run this code, we will get the messages below:
Caught exception: ReferenceError: callNonexistentFunc is not defined
This will still run.
beforeExist invoked, code: 1
Note that 'uncaughtException' is a crude mechanism for exception handling intended to be used only as a last resort. The event should not be used as an equivalent to 'On Error Resume Next'. Unhandled exceptions inherently mean that an application is in an undefined state. Attempting to resume application code without properly recovering from the exception can cause additional unforeseen and unpredictable issues.
Exceptions thrown from within the event handler will not be caught. Instead the process will exit with a non-zero exit code and the stack trace will be printed. This is to avoid infinite recursion.
Attempting to resume normally after an uncaught exception can be similar to pulling out of the power cord when upgrading a computer — nine out of ten times nothing happens - but the 10th time, the system becomes corrupted.
The correct use of 'uncaughtException' is to perform synchronous cleanup of allocated resources (e.g. file descriptors, handles, etc) before shutting down the process. It is not safe to resume normal operation after 'uncaughtException'.
To restart a crashed application in a more reliable way, whether 'uncaughtException' is emitted or not, an external monitor should be employed in a separate process to detect application failures and recover or restart as needed.