JS浏览器事件循环机制

进程、线程

进程是系统分配的独立资源，是 CPU 资源分配的基本单位，进程是由一个或者多个线程组成的。

线程是进程的执行流，是CPU调度和分派的基本单位，同个进程之中的多个线程之间是共享该进程的资源的。

浏览器内核

浏览器是多进程的，浏览器每一个 tab 标签都代表一个独立的进程（也不一定，因为多个空白 tab 标签会合并成一个进程），浏览器内核（浏览器渲染进程）属于浏览器多进程中的一种。

浏览器内核有多种线程在工作。

GUI 渲染线程:

负责渲染页面，解析 HTML，CSS 构成 DOM 树等，当页面重绘或者由于某种操作引起回流都会调起该线程。
和 JS 引擎线程是互斥的，当 JS 引擎线程在工作的时候，GUI 渲染线程会被挂起，GUI 更新被放入在 JS 任务队列中，等待 JS 引擎线程空闲的时候继续执行。

JS 引擎线程:

单线程工作，负责解析运行 JavaScript 脚本。
和 GUI 渲染线程互斥，JS 运行耗时过长就会导致页面阻塞。

事件触发线程:

当事件符合触发条件被触发时，该线程会把对应的事件回调函数添加到任务队列的队尾，等待 JS 引擎处理。

定时器触发线程:

浏览器定时计数器并不是由 JS 引擎计数的，阻塞会导致计时不准确。
开启定时器触发线程来计时并触发计时，计时完成后会被添加到任务队列中，等待 JS 引擎处理。

http 请求线程:

http 请求的时候会开启一条请求线程。
请求完成有结果了之后，将请求的回调函数添加到任务队列中，等待 JS 引擎处理。

JavaScript 引擎是单线程

JavaScript 引擎是单线程，也就是说每次只能执行一项任务，其他任务都得按照顺序排队等待被执行，只有当前的任务执行完成之后才会往下执行下一个任务。

HTML5 中提出了 Web-Worker API，主要是为了解决页面阻塞问题，但是并没有改变 JavaScript 是单线程的本质。了解 Web-Worker。

JavaScript 事件循环机制

JavaScript 事件循环机制分为: 浏览器和 Node 事件循环机制，
两者的实现技术不一样:
浏览器 Event Loop 是 HTML 中定义的规范，
Node Event Loop 是由 libuv 库实现。

这里主要讲的是浏览器部分。

Javascript 有一个 main thread 主线程和 call-stack 调用栈(执行栈)，所有的任务都会被放到调用栈等待主线程执行。

JS 调用栈

JS 调用栈是一种后进先出的数据结构。当函数被调用时，会被添加到栈中的顶部，执行完成之后就从栈顶部移出该函数，直到栈内被清空。

同步任务、异步任务

JavaScript 单线程中的任务分为同步任务和异步任务。

同步任务会在调用栈中按照顺序排队等待主线程执行，
异步任务则会在异步有了结果后将注册的回调函数添加到任务队列(消息队列)中等待主线程空闲的时候，也就是栈内被清空的时候，被读取到栈中等待主线程执行。
任务队列是先进先出的数据结构。

Event Loop

调用栈中的同步任务都执行完毕，栈内被清空了，
就代表主线程空闲了，
这个时候就会去任务队列中按照顺序读取一个任务放入到栈中执行。每次栈内被清空，都会去读取任务队列有没有任务，有就读取执行，一直循环读取-执行的操作，就形成了事件循环。

定时器

定时器会开启一条定时器触发线程来触发计时，定时器会在等待了指定的时间后将事件放入到任务队列中等待读取到主线程执行。

定时器指定的延时毫秒数其实并不准确，因为定时器只是在到了指定的时间时将事件放入到任务队列中，必须要等到同步的任务和现有的任务队列中的事件全部执行完成之后，才会去读取定时器的事件到主线程执行，中间可能会存在耗时比较久的任务，那么就不可能保证在指定的时间执行。

宏任务(macro-task)、微任务(micro-task)

除了广义的同步任务和异步任务，JavaScript 单线程中的任务可以细分为宏任务和微任务。

macro-task包括：script(整体代码), setTimeout, setInterval, setImmediate, I/O, UI rendering。

micro-task包括：process.nextTick, Promises, Object.observe, MutationObserver。

console.log(1);
setTimeout(function() {
    console.log(2);
})
var promise = new Promise(function(resolve, reject) {
    console.log(3);
    resolve();
})
promise.then(function() {
    console.log(4);
})
console.log(5);

示例中，setTimeout 和 Promise被称为任务源，来自不同的任务源注册的回调函数会被放入到不同的任务队列中。

有了宏任务和微任务的概念后，那 JS 的执行顺序是怎样的？是宏任务先还是微任务先？

第一次事件循环中，JavaScript 引擎会把整个 script 代码当成一个宏任务执行，执行完成之后，再检测本次循环中是否存在微任务，存在的话就依次从微任务的任务队列中读取执行完所有的微任务，再读取宏任务的任务队列中的任务执行，再执行所有的微任务，如此循环。JS 的执行顺序就是每次事件循环中的宏任务-微任务。

