問題描述

假設(shè)單核CPU下安裝一個(gè)node程序, 程序里面很簡單, 一個(gè)http服務(wù)器, 有請(qǐng)求進(jìn)來, 延遲5秒返回結(jié)果(可以理解了5s同步做一些事情)

當(dāng)有3個(gè)請(qǐng)求同時(shí)進(jìn)來時(shí), 請(qǐng)問結(jié)果會(huì)是哪個(gè)場景:場景1:第一個(gè)請(qǐng)求在5秒后拿到結(jié)果, 第二個(gè)和第三個(gè)是在10s和15s后拿到結(jié)果場景2:所有請(qǐng)求都是5秒后拿到結(jié)果

如果換成java+tomcat, 會(huì)是哪種場景, 謝謝大家!

問題解答

如果是 同步的 延遲 5秒，且 node.js 為簡單的單線程運(yùn)行，不加入 cluster 等優(yōu)化

const start = Date.now();while(Date.now() - start < 5000) { ; }return res.send();

那么，多個(gè)請(qǐng)求同時(shí)發(fā)起時(shí)，場景1

但通常在 node.js 很少真的碰到完全阻塞的同步等待 5 秒，如果是下列情況：

setTimeOut(() => { return res.send(); }, 5000);

那結(jié)果當(dāng)然是場景2

至于 Java ，并發(fā)是多線程支撐的，在機(jī)能足夠的情況下，比如并發(fā)僅僅為3，可以粗略的視為是：場景2。當(dāng)然由于涉及到線程開銷，在并發(fā)量上升之后，其內(nèi)存的占用將遠(yuǎn)超 node.js 的模型

實(shí)際上這也是為什么我們說 node.js 更加適合 IO密集 低運(yùn)算 的場景。可以參考我的另一個(gè)回答