node中异步IO的理解

解释性语言和编译型语言的区别：

计算器不能直接的理解高级语言，只能理解机器语言，所以必须把高级语言翻译为机器语言，翻译的方式有两种，一个是编译，一个是解释。

解释性语言的程序不需要编译，它是在运行程序的时候进行翻译，比如java，专门有一个解释器可以直接执行Java程序，每一个语句都是执行的时候才能翻译，编译型就是编译的时候直接编译成机器可以执行的，编译和执行时分开的，但是不能跨平台。因为翻译只做了一次，运行的时候不需要再去翻译，所以编译型语言的程序执行效率高。

对于解释性语言，程序运行时的控制权在解释器而不在于程序，对于编译型语言程序运行时的控制权在程序。

进程的前台运行和后台运行

后台进程是一直运行的服务端程序，又称为守护进程，通常是在系统后台运行，没有控制终端，不与前台交互，一般作为系统服务使用。其称为后台进程的原因大部分是因为它没有控制端，无法和前台的用户交互。

相对应的前台进程，就是我们在终端中开启的进程，例如我们在终端中npm run server.js启动一个webServer，此时启动的进程就是前台进程，当你把当前的命令行终端进行关闭了之后，该进程也便被杀死了。

node中的阻塞/非阻塞IO和同步/异步IO

表面上来看，这两组的概念都差不多，阻塞/非阻塞IO，是操作系统内核对于IO的两种处理方式，对于阻塞IO，比如读取文件，操作系统在读取完文件之后，才会给应用程序返回结果，这一段过程呢，应用程序在等待操作系统的回复，是为应用层面的同步IO。

对于非阻塞IO，操作系统在接收到应用程序对于读取文件的请求时，立即返回给应用程序一个结果，但是应用程序怎么知道操作系统完成了IO操作呢？这时候应用程序就会对操作系统发起询问（你到底好了没有？人家都快急死了），发起询问的方法又经过好几种演变，比如read、poll、epoll等，中间多的无非就是根据文件描述符减少询问的次数，总体上来说这种方式不好。并不能达到我们理想的异步IO。

那么从应用程序方面来将，我们期望的异步IO，就是应用程序进行了IO操作之后，不再需要操心操作系统什么时候返回，去执行下边的代码就行了，当操作执行完了之后呢，直接给应用程序发信息告诉他就行了。Linux系统下原生提供了一种AIO是通过信号或者回调来传递数据的，这个AIO就是我们的理想的异步IO。但是不幸的是只有Linux中有，而且无法利用系统缓存。

node（单线程）中对于*nix平台而言，采用的是线程池+epoll异步IO模拟实现应用程序层面的异步IO，主线程进行执行程序，碰到我们异步IO调用时，将改异步IO分配给线程池中的某一个线程，然后就变成了线程池中的某个线程和操作系统的阻塞IO进行IO操作，当IO线程接收到操作系统的阻塞IO执行的返回结果之后，IO线程再发送时间给主线程。

node中对于window平台而言，是依靠于IOCP来实现的，其内部仍然是线程池原理，不同之处在于这些线程池由系统内核接手管理。

node中对于异步IO的实现：

对于异步IO的实现，其中有几个组成部分：事件循环、观察者、请求对象

事件循环是node中的一种执行机制，这种机制是回调执行的基础部分，它保证了我们的回调函数能够被执行。

观察者是暴露回调函数的窗口，如果整体的场景为饮料工厂的话，我们的瓶子就是我们的回调函数，事件循环就是传送带在那一直转，而观察者就是瓶子就如机器的入口，机器就是我们的应用程序。所以应用程序从观察者这里获取事件，应用程序询问观察者是否还有事件。

请求对象，是应用程序封装的一个对象，里边包含了要做的IO操作类型，以及回调函数。

整体流程就是，异步调用开始之后，应用程序封装一个请求对象，送入我们的线程池中的某个线程，该线程和操作系统的非阻塞IO通过epoll机制进行工作，这其中，会有观察者在线程池中进行检查，当某个线程的IO操作完成之后，观察者会将回调函数（封装在请求对象中的）放在事件循环上（上段提到的传送带），然后主线程调用回调函数。

参考：《深入浅出Node.js》
问题思考：

操作系统的线程与CPU中的线程有什么不同？