Nodejs 中libuv運行的原理是什么

Nodejs 中libuv運行的原理是什么，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

1) libuv的架構

2) 案例，從細節的角度看libuv是如何對待不同I/O請求，按照不同的方式來完成異步請求和數據返回的。

Libuv的架構

從左往右可分為兩部分，Network I/O的相關請求，另一部分File I/O，DNS Ops和User Code組成。

上圖展示了libuv細節的流程，圖中代碼很簡單，包括2個部分：

1. server.listen()是用來創建TCP server時，通常放在最后一步執行的代碼。主要指定服務器工作的端口以及回調函數。

2. fs.open()是用異步的方式打開一個文件。

選擇兩個示例很簡單，因為libuv架構圖可視：libuv對 Network I/O和 File I/O采用不同的機制。

上圖右半部分，主要分成兩個部分：

1. 主線程：主線程也是node啟動時執行的現成。node啟動時，會完成一系列的初始化動作，啟動V8 engine，進入下一個循環。

2. 線程池：線程池的數量可以通過環境變量UV_THREADPOOL_SIZE配置，最大不超過128個，默認為4個。

Network I/O

V8 engine執行從server.listen() 開始，調用builtin module Tcp_wrap 的過程。

在創建TCP鏈接的過程中，libuv直接參與Tcp_wrap.cc函數中的 TCPWrap::listen() 調用uv_listen()開始到執行uv_io_start()結束。看起來很短暫的過程，其實是類似linux kernel的中斷處理機制。

uv_io_start()負載將handle插入到處理的water queue中。這樣的好處是請求能夠立即得到處理。中斷處理機制里面的下半部分與數據處理操作相似，交由主線程去完成處理。

代碼邏輯很簡單，查看loop中是否包含handle，如果有遍歷default loop。

File I/O

這里我們研究一下 File I/O。

同Network I/O一樣，我們的應用所依賴的fs模塊，后面有一個builtin module Node_file.cc作為支撐。 Node_file.cc包含了各種我們常用的文件操作的接口，例如open, read, write, chmod,chown等。但同時，它們都支持異步模式。 我們通過Node_file.cc中的Open()函數來研究一下具體的實現細節。

如果你用類似source insight之類的代碼閱讀工具跟蹤一下代碼調用順序，會很容易發現對于異步模式，Open()函數會在一系列輔助操作之后，進入函數uv_fs_open(),并且傳入了一個FSReqWrap的對象。

FSReqWrap()，從名字可以看得出來，這是一個wrap,且是與FS相關的請求。也就是說，它基于某一個現成的機制來實現與FS相關的請求操作。這個現成的機制就是ReqWrap。好吧，它也是個wrap。乘你還沒瘋的時候，看一下圖6吧。這里完整展示了FSReqWrap類繼承關系。

除了FSReqWrap，還有其它Wrap,例如PipeConnectWrap，TCPConnectWrap等等。每個Wrap均為一種請求類型服務。 但是這些wrap，都是node自身的行為，而與libuv相關的是什么呢？上圖中表示出了FSReqWrap關鍵的數據結構 uv_fs_s req__。

讓我們把目光回到uv_fs_open()。在調用這個函數時， req__作為其一個重要的參數被傳遞進去。而在uv_fs_open()內部，req__則被添加到work queue的末尾中去。圖3 thread pool中的thread會去領取這些request進行處理。 每個request很像一個粘貼板，它將event loop, work queue，每個請求的處理函數(work())，以及請求結束處理函數(done())綁定在一起。綁定的操作在uv__work_submit()中完成。 例如對于這里的req__，綁定在它身上的work()為uv__fs_work(), done()為uv__fs_done()。

這里有一個比較有意思的問題值得額外看一下。我們的thread pool是在什么時候建立的呢？

答案是：在第一次異步調用uv__work_submit()時。

每個thead的入口函數是 Threadpool.c中的worker()。工作邏輯比較簡單，依次取出work queue中的請求，執行綁定在該請求上的work()函數。 前面我們提到的綁定在請求上的done()函數在哪里執行呢？這也是一個比較有意思的操作。libuv通過uv_async_send()通知event loop去執行相應的callback函數，也即我們綁定在request上的done()函數。uv__work_done()用于完成這樣的操作。

uv_async_send()與主線程之間通過PIPE通信。

我在這一小節以一個FSReqWrap以及Open()函數為例，描述了libuv處理這種File I/O請求時所涉及的各種操作：

建立thread pool(只建立一次) 在每個請求req__上綁定與其相關的event loop, work queue, work(), done() thread worker()用來處理work queue里面的每個請求，并執行work() 通過uv_async_send()通知event loop執行done()

看完上述內容，你們掌握Nodejs 中libuv運行的原理是什么的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！