深入理解Node.js 進程與執行緒(8000長文徹底搞懂)
- 2019 年 10 月 10 日
- 筆記

前言
進程
與 執行緒
是一個程式設計師的必知概念,面試經常被問及,但是一些文章內容只是講講理論知識,可能一些小夥伴並沒有真的理解,在實際開發中應用也比較少。本篇文章除了介紹概念,通過Node.js 的角度講解 進程
與 執行緒
,並且講解一些在項目中的實戰的應用,讓你不僅能迎戰面試官還可以在實戰中完美應用。
文章導覽

面試會問
Node.js是單執行緒嗎? Node.js 做耗時的計算時候,如何避免阻塞? Node.js如何實現多進程的開啟和關閉? Node.js可以創建執行緒嗎? 你們開發過程中如何實現進程守護的? 除了使用第三方模組,你們自己是否封裝過一個多進程架構?
進程
進程 Process
是電腦中的程式關於某數據集合上的一次運行活動,是系統進行資源分配和調度的基本單位,是作業系統結構的基礎,進程是執行緒的容器(來自百科)。進程是資源分配的最小單位。我們啟動一個服務、運行一個實例,就是開一個服務進程,例如 Java 里的 JVM 本身就是一個進程,Node.js 里通過 node app.js
開啟一個服務進程,多進程就是進程的複製(fork),fork 出來的每個進程都擁有自己的獨立空間地址、數據棧,一個進程無法訪問另外一個進程里定義的變數、數據結構,只有建立了 IPC 通訊,進程之間才可數據共享。
- Node.js開啟服務進程例子
const http = require('http'); const server = http.createServer(); server.listen(3000,()=>{ process.title='程式設計師成長指北測試進程'; console.log('進程id',process.pid) })
運行上面程式碼後,以下為 Mac 系統自帶的監控工具 「活動監視器」 所展示的效果,可以看到我們剛開啟的 Nodejs 進程 7663

