以上描述比較硬,看完可能也沒看懂,還不利于理解記憶。那么我們舉個(gè)簡(jiǎn)單的例子:
假設(shè)你是某個(gè)快遞站點(diǎn)的一名小哥,起初這個(gè)站點(diǎn)負(fù)責(zé)的區(qū)域住戶不多,收取件都是你一個(gè)人。給張三家送完件,再去李四家取件,事情得一件件做,這叫單線程,所有的工作都得按順序執(zhí)行。后來這個(gè)區(qū)域住戶多了,站點(diǎn)給這個(gè)區(qū)域分配了多個(gè)小哥,還有個(gè)小組長(zhǎng),你們可以為更多的住戶服務(wù)了,這叫多線程,小組長(zhǎng)是主線程,每個(gè)小哥都是一個(gè)線程。快遞站點(diǎn)使用的小推車等工具,是站點(diǎn)提供的,小哥們都可以使用,并不僅供某一個(gè)人,這叫多線程資源共享。站點(diǎn)小推車目前只有一個(gè),大家都需要使用,這叫沖突。解決的方法有很多,排隊(duì)等待或者等其他小哥用完后的通知,這叫線程同步。
(相關(guān)資料圖)
總公司有很多站點(diǎn),各個(gè)站點(diǎn)的運(yùn)營模式幾乎一模一樣,這叫多進(jìn)程。總公司叫主進(jìn)程,各個(gè)站點(diǎn)叫子進(jìn)程。總公司和站點(diǎn)之間,以及各個(gè)站點(diǎn)互相之間,小推車都是相互獨(dú)立的,不能混用,這叫進(jìn)程間不共享資源。各站點(diǎn)間可以通過電話等方式聯(lián)系,這叫管道。各站點(diǎn)間還有其他協(xié)同手段,便于完成更大的計(jì)算任務(wù),這叫進(jìn)程間同步。
還可以看看阮一峰的 進(jìn)程與線程的一個(gè)簡(jiǎn)單解釋。
Node.js 是單線程服務(wù),事件驅(qū)動(dòng)和非阻塞 I/O 模型的語言特性,使得 Node.js 高效和輕量。優(yōu)勢(shì)在于免去了頻繁切換線程和資源沖突;擅長(zhǎng) I/O 密集型操作(底層模塊 libuv 通過多線程調(diào)用操作系統(tǒng)提供的異步 I/O 能力進(jìn)行多任務(wù)的執(zhí)行),但是對(duì)于服務(wù)端的 Node.js,可能每秒有上百個(gè)請(qǐng)求需要處理,當(dāng)面對(duì) CPU 密集型請(qǐng)求時(shí),因?yàn)槭菃尉€程模式,難免會(huì)造成阻塞。
我們利用 Koa 簡(jiǎn)單地搭建一個(gè) Web 服務(wù),用斐波那契數(shù)列方法來模擬一下 Node.js 處理 CPU 密集型的計(jì)算任務(wù):
// app.jsconst Koa = require("koa")const router = require("koa-router")()const app = new Koa()// 用來測(cè)試是否被阻塞router.get("/test", (ctx) => { ctx.body = { pid: process.pid, msg: "Hello World" }})router.get("/fibo", (ctx) => { const { num = 38 } = ctx.query const start = Date.now() // 斐波那契數(shù)列 const fibo = (n) => { return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1 } fibo(num) ctx.body = { pid: process.pid, duration: Date.now() - start }})app.use(router.routes())app.listen(9000, () => { console.log("Server is running on 9000")})
執(zhí)行 node app.js
啟動(dòng)服務(wù),用 Postman 發(fā)送請(qǐng)求,可以看到,計(jì)算 38 次耗費(fèi)了 617ms,換而言之,因?yàn)閳?zhí)行了一個(gè) CPU 密集型的計(jì)算任務(wù),所以 Node.js 主線程被阻塞了六百多毫秒。如果同時(shí)處理更多的請(qǐng)求,或者計(jì)算任務(wù)更復(fù)雜,那么在這些請(qǐng)求之后的所有請(qǐng)求都會(huì)被延遲執(zhí)行。
我們?cè)傩陆ㄒ粋€(gè) axios.js 用來模擬發(fā)送多次請(qǐng)求,此時(shí)將 app.js 中的 fibo 計(jì)算次數(shù)改為 43,用來模擬更復(fù)雜的計(jì)算任務(wù):
// axios.jsconst axios = require("axios")const start = Date.now()const fn = (url) => { axios.get(`http://127.0.0.1:9000/${ url }`).then((res) => { console.log(res.data, `耗時(shí): ${ Date.now() - start }ms`) })}fn("test")fn("fibo?num=43")fn("test")
可以看到,當(dāng)請(qǐng)求需要執(zhí)行 CPU 密集型的計(jì)算任務(wù)時(shí),后續(xù)的請(qǐng)求都被阻塞等待,這類請(qǐng)求一多,服務(wù)基本就阻塞卡死了。對(duì)于這種不足,Node.js 一直在彌補(bǔ)。
master-worker 模式是一種并行模式,核心思想是:系統(tǒng)有兩個(gè)及以上的進(jìn)程或線程協(xié)同工作時(shí),master 負(fù)責(zé)接收和分配并整合任務(wù),worker 負(fù)責(zé)處理任務(wù)。
線程是 CPU 調(diào)度的一個(gè)基本單位,只能同時(shí)執(zhí)行一個(gè)線程的任務(wù),同一個(gè)線程也只能被一個(gè) CPU 調(diào)用。如果使用的是多核 CPU,那么將無法充分利用 CPU 的性能。
多線程帶給我們靈活的編程方式,但是需要學(xué)習(xí)更多的 Api 知識(shí),在編寫更多代碼的同時(shí)也存在著更多的風(fēng)險(xiǎn),線程的切換和鎖也會(huì)增加系統(tǒng)資源的開銷。
worker_threads 工作線程,給 Node.js 提供了真正的多線程能力。worker_threads 是 Node.js 提供的一種多線程 Api。對(duì)于執(zhí)行 CPU 密集型的計(jì)算任務(wù)很有用,對(duì) I/O 密集型的操作幫助不大,因?yàn)?Node.js 內(nèi)置的異步 I/O 操作比 worker_threads 更高效。worker_threads 中的 Worker,parentPort 主要用于子線程和主線程的消息交互。
將 app.js 稍微改動(dòng)下,將 CPU 密集型的計(jì)算任務(wù)交給子線程計(jì)算:
// app.jsconst Koa = require("koa")const router = require("koa-router")()const { Worker } = require("worker_threads")const app = new Koa()// 用來測(cè)試是否被阻塞router.get("/test", (ctx) => { ctx.body = { pid: process.pid, msg: "Hello World" }})router.get("/fibo", async (ctx) => { const { num = 38 } = ctx.query ctx.body = await asyncFibo(num)})const asyncFibo = (num) => { return new Promise((resolve, reject) => { // 創(chuàng)建 worker 線程并傳遞數(shù)據(jù) const worker = new Worker("./fibo.js", { workerData: { num } }) // 主線程監(jiān)聽子線程發(fā)送的消息 worker.on("message", resolve) worker.on("error", reject) worker.on("exit", (code) => { if (code !== 0) reject(new Error(`Worker stopped with exit code ${code}`)) }) })}app.use(router.routes())app.listen(9000, () => { console.log("Server is running on 9000")})
新增 fibo.js 文件,用來處理復(fù)雜計(jì)算任務(wù):
const { workerData, parentPort } = require("worker_threads")const { num } = workerDataconst start = Date.now()// 斐波那契數(shù)列const fibo = (n) => { return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1}fibo(num)parentPort.postMessage({ pid: process.pid, duration: Date.now() - start})
執(zhí)行上文的 axios.js,此時(shí)將 app.js 中的 fibo 計(jì)算次數(shù)改為 43,用來模擬更復(fù)雜的計(jì)算任務(wù):
可以看到,將 CPU 密集型的計(jì)算任務(wù)交給子線程處理時(shí),主線程不再被阻塞,只需等待子線程處理完成后,主線程接收子線程返回的結(jié)果即可,其他請(qǐng)求不再受影響。上述代碼是演示創(chuàng)建 worker 線程的過程和效果,實(shí)際開發(fā)中,請(qǐng)使用線程池來代替上述操作,因?yàn)轭l繁創(chuàng)建線程也會(huì)有資源的開銷。
線程是 CPU 調(diào)度的一個(gè)基本單位,只能同時(shí)執(zhí)行一個(gè)線程的任務(wù),同一個(gè)線程也只能被一個(gè) CPU 調(diào)用。
我們?cè)倩匚断拢拘」?jié)開頭提到的線程和 CPU 的描述,此時(shí)由于是新的線程,可以在其他 CPU 核心上執(zhí)行,可以更充分的利用多核 CPU。
Node.js 為了能充分利用 CPU 的多核能力,提供了 cluster 模塊,cluster 可以通過一個(gè)父進(jìn)程管理多個(gè)子進(jìn)程的方式來實(shí)現(xiàn)集群的功能。
child_process 子進(jìn)程,衍生新的 Node.js 進(jìn)程并使用建立的 IPC 通信通道調(diào)用指定的模塊。cluster 集群,可以創(chuàng)建共享服務(wù)器端口的子進(jìn)程,工作進(jìn)程使用 child_process 的 fork 方法衍生。cluster 底層就是 child_process,master 進(jìn)程做總控,啟動(dòng) 1 個(gè) agent 進(jìn)程和 n 個(gè) worker 進(jìn)程,agent 進(jìn)程處理一些公共事務(wù),比如日志等;worker 進(jìn)程使用建立的 IPC(Inter-Process Communication)通信通道和 master 進(jìn)程通信,和 master 進(jìn)程共享服務(wù)端口。
新增 fibo-10.js,模擬發(fā)送 10 次請(qǐng)求:
// fibo-10.jsconst axios = require("axios")const url = `http://127.0.0.1:9000/fibo?num=38`const start = Date.now()for (let i = 0; i < 10; i++) { axios.get(url).then((res) => { console.log(res.data, `耗時(shí): ${ Date.now() - start }ms`) })}
可以看到,只使用了一個(gè)進(jìn)程,10 個(gè)請(qǐng)求慢慢阻塞,累計(jì)耗時(shí) 15 秒:
接下來,將 app.js 稍微改動(dòng)下,引入 cluster 模塊:
// app.jsconst cluster = require("cluster")const http = require("http")const numCPUs = require("os").cpus().length// const numCPUs = 10 // worker 進(jìn)程的數(shù)量一般和 CPU 核心數(shù)相同const Koa = require("koa")const router = require("koa-router")()const app = new Koa()// 用來測(cè)試是否被阻塞router.get("/test", (ctx) => { ctx.body = { pid: process.pid, msg: "Hello World" }})router.get("/fibo", (ctx) => { const { num = 38 } = ctx.query const start = Date.now() // 斐波那契數(shù)列 const fibo = (n) => { return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1 } fibo(num) ctx.body = { pid: process.pid, duration: Date.now() - start }})app.use(router.routes())if (cluster.isMaster) { console.log(`Master ${process.pid} is running`) // 衍生 worker 進(jìn)程 for (let i = 0; i < numCPUs; i++) { cluster.fork() } cluster.on("exit", (worker, code, signal) => { console.log(`worker ${worker.process.pid} died`) })} else { app.listen(9000) console.log(`Worker ${process.pid} started`)}
執(zhí)行 node app.js
啟動(dòng)服務(wù),可以看到,cluster 幫我們創(chuàng)建了 1 個(gè) master 進(jìn)程和 4 個(gè) worker 進(jìn)程:
通過 fibo-10.js 模擬發(fā)送 10 次請(qǐng)求,可以看到,四個(gè)進(jìn)程處理 10 個(gè)請(qǐng)求耗時(shí)近 9 秒:
當(dāng)啟動(dòng) 10 個(gè) worker 進(jìn)程時(shí),看看效果:
僅需不到 3 秒,不過進(jìn)程的數(shù)量也不是無限的。在日常開發(fā)中,worker 進(jìn)程的數(shù)量一般和 CPU 核心數(shù)相同。
開啟多進(jìn)程不全是為了處理高并發(fā),而是為了解決 Node.js 對(duì)于多核 CPU 利用率不足的問題。由父進(jìn)程通過 fork 方法衍生出來的子進(jìn)程擁有和父進(jìn)程一樣的資源,但是各自獨(dú)立,互相之間資源不共享。通常根據(jù) CPU 核心數(shù)來設(shè)置進(jìn)程數(shù)量,因?yàn)橄到y(tǒng)資源是有限的。
1、大部分通過多線程解決 CPU 密集型計(jì)算任務(wù)的方案都可以通過多進(jìn)程方案來替代;2、Node.js 雖然異步,但是不代表不會(huì)阻塞,CPU 密集型任務(wù)最好不要在主線程處理,保證主線程的暢通;3、不要一味的追求高性能和高并發(fā),達(dá)到系統(tǒng)需要即可,高效、敏捷才是項(xiàng)目需要的,這也是 Node.js 輕量的特點(diǎn)。4、Node.js 中的進(jìn)程和線程還有很多概念在文章中提到了但沒展開細(xì)講或沒提到的,比如:Node.js 底層 I/O 的 libuv、IPC 通信通道、多進(jìn)程如何守護(hù)、進(jìn)程間資源不共享如何處理定時(shí)任務(wù)、agent 進(jìn)程等;5、以上代碼可在 https://github.com/liuxy0551/node-process-thread 查看。
更多node相關(guān)知識(shí),請(qǐng)?jiān)L問:nodejs 教程!
以上就是深入淺析Node中的進(jìn)程和線程的詳細(xì)內(nèi)容,更多請(qǐng)關(guān)注php中文網(wǎng)其它相關(guān)文章!
關(guān)鍵詞: nodejs?