Nodejs 中l(wèi)ibuv運行的原理是什么，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

扎賚特網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)公司,扎賚特網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為扎賚特上千提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設(shè)要多少錢，請找那個售后服務(wù)好的扎賚特做網(wǎng)站的公司定做！

1) libuv的架構(gòu)

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

Libuv的架構(gòu)

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

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

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

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

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

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

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

2. 線程池：線程池的數(shù)量可以通過環(huán)境變量UV_THREADPOOL_SIZE配置，最大不超過128個，默認(rèn)為4個。

Network I/O

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

在創(chuàng)建TCP鏈接的過程中，libuv直接參與Tcp_wrap.cc函數(shù)中的 TCPWrap::listen() 調(diào)用uv_listen()開始到執(zhí)行uv_io_start()結(jié)束?？雌饋砗芏虝旱倪^程，其實是類似linux kernel的中斷處理機制。

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

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

File I/O

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

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

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

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

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

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

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

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

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

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

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

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

看完上述內(nèi)容，你們掌握Nodejs 中l(wèi)ibuv運行的原理是什么的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

網(wǎng)頁標(biāo)題：Nodejs中l(wèi)ibuv運行的原理是什么
文章鏈接：http://m.newbst.com/article40/goheeo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供電子商務(wù)、面包屑導(dǎo)航、靜態(tài)網(wǎng)站、網(wǎng)站導(dǎo)航、網(wǎng)站設(shè)計公司、企業(yè)網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)