[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8},"actionData","errors","root",{"_11":-5},"routes/user.$name.collections",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":16},"topics",[35],"user",{"_20":21,"_13":14,"_22":23,"_24":14,"_25":26,"_27":28,"_29":30,"_31":32,"_33":34},"loginname","CaanDoll","page",1,"limit",20,"total","id","34401","avatar_url","https://avatars1.githubusercontent.com/u/23540471?v=4","githubUsername","create_at","2018-08-09 01:29:54.705","score",310,"topic_count",4,"reply_count",58,"is_star",false,{"_20":36,"_37":38,"_39":40,"_41":42,"_43":44,"_45":46,"_47":48,"_49":34,"_31":50,"_51":52,"_25":53,"_54":55},"31191","author_id","19734","tab","share","content","# 2018/5/8更新：\r\n距离这篇文章完笔虽然才两个月，但是我已经对各种细节忘记得差不多（不常用的东西马上就忘记了，大脑内存不足会经常自动腾出空间记忆别的事情），各位如果有任何疑问我大概率是回答不上来，非常抱歉。另外我觉得深入折腾这种东西意义其实不是太大，还不如学习一下更加通用价值更加高的知识（例如算法、数据库原理、操作系统原理、tcp/ip协议、架构设计、高数线代概率统计等）\r\n\r\n\r\n# 不同的event loop\r\nevent loop是一个执行模型，在不同的地方有不同的实现。浏览器和nodejs基于不同的技术实现了各自的event loop。网上关于它的介绍多如牛毛，但大多数是基于浏览器的，真正讲nodejs的event loop的并没有多少，甚至很多将浏览器和nodejs的event loop等同起来的。我觉得讨论event loop要做到以下两点： \r\n* **首先要确定好上下文，nodejs和浏览器的event loop是两个有明确区分的事物，不能混为一谈**。\r\n* 其次，讨论一些js异步代码的执行顺序时候，**要基于node的源码而不是自己的臆想**。 \r\n\r\n简单来讲， \r\n* **nodejs的event是基于libuv，而浏览器的event loop则在[html5的规范](https://www.w3.org/TR/html5/webappapis.html#event-loops)中明确定义**。\r\n* libuv已经对event loop作出了实现，而html5规范中只是定义了浏览器中event loop的模型，具体实现留给了浏览器厂商。\r\n\r\n# nodejs中的event loop\r\n关于nodejs中的event loop有两个地方可以参考，一个是nodejs[官方的文档](https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/)；另一个是libuv的[官方的文档](http://docs.libuv.org/en/v1.x/design.html)，前者已经对nodejs有一个比较完整的描述，而后者则有更多细节的描述。nodejs正在快速发展，源码变化很大，以下的讨论都是基于nodejs9.5.0。\r\n\r\n（然而nodejs的event loop似乎比预料更加复杂，在查看nodejs源码的过程中我惊奇发现原来nodejs的event loop的某些阶段，还会将v8的micro task queue中的任务取出来运行，看来nodejs的浏览器的event loop还是存在一些关联，这些细节我们往后再讨论，目前先关注重点内容。）\r\n\r\n\r\n\r\n## event loop的6个阶段（phase）\r\nnodejs的event loop分为6个阶段，每个阶段的作用如下（`process.nextTick()`在6个阶段结束的时候都会执行，文章后半部分会详细分析`process.nextTick()`的回调是怎么引进event loop，仅仅从`uv_run()`是找不到`process.nextTick()`是如何牵涉进来）：\r\n* timers：执行`setTimeout()` 和 `setInterval()`中到期的callback。\r\n* I/O callbacks：上一轮循环中有少数的I/Ocallback会被延迟到这一轮的这一阶段执行\r\n* idle, prepare：仅内部使用\r\n* poll：最为重要的阶段，执行I/O callback，在适当的条件下会阻塞在这个阶段\r\n* check：执行setImmediate的callback\r\n* close callbacks：执行close事件的callback，例如`socket.on(\"close\",func)`\r\n```C\r\n ┌───────────────────────┐\r\n┌─>│ timers │\r\n│ └──────────┬────────────┘\r\n│ ┌──────────┴────────────┐\r\n│ │ I/O callbacks │\r\n│ └──────────┬────────────┘\r\n│ ┌──────────┴────────────┐\r\n│ │ idle, prepare │\r\n│ └──────────┬────────────┘ ┌───────────────┐\r\n│ ┌──────────┴────────────┐ │ incoming: │\r\n│ │ poll │<─────┤ connections, │\r\n│ └──────────┬────────────┘ │ data, etc. │\r\n│ ┌──────────┴────────────┐ └───────────────┘\r\n│ │ check │\r\n│ └──────────┬────────────┘\r\n│ ┌──────────┴────────────┐\r\n└──┤ close callbacks │\r\n └───────────────────────┘\r\n```\r\nevent loop的每一次循环都需要依次经过上述的阶段。每个阶段都有自己的callback队列，每当进入某个阶段，都会从所属的队列中取出callback来执行，当队列为空或者被执行callback的数量达到系统的最大数量时，进入下一阶段。这六个阶段都执行完毕称为一轮循环。\r\n\r\nevent loop的核心代码在deps/uv/src/unix/core.c\r\n```C\r\nint uv_run(uv_loop_t* loop, uv_run_mode mode) {\r\n int timeout;\r\n int r;\r\n int ran_pending;\r\n\r\n /*\r\n 从uv__loop_alive中我们知道event loop继续的条件是以下三者之一：\r\n 1，有活跃的handles（libuv定义handle就是一些long-lived objects，例如tcp server这样）\r\n 2，有活跃的request\r\n 3，loop中的closing_handles\r\n */\r\n r = uv__loop_alive(loop);\r\n if (!r)\r\n uv__update_time(loop);\r\n\r\n while (r != 0 && loop->stop_flag == 0) {\r\n uv__update_time(loop);//更新时间变量，这个变量在uv__run_timers中会用到\r\n uv__run_timers(loop);//timers阶段\r\n ran_pending = uv__run_pending(loop);//从libuv的文档中可知，这个其实就是I/O callback阶段,ran_pending指示队列是否为空\r\n uv__run_idle(loop);//idle阶段\r\n uv__run_prepare(loop);//prepare阶段\r\n\r\n timeout = 0;\r\n\r\n /**\r\n 设置poll阶段的超时时间，以下几种情况下超时会被设为0，这意味着此时poll阶段不会被阻塞，在下面的poll阶段我们还会详细讨论这个\r\n 1，stop_flag不为0\r\n 2，没有活跃的handles和request\r\n 3，idle、I/O callback、close阶段的handle队列不为空\r\n 否则，设为timer阶段的callback队列中，距离当前时间最近的那个\r\n **/ \r\n if ((mode == UV_RUN_ONCE && !ran_pending) || mode == UV_RUN_DEFAULT)\r\n timeout = uv_backend_timeout(loop);\r\n\r\n uv__io_poll(loop, timeout);//poll阶段\r\n uv__run_check(loop);//check阶段\r\n uv__run_closing_handles(loop);//close阶段\r\n //如果mode == UV_RUN_ONCE（意味着流程继续向前）时，在所有阶段结束后还会检查一次timers，这个的逻辑的原因不太明确\r\n \r\n if (mode == UV_RUN_ONCE) {\r\n uv__update_time(loop);\r\n uv__run_timers(loop);\r\n }\r\n\r\n r = uv__loop_alive(loop);\r\n if (mode == UV_RUN_ONCE || mode == UV_RUN_NOWAIT)\r\n break;\r\n }\r\n\r\n if (loop->stop_flag != 0)\r\n loop->stop_flag = 0;\r\n\r\n return r;\r\n}\r\n\r\n```\r\n我对重要部分加上注释，从上述代码可以看到event loop的六个阶段是依次执行的。值得注意的是，在UV_RUN_ONCE模式下，timers阶段在当前循环结束前还会得到一次的执行机会。 \r\n\r\n## timers阶段\r\ntimer阶段的代码在deps/uv/src/unix/timer.c的`uv__run_timers()`中\r\n```C\r\nvoid uv__run_timers(uv_loop_t* loop) {\r\n struct heap_node* heap_node;\r\n uv_timer_t* handle;\r\n\r\n for (;;) {\r\n heap_node = heap_min((struct heap*) &loop->timer_heap);//取出timer堆上超时时间最小的元素\r\n if (heap_node == NULL)\r\n break;\r\n //根据上面的元素，计算出handle的地址，head_node结构体和container_of的结合非常巧妙，值得学习\r\n handle = container_of(heap_node, uv_timer_t, heap_node);\r\n if (handle->timeout > loop->time)//如果最小的超时时间比循环运行的时间还要大，则表示没有到期的callback需要执行，此时退出timer阶段\r\n break;\r\n\r\n uv_timer_stop(handle);//将这个handle移除\r\n uv_timer_again(handle);//如果handle是repeat类型的，重新插入堆里\r\n handle->timer_cb(handle);//执行handle上的callback\r\n }\r\n}\r\n```\r\n从上面的逻辑可知，**在timer阶段其实使用一个最小堆而不是队列来保存所有元素**（其实也可以理解，因为timeout的callback是按照超时时间的顺序来调用的，并不是先进先出的队列逻辑），然后循环取出所有到期的callback执行。\r\n\r\n## I/O callbacks阶段\r\nI/O callbacks阶段的代码在deps/uv/src/unix/core.c的`int uv__run_pending()`中\r\n```C\r\nstatic int uv__run_pending(uv_loop_t* loop) {\r\n QUEUE* q;\r\n QUEUE pq;\r\n uv__io_t* w;\r\n\r\n if (QUEUE_EMPTY(&loop->pending_queue))//如果队列为空则退出\r\n return 0;\r\n\r\n QUEUE_MOVE(&loop->pending_queue, &pq);//移动该队列\r\n\r\n while (!QUEUE_EMPTY(&pq)) {\r\n q = QUEUE_HEAD(&pq);//取出队列的头结点\r\n QUEUE_REMOVE(q);//将其移出队列\r\n QUEUE_INIT(q);//不再引用原来队列的元素\r\n w = QUEUE_DATA(q, uv__io_t, pending_queue);\r\n w->cb(loop, w, POLLOUT);//执行callbak直到队列为空\r\n }\r\n return 1;\r\n}\r\n```\r\n根据libuv的文档，一些应该在上轮循环poll阶段执行的callback，因为某些原因不能执行，就会被延迟到这一轮的循环的I/O callbacks阶段执行。换句话说这个阶段执行的callbacks是上轮残留的。\r\n\r\n## idle和prepare阶段\r\n`uv__run_idle()`、`uv__run_prepare()`、`uv__run_check()`定义在文件deps/uv/src/unix/loop-watcher.c中，它们的逻辑非常相似，其中的实现利用了大量的宏（说实在我个人非常烦宏，它的可读性真的很差，为了那点点的性能而使用宏真是值得商榷）。\r\n```C\r\n void uv__run_##name(uv_loop_t* loop) { \\\r\n uv_##name##_t* h; \\\r\n QUEUE queue; \\\r\n QUEUE* q; \\\r\n QUEUE_MOVE(&loop->name##_handles, &queue);//用新的头节点取代旧的头节点，相当于将原队列移动到新队列 \\\r\n while (!QUEUE_EMPTY(&queue)) {//当新队列不为空 \\\r\n q = QUEUE_HEAD(&queue);//取出新队列首元素 \\\r\n h = QUEUE_DATA(q, uv_##name##_t, queue);//获取首元素中指向的handle \\\r\n QUEUE_REMOVE(q);//将这个元素移出新队列 \\\r\n QUEUE_INSERT_TAIL(&loop->name##_handles, q);//然后再插入旧队列尾部 \\\r\n h->name##_cb(h);//执行对应的callback \\\r\n } \\\r\n } \r\n```\r\n\r\n## poll阶段\r\npoll阶段的代码+注释高达200行不好逐行分析，我们挑选部分重要代码\r\n\r\n```C\r\nvoid uv__io_poll(uv_loop_t* loop, int timeout) {\r\n\t//...\r\n\t//处理观察者队列\r\n\twhile (!QUEUE_EMPTY(&loop->watcher_queue)) {\r\n\t\t//...\r\n\tif (w->events == 0)\r\n\t op = UV__EPOLL_CTL_ADD;//新增监听这个事件\r\n\telse\r\n\t op = UV__EPOLL_CTL_MOD;//修改这个事件\r\n\t}\r\n \t//...\r\n \t//阻塞直到监听的事件来临，前面已经算好timeout以防uv_loop一直阻塞下去\r\n\tif (no_epoll_wait != 0 || (sigmask != 0 && no_epoll_pwait == 0)) {\r\n\t nfds = uv__epoll_pwait(loop->backend_fd,\r\n\t events,\r\n\t ARRAY_SIZE(events),\r\n\t timeout,\r\n\t sigmask);\r\n\t if (nfds == -1 && errno == ENOSYS)\r\n\t no_epoll_pwait = 1;\r\n\t} else {\r\n\t nfds = uv__epoll_wait(loop->backend_fd,\r\n\t events,\r\n\t ARRAY_SIZE(events),\r\n\t timeout);\r\n\t if (nfds == -1 && errno == ENOSYS)\r\n\t no_epoll_wait = 1;\r\n\t}\r\n\t//...\r\n\tfor (i = 0; i < nfds; i++) {\r\n\t if (w == &loop->signal_io_watcher)\r\n\t have_signals = 1;\r\n\t else\r\n\t w->cb(loop, w, pe->events);//执行callback\r\n\t}\r\n\t//...\r\n}\r\n```\r\n可见poll阶段的任务就是阻塞等待监听的事件来临，然后执行对应的callback，其中阻塞是带有超时时间的，以下几种情况都会使得超时时间为0\r\n* uv_run处于UV_RUN_NOWAIT模式下\r\n* `uv_stop()`被调用\r\n* 没有活跃的handles和request\r\n* 有活跃的idle handles\r\n* 有等待关闭的handles\r\n\r\n如果上述都不符合，则超时时间为距离现在最近的timer；如果没有timer则poll阶段会一直阻塞下去\r\n\r\n## check阶段\r\n见上面的 *idle和prepare阶段*\r\n\r\n## close阶段\r\n```C\r\nstatic void uv__run_closing_handles(uv_loop_t* loop) {\r\n uv_handle_t* p;\r\n uv_handle_t* q;\r\n\r\n p = loop->closing_handles;\r\n loop->closing_handles = NULL;\r\n\r\n while (p) {\r\n q = p->next_closing;\r\n uv__finish_close(p);\r\n p = q;\r\n }\r\n}\r\n```\r\n这段代码非常浅显，就是循环关闭所有的closing handles，无需多言。其中的callback调用在`\r\nuv__finish_close()`中\r\n\r\n## process.nextTick在哪里\r\n文档中提到`process.nextTick()`不属于上面的任何一个phase，它在每个phase结束的时候都会运行。但是我们看到`uv_run()`中只是依次运行了6个phase的函数，并没有`process.nextTick()`影子，那它是怎么被驱动起来的呢？ \r\n这个问题要从两个c++和js的源码层面来说明。\r\n\r\n### process.nextTick在js层面的实现\r\n`process.nextTick`的实现在next_tick.js中\r\n```javascript\r\n function nextTick(callback) {\r\n if (typeof callback !== 'function')\r\n throw new errors.TypeError('ERR_INVALID_CALLBACK');\r\n\r\n if (process._exiting)\r\n return;\r\n\r\n var args;\r\n switch (arguments.length) {\r\n case 1: break;\r\n case 2: args = [arguments[1]]; break;\r\n case 3: args = [arguments[1], arguments[2]]; break;\r\n case 4: args = [arguments[1], arguments[2], arguments[3]]; break;\r\n default:\r\n args = new Array(arguments.length - 1);\r\n for (var i = 1; i < arguments.length; i++)\r\n args[i - 1] = arguments[i];\r\n }\r\n\r\n push(new TickObject(callback, args, getDefaultTriggerAsyncId()));//将callback封装为一个对象放入队列中\r\n }\r\n```\r\n它并没有什么魔法，也没有调用C++提供的函数，只是简单地将所有回调封装为对象并放入队列。而callback的执行是在函数`_tickCallback()`\r\n```javascript\r\n function _tickCallback() {\r\n let tock;\r\n do {\r\n while (tock = shift()) {\r\n const asyncId = tock[async_id_symbol];\r\n emitBefore(asyncId, tock[trigger_async_id_symbol]);\r\n if (destroyHooksExist())\r\n emitDestroy(asyncId);\r\n\r\n const callback = tock.callback;\r\n if (tock.args === undefined)\r\n callback();//执行调用process.nextTick()时放置进来的callback\r\n else\r\n Reflect.apply(callback, undefined, tock.args);//执行调用process.nextTick()时放置进来的callback\r\n\r\n emitAfter(asyncId);\r\n }\r\n runMicrotasks();//microtasks将会在此时执行，例如Promise\r\n } while (head.top !== head.bottom || emitPromiseRejectionWarnings());\r\n tickInfo[kHasPromiseRejections] = 0;\r\n }\r\n```\r\n可以看到`_tickCallback()`会循环执行队列中所有callback，值得注意的是microtasks的执行时机，因此`_tickCallback()`的执行就意味着`process.nextTick()`的回调的执行。我们继续搜索一下发现`_tickCallback()`在好几个地方都有被调用，但是我们只关注跟event loop相关的。 \r\n在next_tick.js中发现\r\n```javascript\r\n const [\r\n tickInfo,\r\n runMicrotasks\r\n ] = process._setupNextTick(_tickCallback);\r\n```\r\n\r\n查找了一下发现在node.cc中有\r\n```C++\r\nenv->SetMethod(process, \"_setupNextTick\", SetupNextTick);//暴露_setupNextTick给js\r\n```\r\n`_setupNextTick()`是node.cc那边暴露出来的方法，因此猜测这就是连接event loop的桥梁。\r\n\r\n\r\n### c++中执行process.nextTick的回调\r\n在node.cc中找出`SetupNextTick()`函数，有这样的代码片段\r\n\r\n```C++\r\nvoid SetupNextTick(const FunctionCallbackInfo& args) {\r\n Environment* env = Environment::GetCurrent(args);\r\n\r\n CHECK(args[0]->IsFunction());\r\n //把js中提供的回调函数（即_tickCallback）保存起来，以供调用\r\n env->set_tick_callback_function(args[0].As());\r\n ...\r\n}\r\n```\r\n`_tickCallback`被放置到env里面去了，那它何时被调用？也是在node.cc中我们发现\r\n```C++\r\nvoid InternalCallbackScope::Close() {\r\n if (!tick_info->has_scheduled()) {\r\n env_->isolate()->RunMicrotasks();\r\n }\r\n //...\r\n //终于调用在SetupNextTick()中放置进来的函数了\r\n if (env_->tick_callback_function()->Call(process, 0, nullptr).IsEmpty()) {\r\n env_->tick_info()->set_has_thrown(true);\r\n failed_ = true;\r\n }\r\n}\r\n```\r\n\r\n可知`InternalCallbackScope::Close()`会调用它，而`InternalCallbackScope::Close()`则在文件node.cc的`InternalMakeCallback()`中被调用\r\n```C++\r\nMaybeLocal InternalMakeCallback(Environment* env,\r\n Local