Nodejs中libuv运行的原理是什么-创新互联

Nodejs 中libuv运行的原理是什么，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

成都创新互联公司是一家专注网站建设、网络营销策划、成都微信小程序、电子商务建设、网络推广、移动互联开发、研究、服务为一体的技术型公司。公司成立10年以来，已经为超过千家纱窗各业的企业公司提供互联网服务。现在，服务的超过千家客户与我们一路同行，见证我们的成长；未来，我们一起分享成功的喜悦。

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运行的原理是什么的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注创新互联行业资讯频道，感谢各位的阅读！

网页标题：Nodejs中libuv运行的原理是什么-创新互联
当前链接：http://cdiso.cn/article/eshpp.html