JavaScript單線程的誤解

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

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

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

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

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

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

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

node cluster server.js

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

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