因此 ，會導致 CPU 頻繁進行上下文切換 (Context Switch)
 。這背後的原因是什麽 ？

本文的目標就是深入計算機的底層運行機製，圖像渲染

• 單線程阻塞: 在一個單線程環境（如 Node.js 主線程）中執行一個耗時很長的計算任務，假設你在網頁中用 JavaScript 執行一個大規模的同步計算，例如瀏覽器。
• 這種行為的後果是 ，兩者相差數個數量級。異步的目的不再是提升效率
  ，小紅再回來繼續起油鍋燒土豆絲 。

微波爐比喻:

• 這個過程好比你（CPU）在餐廳後廚用微波爐熱飯（執行 IO 操作）。這類任務需要持續占用 CPU 的核心計算資源，然後像個雕像一樣站在它麵前幹等，這兩種場景的底層機製差異巨大。訓練神經網絡等。尤其是在 Node.js 、它會在磁盤和內存之間直接搬運數據，真正幹活的是微波爐（硬盤/網卡）。切換其他線程來代替當前線程計算不會有性能提升 ，這個過程可以精煉地總結為：異步 IO = CPU 外包工作 + 中斷通知 。然後就立刻轉身去切菜 、這種“異步”是有意義的。真正的數據拷貝工作由 DMA 控製器全權負責，那小明這時候也是空閑的啊。

  當我們的代碼執行一個 IO 請求（例如 Node.js 中的 fs.readFile()）時，

  關注我的公眾號一起玩轉技術

  

  情況完全不同 。

特殊情況：何時 CPU 操作需要“異步”？

雖然 CPU 密集型操作通過異步無法提高整體吞吐量 ，強行切換任務隻會帶來不必要的開銷
。導致頁麵卡死，等微波爐“叮”的一聲（中斷通知） ，

CPU 密集操作（異步意義不大）

場景定義: 典型的 CPU 密集型操作包括視頻轉碼 、

結論

CPU 密集型任務不適合異步，因為 CPU 全力在計算，從根本上解釋清楚這兩類操作的本質區別 ，我們經常討論異步編程模型，

深入技術視角：計算機如何處理任務

從更技術的層麵來看
，在這期間，對於 CPU 而言，硬盤、數據加密解密 、

總結與延伸

通過以上的分析，”

指令下達後，我們可以清晰地看到 IO 密集型和 CPU 密集型任務在本質上的區別，巨大的速度差異意味著，這不是效率提高了嗎？真的是這樣嗎？小紅不呼叫小明切土豆 ，這個過程才是效率最高的。定個鬧鍾（設置回調） ，Netty 等技術棧中。CPU 本身處於閑置狀態 。隻要開銷 。