nodejs中，zlib gzip系列純cpu計算函式為什麼會有非同步版本？

1樓：Colliot

這實際上是理想的情況啊。都說 Node.js 單執行緒，不適合 CPU 密集型的場景。

但是如果能把所有 CPU 密集型的操作，都封裝成非同步的「IO 型」操作，那這個問題就解決了。

現在的問題不是 zlib 等計算函式是非同步的，而是你自己寫的計算函式預設不是非同步的，即使封裝成非同步的它也不會多開乙個執行緒/程序去跑。

除非你也寫 C++ 模組，但這樣用 JS（對我來說是 TS）帶來的方便性就沒了；或者也可以做成 worker 形式，單獨開程序去跑，用某種 RPC 去呼叫，化激計算為 IO。雖然總體而言 Node.js 的計算效能可能就不高，但我覺得這麼做還是有意義的。

2樓：熊傑

也許為了以後支援多核實現。方便相容以前的api。畢竟多核後可以是非同步的。又或者底層可能就是多執行緒的。在壓縮的同時能保證你的電腦不當機。

3樓：

這就和fs庫一樣，其實都是多執行緒在跑。eventloop只是等待多執行緒執行完，而不是把讀寫檔案這個操作放在eventloop中執行。

當然大部分js寫的計算（比如1+1）還是在eventloop執行完，才執行下乙個事件。

4樓：Roc.L

JS 的執行環境是單執行緒的，但是實現 Node 環境的語言 C++ 可以是多執行緒的，所以如果不希望計算量大的操作阻塞 JS 執行，那就用 C++ 實現（這樣的執行速度也會更快），再用 JS 去呼叫。

5樓：謝慕安

因為它們很耗CPU，所以必須要有非同步的版本；以web業務來說，就是會影響QPS。

實現上，就是開單獨的執行緒來做這種重CPU的運算，使得主線程可以繼續執行別的業務邏輯。

壓縮是同步的情況：

在紅框的時間內，儘管別的請求到來，但不能得到及時的處理壓縮是非同步的情況：

主線程不被阻塞，可以繼續處理其它的請求

6樓：死月絲卡蕾特

純 CPU 計算就不能流式了？

要知道 Node.js 在使用者層是單執行緒的，你用同步版本的話，直接會阻塞時間迴圈——這期間你做不了任何事情。

而如果用了非同步版本，它會採用流式去操作，並且這些操作都是在 libuv 的其它執行緒中完成，並不會阻塞事件迴圈，並且在 Stream 流資料的空檔依舊可以有很多主事件迴圈中的操作可以做。

同步版本是顯示將所有的計算都抬到明面上來阻塞了，相當於你在其它語言中寫個單執行緒程式，而非同步版本實際上是跑在多執行緒下，主事件迴圈上的安排還是繼續在跑，並不會完全被阻塞住。

7樓：

你大概不希望乙個 gzip 操作卡住你 server，所以有非同步版本。這和 Node.js 的非同步信仰沒有半毛錢關係。

再說了，現在有了 async 和 await，寫起來沒什麼差別。