process存在於全局對象上,不須要運用require()加載即可運用,process模塊主要做兩方面的事變
- 讀:獵取歷程信息(資本運用、運轉環境、運轉狀況)
- 寫:實行歷程操縱(監聽事宜、調理使命、發出正告)
資本運用
資本運用指運轉此歷程所斲喪的机械資本。比方內存、cpu
內存
process.memoryUsage())
{ rss: 21848064,
heapTotal: 7159808,
heapUsed: 4431688,
external: 8224
}
rss(常駐內存)的構成見下圖
code segment對應當前運轉的代碼
external對應的是C++對象(與V8治理的JS對象綁定)的佔用的內存,比方Buffer的運用
Buffer.allocUnsafe(1024 * 1024 * 1000);
console.log(process.memoryUsage());
{ rss: 22052864,
heapTotal: 6635520,
heapUsed: 4161376,
external: 1048584224 }
cpu
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架構、用戶環境、體系平台
運轉目次
console.log(`Current directory: ${process.cwd()}`);
// Current directory: /Users/xxxx/workspace/learn/node-basic/process
node環境
console.log(process.version)
// v9.1.0
假如不單單議願望取得node的版本信息,還願望v8、zlib、libuv版本等信息的話就須要運用process.versions了
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' }
cpu架構
console.log(`This processor architecture is ${process.arch}`);
// This processor architecture is x64
支撐的值包含:'arm'
, 'arm64'
, 'ia32'
, 'mips'
, 'mipsel'
, 'ppc'
, 'ppc64'
, 's390'
, 's390x'
, 'x32'
'x64'
用戶環境
console.log(process.env.NODE_ENV); // dev
NODE_ENV=dev node b.js
除了啟動時的自定義信息以外,process.env還能夠取得其他的用戶環境信息(比方PATH、SHELL、HOME等),感興趣的能夠本身打印一下嘗嘗
體系平台
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]的值(略有差別)
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' ]
實行目次
console.log(process.execPath);
// /Users/xxxx/.nvm/versions/node/v9.1.0/bin/node
運轉時刻
var date = new Date();
while(new Date() - date < 500) {}
console.log(process.uptime()); // 0.569
主文件
除了require.main以外也能夠經由過程process.mainModule來推斷一個模塊是不是是主文件
//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信息
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都不會被實行
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事宜將會不再被觸發。
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信號時會啟動內置的調試器,當實行以下操縱時
kill -USR1 PID_OF_THE_NODE_JS_PROCESS
能夠看到node.js會啟動調試器代辦,端口是9229
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 來啟動調試代辦
node --inspect index.js
調理使命
process.nextTick(fn)
經由過程process.nextTick調理的使命是異步使命,EventLoop是分階段的,每一個階段實行特定的使命,而nextTick的使命在階段切換的時刻就會實行,因而nextTick會比setTimeout(fn, 0)更快的實行,關於EventLoop見下圖,背面會做進一步細緻的解說
發出正告
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
打印細緻客棧信息
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