本文我们将会介绍 JS 实现异步的原理，并且了解了在浏览器和 Node 中 Event Loop 其实是不相同的。
想阅读更多优质原创文章请猛戳GitHub博客
我们经常说JS 是单线程执行的，指的是一个进程里只有一个主线程，那到底什么是线程？什么是进程？
官方的说法是：进程是 CPU资源分配的最小单位；线程是 CPU调度的最小单位。这两句话并不好理解，我们先来看张图：
以Chrome浏览器中为例，当你打开一个 Tab 页时，其实就是创建了一个进程，一个进程中可以有多个线程（下文会详细介绍），比如渲染线程、JS 引擎线程、HTTP 请求线程等等。当你发起一个请求时，其实就是创建了一个线程，当请求结束后，该线程可能就会被销毁。
简单来说浏览器内核是通过取得页面内容、整理信息（应用CSS）、计算和组合最终输出可视化的图像结果，通常也被称为渲染引擎。
浏览器内核是多线程，在内核控制下各线程相互配合以保持同步，一个浏览器通常由以下常驻线程组成：
比如 setTimeout定时器计数结束， ajax等异步请求成功并触发回调函数，或者用户触发点击事件时，该线程会将整装待发的事件依次加入到任务队列的队尾，等待 JS引擎线程的执行。
浏览器端事件循环中的异步队列有两种：macro（宏任务）队列和 micro（微任务）队列。宏任务队列可以有多个，微任务队列只有一个。
一个完整的 Event Loop 过程，可以概括为以下阶段：
一开始执行栈空,我们可以把执行栈认为是一个存储函数调用的栈结构，遵循先进后出的原则。micro 队列空，macro 队列里有且只有一个 script 脚本（整体代码）。
全局上下文（script 标签）被推入执行栈，同步代码执行。在执行的过程中，会判断是同步任务还是异步任务，通过对一些接口的调用，可以产生新的 macro-task 与 micro-task，它们会分别被推入各自的任务队列里。同步代码执行完了，script 脚本会被移出 macro 队列，这个过程本质上是队列的 macro-task 的执行和出队的过程。
上述过程循环往复，直到两个队列都清空
我们总结一下，每一次循环都是一个这样的过程：
当某个宏任务执行完后,会查看是否有微任务队列。如果有，先执行微任务队列中的所有任务，如果没有，会读取宏任务队列中排在最前的任务，执行宏任务的过程中，遇到微任务，依次加入微任务队列。栈空后，再次读取微任务队列里的任务，依次类推。
接下来我们看道例子来介绍上面流程：
Promise.resolve().then(()=>{
console.log(‘Promise1‘)
setTimeout(()=>{
console.log(‘setTimeout2‘)
},0)
})
setTimeout(()=>{
console.log(‘setTimeout1‘)
Promise.resolve().then(()=>{
console.log(‘Promise2‘)
})
},0)最后输出结果是Promise1，setTimeout1，Promise2，setTimeout2
Node 中的 Event Loop 和浏览器中的是完全不相同的东西。Node.js采用V8作为js的解析引擎，而I/O处理方面使用了自己设计的libuv，libuv是一个基于事件驱动的跨平台抽象层，封装了不同操作系统一些底层特性，对外提供统一的API，事件循环机制也是它里面的实现（下文会详细介绍）。
Node.js的运行机制如下:
其中libuv引擎中的事件循环分为 6 个阶段，它们会按照顺序反复运行。每当进入某一个阶段的时候，都会从对应的回调队列中取出函数去执行。当队列为空或者执行的回调函数数量到达系统设定的阈值，就会进入下一阶段。
从上图中，大致看出node中的事件循环的顺序：
外部输入数据-->轮询阶段(poll)-->检查阶段(check)-->关闭事件回调阶段(close callback)-->定时器检测阶段(timer)-->I/O事件回调阶段(I/O callbacks)-->闲置阶段(idle, prepare)-->轮询阶段（按照该顺序反复运行）...
注意：上面六个阶段都不包括 process.nextTick()(下文会介绍)
接下去我们详细介绍timers、poll、check这3个阶段，因为日常开发中的绝大部分异步任务都是在这3个阶段处理的。
timers 阶段会执行 setTimeout 和 setInterval 回调，并且是由 poll 阶段控制的。
同样，在 Node 中定时器指定的时间也不是准确时间，只能是尽快执行。
poll 是一个至关重要的阶段，这一阶段中，系统会做两件事情
1.回到 timer 阶段执行回调
2.执行 I/O 回调
并且在进入该阶段时如果没有设定了 timer 的话，会发生以下两件事情
当然设定了 timer 的话且 poll 队列为空，则会判断是否有 timer 超时，如果有的话会回到 timer 阶段执行回调。
setImmediate()的回调会被加入check队列中，从event loop的阶段图可以知道，check阶段的执行顺序在poll阶段之后。
我们先来看个例子:
console.log(‘start‘)
setTimeout(() => {
console.log(‘timer1‘)
Promise.resolve().then(function() {
console.log(‘promise1‘)
})
}, 0)
setTimeout(() => {
console.log(‘timer2‘)
Promise.resolve().then(function() {
console.log(‘promise2‘)
})
}, 0)
Promise.resolve().then(function() {
console.log(‘promise3‘)
})
console.log(‘end‘)
//start=>end=>promise3=>timer1=>timer2=>promise1=>promise2Node端事件循环中的异步队列也是这两种：macro（宏任务）队列和 micro（微任务）队列。
二者非常相似，区别主要在于调用时机不同。
setTimeout(function timeout () {
console.log(‘timeout‘);
},0);
setImmediate(function immediate () {
console.log(‘immediate‘);
});但当二者在异步i/o callback内部调用时，总是先执行setImmediate，再执行setTimeout
const fs = require(‘fs‘)
fs.readFile(__filename, () => {
setTimeout(() => {
console.log(‘timeout‘);
}, 0)
setImmediate(() => {
console.log(‘immediate‘)
})
})
// immediate
// timeout在上述代码中，setImmediate 永远先执行。因为两个代码写在 IO 回调中，IO 回调是在 poll 阶段执行，当回调执行完毕后队列为空，发现存在 setImmediate 回调，所以就直接跳转到 check 阶段去执行回调了。
这个函数其实是独立于 Event Loop 之外的，它有一个自己的队列，当每个阶段完成后，如果存在 nextTick 队列，就会清空队列中的所有回调函数，并且优先于其他 microtask 执行。
setTimeout(() => {
console.log(‘timer1‘)
Promise.resolve().then(function() {
console.log(‘promise1‘)
})
}, 0)
process.nextTick(() => {
console.log(‘nextTick‘)
process.nextTick(() => {
console.log(‘nextTick‘)
process.nextTick(() => {
console.log(‘nextTick‘)
process.nextTick(() => {
console.log(‘nextTick‘)
})
})
})
})
// nextTick=>nextTick=>nextTick=>nextTick=>timer1=>promise1浏览器环境下，microtask的任务队列是每个macrotask执行完之后执行。而在Node.js中，microtask会在事件循环的各个阶段之间执行，也就是一个阶段执行完毕，就会去执行microtask队列的任务。
接下我们通过一个例子来说明两者区别：
setTimeout(()=>{
console.log(‘timer1‘)
Promise.resolve().then(function() {
console.log(‘promise1‘)
})
}, 0)
setTimeout(()=>{
console.log(‘timer2‘)
Promise.resolve().then(function() {
console.log(‘promise2‘)
})
}, 0)浏览器端运行结果：timer1=>promise1=>timer2=>promise2
浏览器端的处理过程如下：
Node端运行结果分两种情况：
timer1=>promise1=>timer2=>promise2timer1=>promise1=>timer2=>promise2timer1=>timer2=>promise1=>promise2(下文过程解释基于这种情况下)1.全局脚本（main()）执行，将2个timer依次放入timer队列，main()执行完毕，调用栈空闲，任务队列开始执行；
2.首先进入timers阶段，执行timer1的回调函数，打印timer1，并将promise1.then回调放入microtask队列，同样的步骤执行timer2，打印timer2；
3.至此，timer阶段执行结束，event loop进入下一个阶段之前，执行microtask队列的所有任务，依次打印promise1、promise2
Node端的处理过程如下：
浏览器和Node 环境下，microtask 任务队列的执行时机不同
文章于2019.1.16晚，对最后一个例子在node运行结果，重新修改！再次特别感谢zy445566和BuptStEve的精彩点评，由于node版本更新到11，Event Loop运行原理发生了变化，一旦执行一个阶段里的一个宏任务(setTimeout,setInterval和setImmediate)就立刻执行微任务队列，这点就跟浏览器端一致。
欢迎关注公众号：前端工匠，你的成长我们一起见证！
浏览器与Node的事件循环(Event Loop)有何区别?
原文：https://www.cnblogs.com/llxz/p/10369203.html