Node.js process模塊解讀

2019年8月24日 96次阅读 来源: Randal

process存在於全局對象上，不須要運用require()加載即可運用，process模塊主要做兩方面的事變

  • 讀：獵取歷程信息（資本運用、運轉環境、運轉狀況）
  • 寫：實行歷程操縱（監聽事宜、調理使命、發出正告）

資本運用

資本運用指運轉此歷程所斲喪的机械資本。比方內存、cpu

內存

process.memoryUsage())

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

rss(常駐內存)的構成見下圖
《Node.js process模塊解讀》

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見下圖，背面會做進一步細緻的解說
《Node.js process模塊解讀》

發出正告

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
    原文作者：Randal
    原文地址: https://segmentfault.com/a/1190000015105353
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