您好,登錄后才能下訂單哦!
這篇文章主要講解了“Nodejs中的非阻塞異步IO是什么”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“Nodejs中的非阻塞異步IO是什么”吧!
我們以網絡請求IO為例,首先介紹服務端處理一次完整的網絡IO請求的典型流程:
應用程序獲得一個操作結果,通常包括兩個不同的階段:
等待數據準備好
從內核向進程復制數據
以下,我們以 recvfrom
函數為例,解釋說明各種IO模型
阻塞調用是指調用結果返回之前,當前線程會被掛起,調用線程只有在等待系統內核層面所有操作完成之后,調用才會結束。
阻塞I/O造成了cpu的等待I/O,浪費了CPU的時間片。
相比于前者,非阻塞I/O不帶數據直接返回,要獲取數據,還需要通過文件描述符再次嘗試讀取數據
非阻塞調用得到返回(并不是真實的期待數據)之后,CPU時間片可以用于處理其他的事情,可以明顯提升性能。
但是隨之而來的問題是,之前的操作并不是一次完整的I/O,返回得到的結果不是期望得到的業務數據,而僅僅是異步調用狀態。
為了獲取完整的數據,應用程序需要重復調用IO操作來確認操作是否已經完成,這種操作我們稱之為輪詢,常見的幾種輪詢策略如下
這是最原始,也是性能最低的一種方式,通過重復調用來檢查I/O狀態達到獲取完整數據的目的
優點:編程簡單
缺點:CPU一直耗費在輪詢上,同時影響服務器性能,因為你輪詢之后服務器還要進行作答
在 I/O 復用模型中,會用到 Select 或 Poll 函數或 Epoll 函數(Linux 2.6 以后的內核開始支持),這兩個函數也會使進程阻塞,但是和阻塞 I/O 有所不同。
這三個函數可以同時阻塞多個 I/O 操作,而且可以同時對多個讀操作,多個寫操作的 I/O 函數進行檢測,直到有數據可讀或可寫時,才真正調用 I/O 操作函數。
三種I/O復用機制的區別如下
select
由于select采用1024長度的數組來存儲文件狀態,因此最多可以同時檢測1024個文件描述符
poll
相比select略有改進,采用鏈表避免了1024的長度限制,并且能避免不需要的遍歷檢查,相比select性能稍有改善
epoll/kqueue
是linux下效率最高的I/O事件通知機制,輪詢時如果沒有檢測到I/O事件,將會進行休眠,直到事件發生將線程喚醒。它是真正利用了事件通知,執行回調,而不是遍歷(文件描述符)查詢,因此不會浪費CPU
小結:本質上說,輪詢仍然是一種同步操作,因為應用程序仍然在等待I/O完全返回,等待期間要么遍歷文件描述狀態,要么休眠等待事件的發生。
在信號驅動式 I/O 模型中,應用程序使用信號驅動 I/O,并安裝一個信號處理函數,進程繼續運行并不阻塞。
當數據準備好時,程序會收到一個 SIGIO 信號,可以在信號處理函數中調用 I/O 操作函數處理數據。
小結:到此為止,信號驅動式I/O模型是更加符合我們的異步需求的,程序會在等待數據的過程中異步執行其他的業務邏輯。
但是!!! 在數據從內核復制到用戶空間過程中依然是阻塞的,并不能算是一場徹底的革命(異步)。
我們理想中的異步I/O應該是應用程序發起非阻塞調用,無需通過輪詢的方式進行數據獲取,更沒有必要在數據拷貝階段進行無謂的等待,而是能夠在I/O完成之后,通過信號或者回調函數的方式傳遞給應用程序,在此期間應用程序可以執行其他業務邏輯。
實際上,linux平臺下原生支持了異步I/O(AIO),但是目前 AIO 并不完善,因此在 Linux 下實現高并發網絡編程時都是以 I/O 復用模型為主。
而Windows 下通過 IOCP 實現了真正的異步 I/O。
linux平臺下,Node利用線程池,通過讓部分線程進行阻塞I/O或者非阻塞I/O+輪詢的方式完成數據獲取,讓某一個單獨的線程進行計算,通過線程之間的通信,將I/O結果進行傳遞,這樣便實現了異步I/O的模擬。
其實Windows平臺下的IOCP異步異步方案底層也是采用線程池的方式實現的,所不同的是,后者的線程池是由系統內核進行托管的。
我們常說Node是單線程的,但其實只能說是JS執行在單線程中,無論是*nix還是windows平臺,底層都是利用線程池來完成I/O操作。
感謝各位的閱讀,以上就是“Nodejs中的非阻塞異步IO是什么”的內容了,經過本文的學習后,相信大家對Nodejs中的非阻塞異步IO是什么這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。