Event Loop

Event Loop模式

Event Loop模式

什么是同步、异步、阻塞、非阻塞？

如果所有的调用都是立即返回结果，不存在执行等待（I/O通信->执行等待，资源等待->服务挂起），就不需要异步和阻塞。
同步/异步：主要体现在调用方发起请求后，是自己主动探查结果反馈（同步），还是被动由服务提供方告知反馈结果（异步）。
阻塞/非阻塞：主要体现在调用方发起请求后，在等待结果反馈期间，是原地不动（阻塞），还是统筹时间干别的事情去（非阻塞）。

消息通信机制层面理解：同步 or 异步

同步：调用方调用，调用方主动询问。（调用方一会儿一问：“完事没啊？”）

异步：调用方调用，返回结果以（回调callback、状态或者通知）方式由服务提供方告知调用方。（调用方：“完事告诉我哈！”）

程序调用层面理解：阻塞 or 非阻塞

阻塞：调用方的线程request在等待反馈结果期间被挂起（啥也不干了），调用方得到response，再唤醒被挂起的线程，该唤醒过程可能是服务提供方以回调的方式唤醒的。（调用方：“啥也不干，干等你！”）

非阻塞：调用方的线程request在等待结果期间不会被挂起（可以干别的），直到response后才返回。（调用方：“老子忙别的去了！”）

同步阻塞I/O：调用方请求后，一直等待结果，不干别的。
同步非阻塞I/O：调用方请求后，一边去吃鸡了（干别的事儿），一边不断询问（完事儿没）。
异步阻塞I/O：调用方请求后，也不干别的，也不询问。服务提供方完成之后，主动告知调用方。
异步非阻塞I/O：调用方请求后，万事大吉，一边去吃鸡了（干别的事儿）。服务提供方完成之后，主动告知调用方。

操作系统层面理解：同步 or 异步，阻塞 or 非阻塞

同步：应用层向系统内核发起请求，不断盲目询问：“完事儿没？”，直到完事儿了。

异步：应用层向系统内核发起请求，走了不管了，系统内核完成操作后主动告知应用层：“完事儿了哈！”

阻塞：应用层向系统内核发起I/O请求，被挂起，盲目傻傻等待，直到完事儿了。

非阻塞：应用层向系统内核发起I/O请求，干别的去了。

操作系统I/O模型演进：

阻塞I/O：一直干等！
同步非阻塞 IO：频繁询问！
IO 多路复用：分为预备和执行，不是上了就做发现原材料不对（数据没有就绪）在停下来，而是先看看那些可以做（数据就绪啦已经！）谋定而后动，知止而有得！检查数据是否就绪借助描述符。

如何理解I/O多路复用？

I/O（网络I/O），多路（多个socket连接），复用（指操作系统进行运算调度的最小单位线程）。
整体意思也就是多个网络 I/O 复用一个或少量的线程来处理 Socket。

I/O 多路服用有多种实现模式：select、 poll、 epoll、 kqueue

select：通过轮询检查在文件描述符上设置的标识位来进行判断，select 的轮询相当于在数据库中查找一条记录没有建立索引，对所有的 socket 进行全部遍历，这对 CPU 是浪费的。另外 select 还有一个限制，对于单个进程所能打开的文件描述符最大只能是 1024，那么基于 select 的轮询技术最多也只能很好的处理 1000 并发的吞吐量，可以查看上一个10年，著名的C10K并发连接问题。
poll: 和 select 在实现上没有本质的区别，相比较 select，poll 基于链表来实现，没有了最大链接 1024 的限制。但是当文件描述符多了之后，每次调用都会对链接进行线性遍历，性能还是十分低下的。
epoll：是 linux 下效率最高的 I/O 事件通知机制，没有最大链接限制，通过 callback 回调通知机制，不在是每次调用都对链接进行线性遍历，这样就不会随着文件描述符的增加导致效率下降。在 1GB 内存的机器上能监听大约 10 万个端口，远超过 select 的 1024 限制，具体可以在服务器上查看 cat/proc/sys/fs/file-max。（select 采用了线性遍历来查找，链接多了之后可以想象一下在一个诺大的数组中每次通过遍历来锁定一个链接，是多么的消耗性能。epoll 则不需要遍历，采用的是回调机制，可以看作一个 HashTable，来锁定一个对象是很快的。）
kqueue：与 epoll 类似，仅存于 FreeBSD（一种类UNIX操作系统）。

