現實比理想要骨感一些，但是要達成異步I/O的目標，并非難事。前面我們將場景限定在了單線程的狀況下，多線程的方式會是另一番風景。通過讓部分線程進行阻塞I/O或者非阻塞I/O加輪詢技術來完成數據獲取，讓一個線程進行計算處理，通過線程之間的通信將I/O得到的數據進行傳遞，這就輕松實現了異步I/O（盡管這是模擬的），示意圖如下：  glibc的AIO便是典型的線程池模擬異步I/O。然而遺憾的是，它存在一些難以忍受的缺陷和bug，不推薦采用。libev的作者 Marc Alexander Lehmann 重新實現了一個異步I/O的庫：libeio。libeio實質上依然是采用線程池與阻塞I/O模擬異步I/O。最初，Node在 `*nix`平臺上采用了libeio配合libev實現I/O部分，實現了異步I/O。在Node v0.9.3中，自行實現了線程池來完成異步I/O。 另一種我遲遲沒有透露的異步I/O方案則是Windows下的IOCP，它在某種程度上提供了理想的異步I/O：調用異步方法，等待I/O完成之后的通知，執行回調，用戶無須考慮輪詢。但是它的內部其實仍然是線程池原理，不同之處在于這些線程池由系統內核接手管理。 IOCP的異步I/O模型與Node的異步調用模型十分近似。在Windows平臺下采用了IOCP實現異步I/O。 由于Windows平臺和`*nix`平臺的差異，Node提供了libuv作為抽象封裝層，使得所有平臺兼容性的判斷都由這一層來完成，并保證上層的Node與下層的自定義線程池及IOCP之間各自獨立。Node在編譯期間會判斷平臺條件，選擇性編譯unix目錄或是win目錄下的源文件到目標程序中，架構如下圖：  需要強調的一點是，這里的I/O不僅僅只限于磁盤文件的讀寫。`*nix`將計算機抽象了一番，磁盤文件、硬件、套接字等幾乎所有計算機資源都被抽象為了文件，因此這里描述的阻塞和非阻塞的情況同樣能適合于套接字等。 另一個需要強調的地方在于，我們時常提到的Node是單線程的，這里的單線程僅僅只是JavaScript執行在單線程中罷了。在Node中，無論是 `*nix`還是Windows平臺，內部完成I/O任務的另有線程池。