本作品采用知识共享署名 4.0 国际许可协议进行许可。转载保留声明头部与原文链接https://luzeshu.com/blog/nodesource2
本博客同步在https://cnodejs.org/topic/56e3be21f5d830306e2f0fd3
本博客同步在http://www.cnblogs.com/papertree/p/5225201.html
2.1 项目代码结构
node 主要的部分有4个【下图最左列就是node项目源码（4.2.2）的根目录】：
1. 原生 js模块：node提供给 用户js 代码的类接口，平时用的require('fs')、require('http')调用的都是这部分的代码。【最左列的 lib文件夹，展开后是左二列】
2. node 源码：node程序的main函数入口；还有提供给lib模块的C++类接口。【最左列的 src 文件夹，展开后是第三列】
3. v8引擎：node用来解析、执行js代码的运行环境。【最左列的deps文件夹展开后是第四列，v8和libuv等依赖都放在这里】
4. libuv：事件循环库，提供最底层的 io操作接口（包括网络io操作的epoll_wait()、文件异步io的线程池管理）、事件循环逻辑。 【第四列的uv文件夹，展开后是第五列】
记住这几个路径：
./lib
./src
./deps/uv
图2-1-1
2.2 运行流程
下图4个红色序号分别对应着上篇博客提出的4个问题所在位置。后续博客分说。
接下来对一些关键地方进行说明：
1. 核心数据结构 default_loop_struct （结构体为struct uv_loop_s，后续祥讲）
这个数据结构是事件循环的核心。当node执行到“加载js文件”这个步骤（结合下图）时，用户的js代码如果有io操作：
那么js代码通过调用 -》lib模块（2.1 中的原生js模块）-》C++模块（2.1中的源码部分） -》 libuv接口（2.1中deps/uv部分） -》最终的系统api，拿到系统返回的一个fd（文件描述符），和 js代码传进来的回调函数callback，封装成一个io观察者（一个uv__io_s类型的对象），保存到default_loop_struct；
2. 进入事件循环
当处理完 js代码，如果有io操作，那么这时default_loop_struct是保存着对应的io观察者的。
处理完js代码，main函数继续往下调用libuv的事件循环入口uv_run()，node进程进入事件循环：
uv_run()的while循环做的就是一件事，判断default_loop_struct是否有存活的io观察者。
a. 如果没有io观察者，那么uv_run()退出，node进程退出。
b. 而如果有io观察者，那么uv_run()进入epoll_wait()，线程挂起等待，监听对应的io观察者是否有数据到来。有数据到来调用io观察者里保存着的callback（js代码），没有数据到来时一直在epoll_wait()进行等待。
这里解答了博客（一）的“问题2”的一部分：为什么console.log()的js代码导致node退出，而server.listen(80)导致线程挂起等待。
3. 这里一旦没搞清逻辑就有个疑问：
第2点说在uv_run()里面如果监听的io观察者有数据到来，那么调用对应的callback，执行js代码。如果没有数据到来，一直在epoll_wait()等待。那如果我js代码里面有新的 io操作想要交给epoll_wait()进行监听，而此刻监听着的io观察者又没有数据到来，线程一直在这里等待，那怎么办？
首先第1点讲到，执行js代码的时候，通过调用node提供的C++接口最终把io观察者都保存到default_loop_struct里面，js代码执行完之后，node继续运行才进入epoll_wait()等待。也就是说node在epoll_wait()的时候，js代码执行完毕了。而js代码的回调函数部分，本来的设定就是在epoll_wait()监听的io观察者被触发之后才会执行回调，在epoll_wait()进行等待的时候，不可能存在“有新io操作要交给epoll_wait()去监听”这样的js代码。
图2-2-1