信号驱动 IO：从轮询查看数据是否就绪（I/O多路复用）变为消息异步通讯。你好了你再告诉我，给我个信号就行啦！

仅在 Unix 上支持，与 I/O 多路复用相比避免了 select 的阻塞轮询。

异步 IO 模型：异步 I/O 模型是目前最理想的一种形式，应用程序发起系统调用后无需等待直接返回当前调用状态，进行后续的其它任务，结果由内核完成 I/O 操作之后通过回调通知到我们的应用程序，中间没有阻塞过程。

信号驱动 IO 里面数据准备好了回调通知我，我还得再发布执行动作去把数据从内核中拷贝出来（recvfrom），太麻烦啦！干脆内核你直接把事情做完，告诉我结果就ok啦！
在 Linux2.6 之后增加了异步 I/O 的实现方式 AIO，但是很少系统能够实现。

什么是Event Loop模式？事件轮询。

运行的程序->进程。
一般一个进程执行一个任务。
多任务时：可以使用队列（延迟处理->时效性问题）、fork进程（分出去大家一起处理->资源问题）或多线程去执行（内部协调处理->并发问题）。
Event Loop是一个程序结构，用于等待和发送消息和事件。
简单理解：程序中设置两个线程，一个负责程序本身运行（主线程）。另一个负责主线程与其他进程（主要是各种I/O操作）的通信，被称为EventLoop线程（消息线程）。每当遇到I/O的时候，主线程就让Event Loop线程去通知相应的I/O程序，然后接着往后运行，所以不存在阻塞等待时间。等到I/O程序完成操作，Event Loop线程再把结果返回主线程。主线程就调用事先设定的回调函数，完成整个任务。（Event Loop相当于是主线程的小弟，专门负责不能及时返回处理结果的任务，事件轮询感觉就像大哥让小弟去派发任务的过程。）
所以，Event Loop模式是异步模式(完事告诉我哈！)、非阻塞模式(老子忙别的去了！)，大哥风范。（应用：js、Redis服务器）

JS中EventLoop应用

在JS中，事件轮询是 JS 实现异步的具体解决方案，同步代码直接执行，异步函数或代码块先放在异步队列中，待同步函数执行完毕，轮询执行异步队列的函数。
当触发一个事件时，相应的这个事件会进入到一个 EventLoop 队列中。
检查 EventLoop 中是否存在事件消息，如果消息存在则会触发相应的回调。
处理完成回调中的操作，就会返回到步骤 2 进行下一次 EventLoop。

EventLoop与Poll的关系？

Node.js 官网提供的说明，这是一次事件循环所经历的六个阶段，这些阶段也是按照顺序依次执行的，在以下阶段中，每个阶段都会有一个先进先出的回调函数队列，只有当前阶段的回调函数队列清空了，才会进入到下一个阶段。
┌───────────────────────────┐
┌─>│ timers │
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
│ │ pending callbacks │
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
│ │ idle, prepare │
│ └─────────────┬─────────────┘ ┌───────────────┐
│ ┌─────────────┴─────────────┐ │ incoming: │
│ │ poll │<─────┤ connections, │
│ └─────────────┬─────────────┘ │ data, etc. │
│ ┌─────────────┴─────────────┐ └───────────────┘
│ │ check │
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
└──┤ close callbacks │
└───────────────────────────┘
timers 定时器（轮询频度掌控）
pending callbacks（通讯异常回调挂起）
idle, prepare（该阶段仅系统内部（libuv）调用）
poll（检索新的 I/O 事件;执行与 I/O 相关的回调（几乎所有情况下，除了关闭的回调函数，setImmediate() 之外），其余情况 node 将在此处阻塞。）
check（setImmediate() 回调函数在这里执行。）
close callbacks（一些准备关闭的回调函数，如：socket.on(‘close’, …)）

Reference

https://www.cnblogs.com/xueqiuqiu/articles/12884004.html（事件轮询(Event Loop)）
https://blog.csdn.net/qq_36380426/article/details/103545219（【面试题】440- 10 道 Nodejs EventLoop 和事件相关面试题）
https://mp.weixin.qq.com/s?__biz=MzIyNDU2NTc5Mw%3D%3D&idx=1&mid=2247483840&scene=21&sn=c050d8e1b40573b3605cace901ac3380#wechat_redirect（I/O 模型如何演进及 I/O 多路复用是什么？）
https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/（What is the Event Loop?官网）
https://www.cnblogs.com/howo/p/7956436.html（I/O复用）

原文链接：https://blog.csdn.net/GZHarryAnonymous/article/details/118465139