執行緒
執行緒是作業系統能夠進行運算調度的最小單位,首先我們要清楚執行緒是隸屬於進程的,被包含於進程之中。一個執行緒只能隸屬於一個進程,但是一個進程是可以擁有多個執行緒的。
單執行緒
單執行緒就是一個進程只開一個執行緒
Javascript 就是屬於單執行緒,程式順序執行(這裡暫且不提JS非同步),可以想像一下隊列,前面一個執行完之後,後面才可以執行,當你在使用單執行緒語言編碼時切勿有過多耗時的同步操作,否則執行緒會造成阻塞,導致後續響應無法處理。你如果採用 Javascript 進行編碼時候,請儘可能的利用Javascript非同步操作的特性。
經典計算耗時造成執行緒阻塞的例子
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') { console.info('計算開始',new Date()); const sum = longComputation(); console.info('計算結束',new Date()); return res.end(`Sum is ${sum}`); } else { res.end('Ok') } }); server.listen(3000); //列印結果 //計算開始 2019-07-28T07:08:49.849Z //計算結束 2019-07-28T07:09:04.522Z
查看列印結果,當我們調用 127.0.0.1:3000/compute
的時候,如果想要調用其他的路由地址比如127.0.0.1/大約需要15秒時間,也可以說一個用戶請求完第一個 compute
介面後需要等待15秒,這對於用戶來說是極其不友好的。下文我會通過創建多進程的方式 child_process.fork
和 cluster
來解決解決這個問題。
單執行緒的一些說明
- Node.js 雖然是單執行緒模型,但是其基於事件驅動、非同步非阻塞模式,可以應用於高並發場景,避免了執行緒創建、執行緒之間上下文切換所產生的資源開銷。
- 當你的項目中需要有大量計算,CPU 耗時的操作時候,要注意考慮開啟多進程來完成了。
- Node.js 開發過程中,錯誤會引起整個應用退出,應用的健壯性值得考驗,尤其是錯誤的異常拋出,以及進程守護是必須要做的。
- 單執行緒無法利用多核CPU,但是後來Node.js 提供的API以及一些第三方工具相應都得到了解決,文章後面都會講到。
Node.js 中的進程與執行緒
Node.js 是 Javascript 在服務端的運行環境,構建在 chrome 的 V8 引擎之上,基於事件驅動、非阻塞I/O模型,充分利用作業系統提供的非同步 I/O 進行多任務的執行,適合於 I/O 密集型的應用場景,因為非同步,程式無需阻塞等待結果返回,而是基於回調通知的機制,原本同步模式等待的時間,則可以用來處理其它任務,
科普:在 Web 伺服器方面,著名的 Nginx 也是採用此模式(事件驅動),避免了多執行緒的執行緒創建、執行緒上下文切換的開銷,Nginx 採用 C 語言進行編寫,主要用來做高性能的 Web 伺服器,不適合做業務。
Web業務開發中,如果你有高並發應用場景那麼 Node.js 會是你不錯的選擇。
在單核 CPU 系統之上我們採用 單進程 + 單執行緒 的模式來開發。在多核 CPU 系統之上,可以通過 child_process.fork
開啟多個進程(Node.js 在 v0.8 版本之後新增了Cluster 來實現多進程架構) ,即 多進程 + 單執行緒 模式。注意:開啟多進程不是為了解決高並發,主要是解決了單進程模式下 Node.js CPU 利用率不足的情況,充分利用多核 CPU 的性能。
Node.js 中的進程
process 模組
Node.js 中的進程 Process 是一個全局對象,無需 require 直接使用,給我們提供了當前進程中的相關資訊。官方文檔提供了詳細的說明,感興趣的可以親自實踐下 Process 文檔。
process.env
:環境變數,例如通過process.env.NODE_ENV
獲取不同環境項目配置資訊process.nextTick
:這個在談及EventLoop
時經常為會提到process.pid
:獲取當前進程idprocess.ppid
:當前進程對應的父進程process.cwd()
:獲取當前進程工作目錄,process.platform
:獲取當前進程運行的作業系統平台process.uptime()
:當前進程已運行時間,例如:pm2 守護進程的 uptime 值- 進程事件:
process.on(『uncaughtException』,cb)
捕獲異常資訊、process.on(『exit』,cb)
進程推出監聽 - 三個標準流:
process.stdout
標準輸出、process.stdin
標準輸入、process.stderr
標準錯誤輸出 process.title
指定進程名稱,有的時候需要給進程指定一個名稱
以上僅列舉了部分常用到功能點,除了 Process 之外 Node.js 還提供了 child_process 模組用來對子進程進行操作,在下文 Nodejs進程創建會繼續講述。
Node.js 進程創建
進程創建有多種方式,本篇文章以child_process模組和cluster模組進行講解。
child_process模組
child_process 是 Node.js 的內置模組,官網地址:
childprocess 官網地址:http://nodejs.cn/api/childprocess.html#childprocesschild_process
幾個常用函數:四種方式
child_process.spawn()
:適用於返回大量數據,例如影像處理,二進位數據處理。child_process.exec()
:適用於小量數據,maxBuffer 默認值為 200 * 1024 超出這個默認值將會導致程式崩潰,數據量過大可採用 spawn。child_process.execFile()
:類似child_process.exec()
,區別是不能通過 shell 來執行,不支援像 I/O 重定向和文件查找這樣的行為child_process.fork()
:衍生新的進程,進程之間是相互獨立的,每個進程都有自己的 V8 實例、記憶體,系統資源是有限的,不建議衍生太多的子進程出來,通長根據系統* CPU 核心數*設置。
CPU 核心數這裡特別說明下,fork 確實可以開啟多個進程,但是並不建議衍生出來太多的進程,cpu核心數的獲取方式
constcpus=require('os').cpus();
,這裡 cpus 返回一個對象數組,包含所安裝的每個 CPU/內核的資訊,二者總和的數組哦。假設主機裝有兩個cpu,每個cpu有4個核,那麼總核數就是8。
fork開啟子進程 Demo
fork開啟子進程解決文章起初的計算耗時造成執行緒阻塞。在進行 compute 計算時創建子進程,子進程計算完成通過 send
方法將結果發送給主進程,主進程通過 message
監聽到資訊後處理並退出。
fork_app.js
const http = require('http'); const fork = require('child_process').fork; const server = http.createServer((req, res) => { if(req.url == '/compute'){ const compute = fork('./fork_compute.js'); compute.send('開啟一個新的子進程'); // 當一個子進程使用 process.send() 發送消息時會觸發 'message' 事件 compute.on('message', sum => { res.end(`Sum is ${sum}`); compute.kill(); }); // 子進程監聽到一些錯誤消息退出 compute.on('close', (code, signal) => { console.log(`收到close事件,子進程收到訊號 ${signal} 而終止,退出碼 ${code}`); compute.kill(); }) }else{ res.end(`ok`); } }); server.listen(3000, 127.0.0.1, () => { console.log(`server started at http://${127.0.0.1}:${3000}`); });
fork_compute.js
針對文初需要進行計算的的例子我們創建子進程拆分出來單獨進行運算。
const computation = () => { let sum = 0; console.info('計算開始'); console.time('計算耗時'); for (let i = 0; i < 1e10; i++) { sum += i }; console.info('計算結束'); console.timeEnd('計算耗時'); return sum; }; process.on('message', msg => { console.log(msg, 'process.pid', process.pid); // 子進程id const sum = computation(); // 如果Node.js進程是通過進程間通訊產生的,那麼,process.send()方法可以用來給父進程發送消息 process.send(sum); })
cluster模組
cluster 開啟子進程Demo
const http = require('http'); const numCPUs = require('os').cpus().length; const cluster = require('cluster'); if(cluster.isMaster){ console.log('Master proces id is',process.pid); // fork workers for(let i= 0;i<numCPUs;i++){ cluster.fork(); } cluster.on('exit',function(worker,code,signal){ console.log('worker process died,id',worker.process.pid) }) }else{ // Worker可以共享同一個TCP連接 // 這裡是一個http伺服器 http.createServer(function(req,res){ res.writeHead(200); res.end('hello word'); }).listen(8000); }
cluster原理分析

cluster模組調用fork方法來創建子進程,該方法與child_process中的fork是同一個方法。cluster模組採用的是經典的主從模型,Cluster會創建一個master,然後根據你指定的數量複製出多個子進程,可以使用 cluster.isMaster
屬性判斷當前進程是master還是worker(工作進程)。由master進程來管理所有的子進程,主進程不負責具體的任務處理,主要工作是負責調度和管理。
cluster模組使用內置的負載均衡來更好地處理執行緒之間的壓力,該負載均衡使用了 Round-robin
演算法(也被稱之為循環演算法)。當使用Round-robin調度策略時,master accepts()所有傳入的連接請求,然後將相應的TCP請求處理髮送給選中的工作進程(該方式仍然通過IPC來進行通訊)。
開啟多進程時候埠疑問講解:如果多個Node進程監聽同一個埠時會出現 Error:listen EADDRIUNS
的錯誤,而cluster模組為什麼可以讓多個子進程監聽同一個埠呢?原因是master進程內部啟動了一個TCP伺服器,而真正監聽埠的只有這個伺服器,當來自前端的請求觸發伺服器的connection事件後,master會將對應的socket具柄發送給子進程。
child_process 模組與cluster 模組總結
無論是 child_process 模組還是 cluster 模組,為了解決 Node.js 實例單執行緒運行,無法利用多核 CPU 的問題而出現的。核心就是父進程(即 master 進程)負責監聽埠,接收到新的請求後將其分發給下面的 worker 進程。
cluster模組的一個弊端:


cluster內部隱時的構建TCP伺服器的方式來說對使用者確實簡單和透明了很多,但是這種方式無法像使用childprocess那樣靈活,因為一直主進程只能管理一組相同的工作進程,而自行通過childprocess來創建工作進程,一個主進程可以控制多組進程。原因是child_process操作子進程時,可以隱式的創建多個TCP伺服器,對比上面的兩幅圖應該能理解我說的內容。
Node.js進程通訊原理
前面講解的無論是child_process模組,還是cluster模組,都需要主進程和工作進程之間的通訊。通過fork()或者其他API,創建了子進程之後,為了實現父子進程之間的通訊,父子進程之間才能通過message和send()傳遞資訊。
IPC這個詞我想大家並不陌生,不管那一張開發語言只要提到進程通訊,都會提到它。IPC的全稱是Inter-Process Communication,即進程間通訊。它的目的是為了讓不同的進程能夠互相訪問資源並進行協調工作。實現進程間通訊的技術有很多,如命名管道,匿名管道,socket,訊號量,共享記憶體,消息隊列等。Node中實現IPC通道是依賴於libuv。windows下由命名管道(name pipe)實現,*nix系統則採用Unix Domain Socket實現。表現在應用層上的進程間通訊只有簡單的message事件和send()方法,介面十分簡潔和消息化。
IPC創建和實現示意圖

IPC通訊管道是如何創建的

父進程在實際創建子進程之前,會創建 IPC通道
並監聽它,然後才 真正的
創建出 子進程
,這個過程中也會通過環境變數(NODECHANNELFD)告訴子進程這個IPC通道的文件描述符。子進程在啟動的過程中,根據文件描述符去連接這個已存在的IPC通道,從而完成父子進程之間的連接。
Node.js句柄傳遞
講句柄之前,先想一個問題,send句柄發送的時候,真的是將伺服器對象發送給了子進程?
子進程對象send()方法可以發送的句柄類型
- net.Socket TCP套接字
- net.Server TCP伺服器,任意建立在TCP服務上的應用層服務都可以享受它帶來的好處
- net.Native C++層面的TCP套接字或IPC管道
- dgram.Socket UDP套接字
- dgram.Native C++層面的UDP套接字
send句柄發送原理分析
結合句柄的發送與還原示意圖更容易理解。

send()
方法在將消息發送到IPC管道前,實際將消息組裝成了兩個對象,一個參數是hadler,另一個是message。message參數如下所示:
{ cmd:'NODE_HANDLE', type:'net.Server', msg:message }
發送到IPC管道中的實際上是我們要發送的句柄文件描述符。這個message對象在寫入到IPC管道時,也會通過 JSON.stringfy()
進行序列化。所以最終發送到IPC通道中的資訊都是字元串,send()方法能發送消息和句柄並不意味著它能發送任何對象。
連接了IPC通道的子執行緒可以讀取父進程發來的消息,將字元串通過JSON.parse()解析還原為對象後,才觸發message事件將消息傳遞給應用層使用。在這個過程中,消息對象還要被進行過濾處理,message.cmd的值如果以NODE為前綴,它將響應一個內部事件internalMessage,如果message.cmd值為NODEHANDLE,它將取出 message.type
值和得到的文件描述符一起還原出一個對應的對象。
以發送的TCP伺服器句柄為例,子進程收到消息後的還原過程程式碼如下:
function(message,handle,emit){ var self = this; var server = new net.Server(); server.listen(handler,function(){ emit(server); }); }
這段還原程式碼, 子進程根據message.type創建對應的TCP伺服器對象,然後監聽到文件描述符上
。由於底層細節不被應用層感知,所以子進程中,開發者會有一種伺服器對象就是從父進程中直接傳遞過來的錯覺。
Node進程之間只有消息傳遞,不會真正的傳遞對象,這種錯覺是抽象封裝的結果。目前Node只支援我前面提到的幾種句柄,並非任意類型的句柄都能在進程之間傳遞,除非它有完整的發送和還原的過程。
Node.js多進程架構模型
我們自己實現一個多進程架構守護Demo

編寫主進程
master.js 主要處理以下邏輯:
- 創建一個 server 並監聽 3000 埠。
- 根據系統 cpus 開啟多個子進程
- 通過子進程對象的 send 方法發送消息到子進程進行通訊
- 在主進程中監聽了子進程的變化,如果是自殺訊號重新啟動一個工作進程。
- 主進程在監聽到退出消息的時候,先退出子進程在退出主進程
// master.js const fork = require('child_process').fork; const cpus = require('os').cpus(); const server = require('net').createServer(); server.listen(3000); process.title = 'node-master' const workers = {}; const createWorker = () => { const worker = fork('worker.js') worker.on('message', function (message) { if (message.act === 'suicide') { createWorker(); } }) worker.on('exit', function(code, signal) { console.log('worker process exited, code: %s signal: %s', code, signal); delete workers[worker.pid]; }); worker.send('server', server); workers[worker.pid] = worker; console.log('worker process created, pid: %s ppid: %s', worker.pid, process.pid); } for (let i=0; i<cpus.length; i++) { createWorker(); } process.once('SIGINT', close.bind(this, 'SIGINT')); // kill(2) Ctrl-C process.once('SIGQUIT', close.bind(this, 'SIGQUIT')); // kill(3) Ctrl- process.once('SIGTERM', close.bind(this, 'SIGTERM')); // kill(15) default process.once('exit', close.bind(this)); function close (code) { console.log('進程退出!', code); if (code !== 0) { for (let pid in workers) { console.log('master process exited, kill worker pid: ', pid); workers[pid].kill('SIGINT'); } } process.exit(0); }
工作進程
worker.js 子進程處理邏輯如下:
- 創建一個 server 對象,注意這裡最開始並沒有監聽 3000 埠
- 通過 message 事件接收主進程 send 方法發送的消息
- 監聽 uncaughtException 事件,捕獲未處理的異常,發送自殺資訊由主進程重建進程,子進程在鏈接關閉之後退出
// worker.js const http = require('http'); const server = http.createServer((req, res) => { res.writeHead(200, { 'Content-Type': 'text/plan' }); res.end('I am worker, pid: ' + process.pid + ', ppid: ' + process.ppid); throw new Error('worker process exception!'); // 測試異常進程退出、重啟 }); let worker; process.title = 'node-worker' process.on('message', function (message, sendHandle) { if (message === 'server') { worker = sendHandle; worker.on('connection', function(socket) { server.emit('connection', socket); }); } }); process.on('uncaughtException', function (err) { console.log(err); process.send({act: 'suicide'}); worker.close(function () { process.exit(1); }) })
Node.js 進程守護
什麼是進程守護?
每次啟動 Node.js 程式都需要在命令窗口輸入命令 node app.js
才能啟動,但如果把命令窗口關閉則Node.js 程式服務就會立刻斷掉。除此之外,當我們這個 Node.js 服務意外崩潰了就不能自動重啟進程了。這些現象都不是我們想要看到的,所以需要通過某些方式來守護這個開啟的進程,執行 node app.js 開啟一個服務進程之後,我還可以在這個終端上做些別的事情,且不會相互影響。,當出現問題可以自動重啟。
如何實現進程守護
這裡我只說一些第三方的進程守護框架,pm2 和 forever ,它們都可以實現進程守護,底層也都是通過上面講的 child_process 模組和 cluster 模組 實現的,這裡就不再提它們的原理。
pm2 指定生產環境啟動一個名為 test 的 node 服務
pm2 start app.js --env production --name test
pm2常用api
-
pm2 stopName/processID
停止某個服務,通過服務名稱或者服務進程ID -
pm2deleteName/processID
刪除某個服務,通過服務名稱或者服務進程ID -
pm2 logs[Name]
查看日誌,如果添加服務名稱,則指定查看某個服務的日誌,不加則查看所有日誌 -
pm2 start app.js-i4
集群,-i參數用來告訴PM2以clustermode的形式運行你的app(對應的叫forkmode),後面的數字表示要啟動的工作執行緒的數量。如果給定的數字為0,PM2則會根據你CPU核心的數量來生成對應的工作執行緒。注意一般在生產環境使用cluster_mode模式,測試或者本地環境一般使用fork模式,方便測試到錯誤。 -
pm2 reloadNamepm2 restartName
應用程式程式碼有更新,可以用重載來載入新程式碼,也可以用重啟來完成,reload可以做到0秒宕機載入新的程式碼,restart則是重新啟動,生產環境中多用reload來完成程式碼更新! -
pm2 showName
查看服務詳情 -
pm2 list
查看pm2中所有項目 -
pm2 monit
用monit可以打開實時監視器去查看資源佔用情況
pm2 官網地址:
http://pm2.keymetrics.io/docs/usage/quick-start/
forever 就不特殊說明了,官網地址
https://github.com/foreverjs/forever 注意:二者更推薦pm2,看一下二者對比就知道我為什麼更推薦使用pm2了。https://www.jianshu.com/p/fdc12d82b661
linux 關閉一個進程
- 查找與進程相關的PID號 ps aux | grep server 說明:
root 20158 0.0 5.0 1251592 95396 ? Sl 5月17 1:19 node /srv/mini-program-api/launch_pm2.js
上面是執行命令後在linux中顯示的結果,第二個參數就是進程對應的PID
- 殺死進程
- 以優雅的方式結束進程 kill -l PID -l選項告訴kill命令用好像啟動進程的用戶已註銷的方式結束進程。當使用該選項時,kill命令也試圖殺死所留下的子進程。但這個命令也不是總能成功–或許仍然需要先手工殺死子進程,然後再殺死父進程。
- kill 命令用於終止進程 例如:
kill-9[PID]
-9 表示強迫進程立即停止 這個強大和危險的命令迫使進程在運行時突然終止,進程在結束後不能自我清理。危害是導致系統資源無法正常釋放,一般不推薦使用,除非其他辦法都無效。當使用此命令時,一定要通過ps -ef確認沒有剩下任何殭屍進程。只能通過終止父進程來消除殭屍進程。如果殭屍進程被init收養,問題就比較嚴重了。殺死init進程意味著關閉系統。如果系統中有殭屍進程,並且其父進程是init, 而且殭屍進程佔用了大量的系統資源,那麼就需要在某個時候重啟機器以清除進程表了。 - killall命令 殺死同一進程組內的所有進程。其允許指定要終止的進程的名稱,而非PID。
killall httpd
Node.js 執行緒
Node.js關於單執行緒的誤區
const http = require('http'); const server = http.createServer(); server.listen(3000,()=>{ process.title='程式設計師成長指北測試進程'; console.log('進程id',process.pid) })
仍然看本文第一段程式碼,創建了http服務,開啟了一個進程,都說了Node.js是單執行緒,所以 Node 啟動後執行緒數應該為 1,但是為什麼會開啟7個執行緒呢?難道Javascript不是單執行緒不知道小夥伴們有沒有這個疑問?
解釋一下這個原因:
Node 中最核心的是 v8 引擎,在 Node 啟動後,會創建 v8 的實例,這個實例是多執行緒的。
- 主執行緒:編譯、執行程式碼。
- 編譯/優化執行緒:在主執行緒執行的時候,可以優化程式碼。
- 分析器執行緒:記錄分析程式碼運行時間,為 Crankshaft 優化程式碼執行提供依據。
- 垃圾回收的幾個執行緒。
所以大家常說的 Node 是單執行緒的指的是 JavaScript 的執行是單執行緒的(開發者編寫的程式碼運行在單執行緒環境中),但 Javascript 的宿主環境,無論是 Node 還是瀏覽器都是多執行緒的因為libuv中有執行緒池的概念存在的,libuv會通過類似執行緒池的實現來模擬不同作業系統的非同步調用,這對開發者來說是不可見的。
某些非同步 IO 會佔用額外的執行緒
還是上面那個例子,我們在定時器執行的同時,去讀一個文件:
const fs = require('fs') setInterval(() => { console.log(new Date().getTime()) }, 3000) fs.readFile('./index.html', () => {})
執行緒數量變成了 11 個,這是因為在 Node 中有一些 IO 操作(DNS,FS)和一些 CPU 密集計算(Zlib,Crypto)會啟用 Node 的執行緒池,而執行緒池默認大小為 4,因為執行緒數變成了 11。我們可以手動更改執行緒池默認大小:
process.env.UV_THREADPOOL_SIZE = 64
一行程式碼輕鬆把執行緒變成 71。
Libuv
Libuv 是一個跨平台的非同步IO庫,它結合了UNIX下的libev和Windows下的IOCP的特性,最早由Node的作者開發,專門為Node提供多平台下的非同步IO支援。Libuv本身是由C++語言實現的,Node中的非蘇塞IO以及事件循環的底層機制都是由libuv實現的。
libuv架構圖

在Window環境下,libuv直接使用Windows的IOCP來實現非同步IO。在非Windows環境下,libuv使用多執行緒來模擬非同步IO。
注意下面我要說的話,Node的非同步調用是由libuv來支援的,以上面的讀取文件的例子,讀文件實質的系統調用是由libuv來完成的,Node只是負責調用libuv的介面,等數據返回後再執行對應的回調方法。
Node.js 執行緒創建
直到 Node 10.5.0 的發布,官方才給出了一個實驗性質的模組 worker_threads 給 Node 提供真正的多執行緒能力。
先看下簡單的 demo:
const { isMainThread, parentPort, workerData, threadId, MessageChannel, MessagePort, Worker } = require('worker_threads'); function mainThread() { for (let i = 0; i < 5; i++) { const worker = new Worker(__filename, { workerData: i }); worker.on('exit', code => { console.log(`main: worker stopped with exit code ${code}`); }); worker.on('message', msg => { console.log(`main: receive ${msg}`); worker.postMessage(msg + 1); }); } } function workerThread() { console.log(`worker: workerDate ${workerData}`); parentPort.on('message', msg => { console.log(`worker: receive ${msg}`); }), parentPort.postMessage(workerData); } if (isMainThread) { mainThread(); } else { workerThread(); }
上述程式碼在主執行緒中開啟五個子執行緒,並且主執行緒向子執行緒發送簡單的消息。
由於 worker_thread 目前仍然處於實驗階段,所以啟動時需要增加 –experimental-worker flag,運行後觀察活動監視器,開啟了5個子執行緒

worker_thread 模組
workerthread 核心程式碼(地址https://github.com/nodejs/node/blob/master/lib/workerthreads.js) worker_thread 模組中有 4 個對象和 2 個類,可以自己去看上面的源碼。
- isMainThread: 是否是主執行緒,源碼中是通過 threadId === 0 進行判斷的。
- MessagePort: 用於執行緒之間的通訊,繼承自 EventEmitter。
- MessageChannel: 用於創建非同步、雙向通訊的通道實例。
- threadId: 執行緒 ID。
- Worker: 用於在主執行緒中創建子執行緒。第一個參數為 filename,表示子執行緒執行的入口。
- parentPort: 在 worker 執行緒里是表示父進程的 MessagePort 類型的對象,在主執行緒里為 null
- workerData: 用於在主進程中向子進程傳遞數據(data 副本)
總結
多進程 vs 多執行緒
對比一下多執行緒與多進程:
屬性 |
多進程 |
多執行緒 |
比較 |
---|---|---|---|
數據 |
數據共享複雜,需要用IPC;數據是分開的,同步簡單 |
因為共享進程數據,數據共享簡單,同步複雜 |
各有千秋 |
CPU、記憶體 |
佔用記憶體多,切換複雜,CPU利用率低 |
佔用記憶體少,切換簡單,CPU利用率高 |
多執行緒更好 |
銷毀、切換 |
創建銷毀、切換複雜,速度慢 |
創建銷毀、切換簡單,速度很快 |
多執行緒更好 |
coding |
編碼簡單、調試方便 |
編碼、調試複雜 |
編碼、調試複雜 |
可靠性 |
進程獨立運行,不會相互影響 |
執行緒同呼吸共命運 |
多進程更好 |
分散式 |
可用於多機多核分散式,易於擴展 |
只能用於多核分散式 |
多進程更好 |