上面的示例中，第一次事件循环，整段代码作为宏任务进入主线程执行。
遇到了 setTimeout ，就会等到过了指定的时间后将回调函数放入到宏任务的任务队列中。
遇到 Promise，将 then 函数放入到微任务的任务队列中。
整个事件循环完成之后，会去检测微任务的任务队列中是否存在任务，存在就执行。

第一次的循环结果打印为: 1,3,5,4。

接着再到宏任务的任务队列中按顺序取出一个宏任务到栈中让主线程执行，那么在这次循环中的宏任务就是 setTimeout 注册的回调函数，执行完这个回调函数，发现在这次循环中并不存在微任务，就准备进行下一次事件循环。
检测到宏任务队列中已经没有了要执行的任务，那么就结束事件循环。
最终的结果就是 1,3,5,4,2。

node.js的Event Loop

Node.js也是单线程的Event Loop，但是它的运行机制不同于浏览器环境。浏览器的Event loop是在HTML5中定义的规范，而node中则由libuv库实现。

node.js运行机制：

1.v8引擎解析JavaScript脚本。

2.解析后的代码，调用Node API。

3.libuv库负责Node API的执行。它将不同的任务分配给不同的线程，形成一个Event Loop（事件循环），以异步的方式将任务的执行结果返回给V8引擎。

4.V8引擎再将结果返回给用户。

node只是在应用层属于单线程，底层其实通过libuv维护了一个阻塞I/O调用的线程池。

JS之所以可以在执行异步操作时可以设置好callback函数之后，就继续执行后续代码，当异步操作执行完成时，又能够及时触发回调函数，获取异步结果。最关键的核心就在于事件循环。

在进程启动时，Node便会创建一个类似于while(true)的循环，每执行一次循环体的过程被称为tick，中文翻译应该意为“滴答”，就像时钟一样，每滴答一下，就表示过去了1s。

Tick:

这个tick也有点这个意思，每循环一次，都表示本次tick结束，下次tick开始。
每个tick开始之初，都会检查是否有事件需要处理，
如果有，就取出事件及关联的callback函数，如果存在有关联的callback函数，就把事件的结果作为参数调用这个callback函数执行。
如果不在有事件处理，就退出进程。

那么在每个tick的过程中，如何判断是否有事件需要处理，先要引入一个概念，叫做“观察者”（watcher）。每一个事件循环都有一个或者多个观察者，判断是否有事件要处理的过程就是向这些观察者询问是否有需要处理的事件

Node的观察者有这样几种：

idle观察者：顾名思义，就是早已等在那里的观察者，以后会说到的process.nextTick就属于这类

I/O观察者：顾名思义，就是I/O相关观察者，也就是I/O的回调事件，如网络，文件，数据库I/O等

check观察者：顾名思义，就是需要检查的观察者，后面会说到的setTimeout/setInterval就属于这类

事件循环是一个典型的生产者/消费者模型。
异步I/O，网络请求，setTimeout等都是典型的事件生产者，源源不断的为Node提供不同类型的事件，这些事件被传到对应的观察者那里，事件循环在每次tick时则从观察者那里取出事件并处理。

我们现在知道，JavaScript的异步I/O调用过程中，回调函数并不由我们开发者调用，
事实上，在JavaScript发起调用到内核执行完I/O操作的过程中，

存在一种中间产物，它叫做请求对象

这个请求对象会重新封装回调函数及参数，并做一些其他的处理。这个请求对象，会在异步事件完成时被调用，取出回调函数和参数，并传入执行结果进行回调。

组装好请求对象，送入I/O线程池等待执行

实际上只是完成了异步I/O的第一步；
第二步则是异步I/O被线程池处理结束后的回调，也就是执行回调。

因为事件循环的逻辑就是这样，这里就不手工再重新绘制一张异步I/O流程图，直接把朴老师书里面的图贴上来给大家看。

应该说，事件循环、观察者、请求对象、I/O线程池，这四者共同组成了Node异步I/O模型的基本要素。

总结

根据源码分析图，可以请求出得出这样几个结论：

1、每次tick都会检查所有完成的回调事件，并一一执行回调函数。

2、跑完当前执行环境下能跑完的代码。每一个事件消息都被运行直到完成为止，在此之前，任何其他事件都不会被处理。这和C等一些语言不通，它们可能在一个线程里面，函数跑着跑着突然停下来，然后其他线程又跑起来了。JS这种机制的一个典型的坏处，就是当某个事件处理耗时过长时，后面的事件处理都会被延后，直到这个事件处理结束，在浏览器环境中运行时，可能会出现某个脚本运行时间过长，页面无响应的提示。Node环境则可能出现大量用户请求被挂起，不能及时响应的情况。

3、不同类型的观察者，处理的优先级不同，idle观察者最先，I/O观察者其次，check观察者最后。