JavaScript單線程的誤解

　　在我接觸JavaScript（無論瀏覽器還是NodeJS）的時間里，總是遇到有朋友有多線程的需求。而在NodeJS方面，有朋友甚至直接說到，NodeJS是單線程的，無法很好的利用多核CPU。

　　誠然，在前端的瀏覽器中，由于前端的JavaScript與UI占據(jù)同一線程，執(zhí)行JavaScript確實為UI響應(yīng)造成了一定程度上的麻煩。但是，除非用到超大的循環(huán)語句執(zhí)行JavaScript，或是用阻塞式的Ajax，或是太過頻繁的定時器執(zhí)行外，JavaScript并沒有給前端應(yīng)用帶來明顯的問題，所以也很少有朋友抱怨JavaScript是單線程而不能很好利用多核CPU的問題，因為沒有因此出現(xiàn)性能瓶頸。

　　但是，我們可以用Ajax和Web Worker回應(yīng)這個誤解。當Ajax請求發(fā)送之后，除非是同步請求，否則其余的JavaScript代碼會很快被執(zhí)行到。在Ajax發(fā)送完成，直到接收到響應(yīng)的這段時間里，這個網(wǎng)絡(luò)請求并不會阻塞JavaScript的執(zhí)行，而網(wǎng)絡(luò)請求已經(jīng)發(fā)生，這是必然的事。那么，答案就很明顯了，JavaScript確實是執(zhí)行在單線程上的，但是，整個Web應(yīng)用執(zhí)行的宿主（瀏覽器）并非以單線程的方式在執(zhí)行。而Web Worker的誕生，就是直接為了解決JavaScript與UI占用同一線程造成的UI響應(yīng)問題的，它能新開一條線程去執(zhí)行JavaScript。

　　同理，NodeJS中的JavaScript也確實是在單線程上執(zhí)行，但是作為宿主的NodeJS，它本身并非是單線程的，NodeJS在I/O方面又動用到一小部分額外的線程協(xié)助實現(xiàn)異步。程序員沒有機會直接創(chuàng)建線程，這也是有的同學想當然的認為NodeJS的單線程無法很好的利用多核CPU的原因，他們甚至會說，難以想象由多人一起協(xié)作開發(fā)一個單線程的程序。

　　NodeJS封裝了內(nèi)部的異步實現(xiàn)后，導(dǎo)致程序員無法直接操作線程，也就造成所有的業(yè)務(wù)邏輯運算都會丟到JavaScript的執(zhí)行線程上，這也就意味著，在高并發(fā)請求的時候，I/O的問題是很好的解決了，但是所有的業(yè)務(wù)邏輯運算積少成多地都運行在JavaScript線程上，形成了一條擁擠的JavaScript運算線程。NodeJS的弱點在這個時候會暴露出來，單線程執(zhí)行運算形成的瓶頸，拖慢了I/O的效率。這大概可以算得上是密集運算情況下無法很好利用多核CPU的缺點。這條擁擠的JavaScript線程，給I/O形成了性能上限。

　　但是，事情又并非絕對的?；氐角岸藶g覽器中，為了解決線程擁擠的情況，Web Worker應(yīng)運而生。而同樣，Node也提供了child_process.fork來創(chuàng)建Node的子進程。在一個Node進程就能很好的解決密集I/O的情況下，fork出來的其余Node子進程可以當作常駐服務(wù)來解決運算阻塞的問題（將運算分發(fā)到多個Node子進程中上去，與Apache創(chuàng)建多個子進程類似）。當然child_process/Web Worker的機制永遠只能解決單臺機器的問題，大的Web應(yīng)用是不可能一臺服務(wù)器就能完成所有的請求服務(wù)的。拜NodeJS在I/O上的優(yōu)勢，跨OS的多Node之間通信的是不算什么問題的。解決NodeJS的運算密集問題的答案其實也是非常簡單的，就是將運算分發(fā)到多個CPU上。請參考文章后的multi-node的性能測試，可以看到在多Node進程的情景下，響應(yīng)請求的速度被大幅度提高。

　　在文章的寫作中，Node最新發(fā)布的0.5.10版本新增了cluster啟動參數(shù)。參數(shù)的使用方式如下：

node cluster server.js

it知識庫：一個前端工程師眼里的NodeJS，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。