Node.js属于单线程事件循环架构，该事件循环由Libuv的uv_run函数实现，在该函数中执行while循环，然后不断地处理各个阶段（phase）的事件回调。事件循环的处理相当于一个消费者，消费由各种代码产生的任务。Node.js初始化完成后就开始陷入该事件循环中，事件循环的结束也就意味着Node.js的结束。下面看一下事件循环的核心代码。
int uv_run(uv_loop_t* loop, uv_run_mode mode) { int timeout; int r; int ran_pending; // 在uv_run之前要先提交任务到loop r = uv__loop_alive(loop); // 事件循环没有任务执行，即将退出，设置一下当前循环的时间 if (!r) uv__update_time(loop); // 没有任务需要处理或者调用了uv_stop则退出事件循环 while (r != 0 && loop->stop_flag == 0) { // 更新loop的time字段 uv__update_time(loop); // 执行超时回调 uv__run_timers(loop); /* 执行pending回调，ran_pending代表pending队列是否为空， 即没有节点可以执行 */ ran_pending = uv__run_pending(loop); // 继续执行各种队列 uv__run_idle(loop); uv__run_prepare(loop); timeout = 0; /* 执行模式是UV_RUN_ONCE时，如果没有pending节点， 才会阻塞式Poll IO，默认模式也是 */ if ((mode == UV_RUN_ONCE && !ran_pending) || mode == UV_RUN_DEFAULT) timeout = uv_backend_timeout(loop); // Poll IO timeout是epoll_wait的超时时间 uv__io_poll(loop, timeout); // 处理check阶段 uv__run_check(loop); // 处理close阶段 uv__run_closing_handles(loop); /* 还有一次执行超时回调的机会，因为uv__io_poll可能是因为 定时器超时返回的。 */ if (mode == UV_RUN_ONCE) { uv__update_time(loop); uv__run_timers(loop); } r = uv__loop_alive(loop); /* 只执行一次，退出循环,UV_RUN_NOWAIT表示在Poll IO阶段 不会阻塞并且循环只执行一次 */ if (mode == UV_RUN_ONCE || mode == UV_RUN_NOWAIT) break; } // 是因为调用了uv_stop退出的，重置flag if (loop->stop_flag != 0) loop->stop_flag = 0; /* 返回是否还有活跃的任务（handle或request）， 业务代表可以再次执行uv_run */ return r; }
Libuv分为几个阶段，下面从先到后，分别分析各个阶段的相关代码。
Libuv中，定时器阶段是第一个被处理的阶段。定时器是以最小堆实现的，最快过期的节点是根节点。Libuv在每次事件循环开始的时候都会缓存当前的时间，在每一轮的事件循环中，使用的都是这个缓存的时间，必要的时候Libuv会显式更新这个时间，因为获取时间需要调用操作系统提供的接口，而频繁调用系统调用会带来一定的耗时，缓存时间可以减少操作系统的调用，提高性能。Libuv缓存了当前最新的时间后，就执行uv__run_timers，该函数就是遍历最小堆，找出当前超时的节点。因为堆的性质是父节点肯定比孩子小。并且根节点是最小的，所以如果一个根节点，它没有超时，则后面的节点也不会超时。对于超时的节点就执行它的回调。我们看一下具体的逻辑。
void uv__run_timers(uv_loop_t* loop) { struct heap_node* heap_node; uv_timer_t* handle; // 遍历二叉堆 for (;;) { // 找出最小的节点 heap_node = heap_min(timer_heap(loop)); // 没有则退出 if (heap_node == NULL) break; // 通过结构体字段找到结构体首地址 handle = container_of(heap_node, uv_timer_t, heap_node); // 最小的节点都没有超市，则后面的节点也不会超时 if (handle->timeout > loop->time) break; // 删除该节点 uv_timer_stop(handle); /* 重试插入二叉堆，如果需要的话（设置了repeat，比如 setInterval） */ uv_timer_again(handle); // 执行回调 handle->timer_cb(handle); } }
执行完回调后，还有两个关键的操作，第一就是stop，第二就是again。stop的逻辑很简单，就是把handle从二叉堆中删除，并且修改handle的状态。那么again又是什么呢？again是为了支持setInterval这种场景，如果handle设置了repeat标记，则该handle在超时后，每repeat的时间后，就会继续执行超时回调。对于setInterval，就是超时时间是x，每x的时间后，执行回调。这就是Node.js里定时器的底层原理。但Node.js不是每次调setTimeout/setInterval的时候都往最小堆插入一个节点，Node.js里，只有一个关于uv_timer_s的handle，它在JS层维护了一个数据结构，每次计算出最早到期的节点，然后修改handle的超时时间，具体在定时器章节讲解。 另外timer阶段和Poll IO阶段也有一些联系，因为Poll IO可能会导致主线程阻塞，为了保证主线程可以尽快执行定时器的回调，Poll IO不能一直阻塞，所以这时候，阻塞的时长就是最快到期的定时器节点的时长（具体可参考libuv core.c中的uv_backend_timeout函数）。
官网对pending阶段的解释是在上一轮的Poll IO阶段没有执行的IO回调，会在下一轮循环的pending阶段被执行。从源码来看，Poll IO阶段处理任务时，在某些情况下，如果当前执行的操作失败需要执行回调通知调用方一些信息，该回调函数不会立刻执行，而是在下一轮事件循环的pending阶段执行（比如写入数据成功，或者TCP连接失败时回调C++层），我们先看pending阶段的处理。
static int uv__run_pending(uv_loop_t* loop) { QUEUE* q; QUEUE pq; uv__io_t* w; if (QUEUE_EMPTY(&loop->pending_queue)) return 0; // 把pending_queue队列的节点移到pq，即清空了pending_queue QUEUE_MOVE(&loop->pending_queue, &pq); // 遍历pq队列 while (!QUEUE_EMPTY(&pq)) { // 取出当前第一个需要处理的节点，即pq.next q = QUEUE_HEAD(&pq); // 把当前需要处理的节点移出队列 QUEUE_REMOVE(q); /* 重置一下prev和next指针，因为这时候这两个指针是 指向队列中的两个节点 */ QUEUE_INIT(q); w = QUEUE_DATA(q, uv__io_t, pending_queue); w->cb(loop, w, POLLOUT); } return 1; }
pending阶段的处理逻辑就是把pending队列里的节点逐个执行。我们看一下pending队列的节点是如何生产出来的。
void uv__io_feed(uv_loop_t* loop, uv__io_t* w) { if (QUEUE_EMPTY(&w->pending_queue)) QUEUE_INSERT_TAIL(&loop->pending_queue, &w->pending_queue); }
Libuv通过uv__io_feed函数生产pending任务，从Libuv的代码中我们看到IO错误的时候会调这个函数（如tcp.c的uv__tcp_connect函数）。
if (handle->delayed_error) uv__io_feed(handle->loop, &handle->io_watcher);
在写入数据成功后（比如TCP、UDP），也会往pending队列插入一个节点，等待回调。比如发送数据成功后执行的代码（udp.c的uv__udp_sendmsg函数）
// 发送完移出写队列 QUEUE_REMOVE(&req->queue); // 加入写完成队列 QUEUE_INSERT_TAIL(&handle->write_completed_queue, &req->queue); /* 有节点数据写完了，把IO观察者插入pending队列， pending阶段执行回调 */ uv__io_feed(handle->loop, &handle->io_watcher);
最后关闭IO的时候（如关闭一个TCP连接）会从pending队列移除对应的节点，因为已经关闭了，自然就不需要执行回调。
void uv__io_close(uv_loop_t* loop, uv__io_t* w) { uv__io_stop(loop, w, POLLIN | POLLOUT | UV__POLLRDHUP | UV__POLLPRI); QUEUE_REMOVE(&w->pending_queue); }
prepare,check,idle是Libuv事件循环中属于比较简单的一个阶段，它们的实现是一样的（见loop-watcher.c）。本节只讲解prepare阶段，我们知道Libuv中分为handle和request，而prepare阶段的任务是属于handle类型。这意味着除非我们显式移除，否则prepare阶段的节点在每次事件循环中都会被执行。下面我们先看看怎么使用它。
void prep_cb(uv_prepare_t *handle) { printf("Prep callback\n"); } int main() { uv_prepare_t prep; // 初始化一个handle，uv_default_loop是事件循环的核心结构体 uv_prepare_init(uv_default_loop(), &prep); // 注册handle的回调 uv_prepare_start(&prep, prep_cb); // 开始事件循环 uv_run(uv_default_loop(), UV_RUN_DEFAULT); return 0; }
执行main函数，Libuv就会在prepare阶段执行回调prep_cb。我们分析一下这个过程。
int uv_prepare_init(uv_loop_t* loop, uv_prepare_t* handle) { uv__handle_init(loop, (uv_handle_t*)handle, UV_PREPARE); handle->prepare_cb = NULL; return 0; }
init函数主要是做一些初始化操作。我们继续要看start函数。
int uv_prepare_start(uv_prepare_t* handle, uv_prepare_cb cb) { // 如果已经执行过start函数则直接返回 if (uv__is_active(handle)) return 0; if (cb == NULL) return UV_EINVAL; QUEUE_INSERT_HEAD(&handle->loop->prepare_handles, &handle->queue); handle->prepare_cb = cb; uv__handle_start(handle); return 0; }
uv_prepare_start函数主要的逻辑主要是设置回调，把handle插入loop的prepare_handles队列，prepare_handles队列保存了prepare阶段的任务。在事件循环的prepare阶段会逐个执行里面的节点的回调。然后我们看看Libuv在事件循环的prepare阶段是如何处理的。
void uv__run_prepare(uv_loop_t* loop) { uv_prepare_t* h; QUEUE queue; QUEUE* q; /* 把该类型对应的队列中所有节点摘下来挂载到queue变量， 相当于清空prepare_handles队列，因为如果直接遍历 prepare_handles队列，在执行回调的时候一直往prepare_handles 队列加节点，会导致下面的while循环无法退出。 先移除的话，新插入的节点在下一轮事件循环才会被处理。 */ QUEUE_MOVE(&loop->prepare_handles, &queue); // 遍历队列，执行每个节点里面的函数 while (!QUEUE_EMPTY(&queue)) { // 取下当前待处理的节点，即队列的头 q = QUEUE_HEAD(&queue); /* 取得该节点对应的整个结构体的基地址， 即通过结构体成员取得结构体首地址 */ h = QUEUE_DATA(q, uv_prepare_t, queue); // 把该节点移出当前队列 QUEUE_REMOVE(q); // 重新插入原来的队列 QUEUE_INSERT_TAIL(&loop->prepare_handles, q); // 执行回调函数 h->prepare_cb(h); } }
uv__run_prepare函数的逻辑很简单，但是有一个重点的地方就是执行完每一个节点，Libuv会把该节点重新插入队列中，所以prepare（包括idle、check）阶段的节点在每一轮事件循环中都会被执行。而像定时器、pending、closing阶段的节点是一次性的，被执行后就会从队列里删除。 我们回顾一开始的测试代码。因为它设置了Libuv的运行模式是默认模式。而prepare队列又一直有一个handle节点，所以它是不会退出的。它会一直执行回调。那如果我们要退出怎么办呢？或者说不要执行prepare队列的某个节点了。我们只需要stop一下就可以了。
int uv_prepare_stop(uv_prepare_t* handle) { if (!uv__is_active(handle)) return 0; // 把handle从prepare队列中移除，但还挂载到handle_queue中 QUEUE_REMOVE(&handle->queue); // 清除active标记位并且减去loop中handle的active数 uv__handle_stop(handle); return 0; }
stop函数和start函数是相反的作用，这就是Node.js中prepare、check、idle阶段的原理。
Poll IO是Libuv非常重要的一个阶段，文件IO、网络IO、信号处理等都在这个阶段处理，这也是最复杂的一个阶段。处理逻辑在core.c的uv__io_poll这个函数，这个函数比较复杂，我们分开分析。在开始分析Poll IO之前，先了解一下它相关的一些数据结构。 1 IO观察者uv__io_t。这个结构体是Poll IO阶段核心结构体。它主要是保存了IO相关的文件描述符、回 调、感兴趣的事件等信息。 2 watcher_queue观察者队列。所有需要Libuv处理的IO观察者都挂载在这个队列里，Libuv在Poll IO阶段会逐个处理。
下面我们开始分析Poll IO阶段。先看第一段逻辑。
// 没有IO观察者，则直接返回 if (loop->nfds == 0) { assert(QUEUE_EMPTY(&loop->watcher_queue)); return; } // 遍历IO观察者队列 while (!QUEUE_EMPTY(&loop->watcher_queue)) { // 取出当前头节点 q = QUEUE_HEAD(&loop->watcher_queue); // 脱离队列 QUEUE_REMOVE(q); // 初始化（重置）节点的前后指针 QUEUE_INIT(q); // 通过结构体成功获取结构体首地址 w = QUEUE_DATA(q, uv__io_t, watcher_queue); // 设置当前感兴趣的事件 e.events = w->pevents; /* 这里使用了fd字段，事件触发后再通过fd从watchs 字段里找到对应的IO观察者，没有使用ptr指向IO观察者的方案 */ e.data.fd = w->fd; // 如果w->events初始化的时候为0，则新增，否则修改 if (w->events == 0) op = EPOLL_CTL_ADD; else op = EPOLL_CTL_MOD; // 修改epoll的数据 epoll_ctl(loop->backend_fd, op, w->fd, &e) // 记录当前加到epoll时的状态 w->events = w->pevents; }
第一步首先遍历IO观察者，修改epoll的数据。然后准备进入等待。
psigset = NULL; if (loop->flags & UV_LOOP_BLOCK_SIGPROF) { sigemptyset(&sigset); sigaddset(&sigset, SIGPROF); psigset = &sigset; } /* http://man7.org/Linux/man-pages/man2/epoll_wait.2.html pthread_sigmask(SIG_SETMASK, &sigmask, &origmask); ready = epoll_wait(epfd, &events, maxevents, timeout); pthread_sigmask(SIG_SETMASK, &origmask, NULL); 即屏蔽SIGPROF信号，避免SIGPROF信号唤醒epoll_wait，但是却没 有就绪的事件 */ nfds = epoll_pwait(loop->backend_fd, events, ARRAY_SIZE(events), timeout, psigset); // epoll可能阻塞，这里需要更新事件循环的时间 uv__update_time(loop) ```
epoll_wait可能会引起主线程阻塞，所以wait返回后需要更新当前的时间，否则在使用的时候时间差会比较大，因为Libuv会在每轮时间循环开始的时候缓存当前时间这个值。其它地方直接使用，而不是每次都去获取。下面我们接着看epoll返回后的处理（假设有事件触发）。
// 保存epoll_wait返回的一些数据，maybe_resize申请空间的时候+2了 loop->watchers[loop->nwatchers] = (void*) events; loop->watchers[loop->nwatchers + 1] = (void*) (uintptr_t) nfds; for (i = 0; i < nfds; i++) { // 触发的事件和文件描述符 pe = events + i; fd = pe->data.fd; // 根据fd获取IO观察者，见上面的图 w = loop->watchers[fd]; // 会其它回调里被删除了，则从epoll中删除 if (w == NULL) { epoll_ctl(loop->backend_fd, EPOLL_CTL_DEL, fd, pe); continue; } if (pe->events != 0) { /* 用于信号处理的IO观察者感兴趣的事件触发了， 即有信号发生。 */ if (w == &loop->signal_io_watcher) have_signals = 1; else // 一般的IO观察者则执行回调 w->cb(loop, w, pe->events); nevents++; } } // 有信号发生，触发回调 if (have_signals != 0) loop->signal_io_watcher.cb(loop, &loop->signal_io_watcher, POLLIN);
上面的代码处理IO事件并执行IO观察者里的回调，但是有一个特殊的地方就是信号处理的IO观察者需要单独判断，它是一个全局的IO观察者，和一般动态申请和销毁的IO观察者不一样，它是存在于Libuv运行的整个生命周期。这就是Poll IO的整个过程。
close是Libuv每轮事件循环中最后的一个阶段。uv_close用于关闭一个handle，并且执行一个回调。uv_close产生的任务会插入到close阶段的队列，然后在close阶段被处理。我们看一下uv_close函数的实现。
void uv_close(uv_handle_t* handle, uv_close_cb close_cb) { // 正在关闭，但是还没执行回调等后置操作 handle->flags |= UV_HANDLE_CLOSING; handle->close_cb = close_cb; switch (handle->type) { case UV_PREPARE: uv__prepare_close((uv_prepare_t*)handle); break; case UV_CHECK: uv__check_close((uv_check_t*)handle); break; ... default: assert(0); } uv__make_close_pending(handle); }
uv_close设置回调和状态，然后根据handle类型调对应的close函数，一般就是stop这个handle，解除IO观察者注册的事件，从事件循环的handle队列移除该handle等等，比如prepare的close函数只是把handle从队列中移除。
void uv__prepare_close(uv_prepare_t* handle) { uv_prepare_stop(handle); } int uv_prepare_stop(uv_prepare__t* handle) { QUEUE_REMOVE(&handle->queue); uv__handle_stop(handle); return 0; }
根据不同的handle做不同的处理后，接着执行uv__make_close_pending往close队列追加节点。
// 头插法插入closing队列，在closing阶段被执行 void uv__make_close_pending(uv_handle_t* handle) { handle->next_closing = handle->loop->closing_handles; handle->loop->closing_handles = handle; }
然后在close阶段逐个处理。我们看一下close阶段的处理逻辑
// 执行closing阶段的的回调 static void uv__run_closing_handles(uv_loop_t* loop) { uv_handle_t* p; uv_handle_t* q; p = loop->closing_handles; loop->closing_handles = NULL; while (p) { q = p->next_closing; uv__finish_close(p); p = q; } } // 执行closing阶段的回调 static void uv__finish_close(uv_handle_t* handle) { handle->flags |= UV_HANDLE_CLOSED; ... uv__handle_unref(handle); // 从handle队列里移除 QUEUE_REMOVE(&handle->handle_queue); if (handle->close_cb) { handle->close_cb(handle); } }
uv__run_closing_handles会逐个执行每个任务节点的回调。
Libuv通过uv__loop_alive函数判断事件循环是否还需要继续执行。我们看看这个函数的定义。
static int uv__loop_alive(const uv_loop_t* loop) { return uv__has_active_handles(loop) || uv__has_active_reqs(loop) || loop->closing_handles != NULL; }
为什么会有一个closing_handle的判断呢？从uv_run的代码来看，执行完close阶段后，会立刻执行uv__loop_alive，正常来说，close阶段的队列是空的，但是如果我们在close回调里又往close队列新增了一个节点，而该节点不会在本轮的close阶段被执行，这样会导致执行完close阶段，但是close队列依然有节点，如果直接退出，则无法执行对应的回调。 我们看到有三种情况，Libuv认为事件循环是存活的。如果我们控制这三种条件就可以控制事件循环的的退出。我们通过一个例子理解一下这个过程。
const timeout = setTimeout(() => { console.log('never console') }, 5000); timeout.unref();
上面的代码中，setTimeout的回调是不会执行的。除非超时时间非常短，短到第一轮事件循环的时候就到期了，否则在第一轮事件循环之后，由于unref的影响，事件循环直接退出了。unref影响的就是handle这个条件。这时候事件循环代码如下。
while (r != 0 && loop->stop_flag == 0) { uv__update_time(loop); uv__run_timers(loop); // ... // uv__loop_alive返回false，直接跳出while，从而退出事件循环 r = uv__loop_alive(loop); }
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8