是什么：

event loop它最主要是分三部分：主线程、宏队列（macrotask）、微队列（microtask）

js的任务队列分为同步任务和异步任务，所有的同步任务都是在主线程里执行的，异步任务可能会在macrotask或者microtask里面

主线程

就是访问到的script标签里面包含的内容，或者是直接访问某一个js文件的时候，里面的可以在当前作用域直接执行的所有内容（执行的方法，new出来的对象等）

宏队列（macrotask）

setTimeout、setInterval、setImmediate、I/O、UI rendering

微队列（microtask）

promise.then、process.nextTick（Node里的）、MutationObserver

执行顺序

1、先执行主线程

2、遇到宏任务（macrotask）放到宏任务队列（macrotask）

3、遇到微任务（microtask）放到微任务队列（microtask）

4、主线程执行完毕

5、执行微任务队列（microtask），微任务队列（microtask）执行完毕

6、执行一次宏任务队列（macrotask）中的一个任务，执行完毕

7、执行微任务队列（microtask），执行完毕

8、依次循环。。。

为什么：

javascript从诞生之日起就是一门 单线程的非阻塞的 脚本语言，单线程意味着，javascript代码在执行的任何时候，都只有一个主线程来处理所有的任务，非阻塞靠的就是 event loop（事件循环）。

怎么做：

例子：

console.log(1)
process.nextTick(() => {
  console.log(8)
  setTimeout(() => {
    console.log(9)
  })
})
setTimeout(() => {
  console.log(2)
  new Promise(() => {
    console.log(11)
  })
})
requestIdleCallback(() => {
  console.log(7)
})
// 特殊说明： new Promise（）属于主线程任务
let promise = new Promise((resolve,reject) => {
  setTimeout(() => {
    console.log(10)
  })
  resolve()
  // 这个console也属于主线程任务
  console.log(4)
})
fn()
console.log(3)
promise.then(() => {
  console.log(12)
})
function fn(){
  console.log(6)
}

结果是1、4、6、3、12、8、2、11、10、9、7

这个写法可以囊括80%以上的event loop循环机制的场景了，下面开始梳理具体的运行机制。

js是从上到下执行的，所以上来先打印的是 1 ，继续往下走；

遇见了process.nextTick,因为它属于微队列（microtask），并且当前主线程的代码还没有执行完毕，所以它被展示扔到了微队列里，暂时不打印；

这个时候又遇到了setTimeout，setTimeout是属于宏队列（macrotask）；

requestIdleCallback，这里也是不立即执行的，它也不属于任何队列，这里不做详细解释；

promise在实例化的时候，这里的setTimeout继续被丢到了宏队列（macrotask）中，并执行了成功的方法，在有promise.then的调用的时候就会去出发，但这里不做打印，接着发现了console，这里直接打印 4 ）；

fn函数直接调用，直接打印 6 ；

console，直接打印 3 ；

promise.then因为它属于微队列，但是它在promise实例化的时候被调用了，所以它会在微队列的最前面执行；

到这里主线程里面就没有任何可以执行到东西了，下面开始走微队列（microtask）：

由于promise.then被提前调用了，所以它会先执行，打印 12 ；

微队列（microtask）里面还有一个，就是上面的process.nextTick，执行它，打印 8 ，这个时候发现它有一个setTimeout，放到宏队列（macrotask）；

到这里微队列就走完了，下面开始走宏队列（macrotask）：

最外面的setTimeout在一开始的时候被放了进去，所以先执行它，打印 2 ，发现它里面有promise被实例化，直接执行，打印 11 ；

下一个要走的就是promise里面的setTimeout，打印 10 ；

还剩最后一个setTimeout，就是process.nextTick里面的，打印 9 ；

到这里主线程、宏队列（macrotask）、微队列（microtask）就全都跑完了，在全部跑完的时候，requestIdleCallback才会执行，打印 7 ；

requesIdleCallback会在当前浏览器空闲时期去依次执行，在整个过程当中你可能添加了多个requestIdleCallback，但是都不会执行，只会在空闲时期，去依次根据调用的顺序就执行。

注意点：

1 SetImmediate （该特性是非标准的，请尽量不要在生产环境中使用它！目前只有最新版本的 Internet Explorer 和Node.js 0.10+实现了该方法。）

setImmediate()是将事件插入到事件队列尾部，主线程和事件队列的函数执行完成之后立即执行setImmediate指定的回调函数，和setTimeout(fn,0)的效果差不多，但是当他们同时在同一个事件循环中时，执行顺序是不定的。

2 Mutation events 是在 DOM3中定义，用于监听DOM树结构变化的事件

它简单的用法如下：

document.getElementById('list').addEventListener("DOMSubtreeModified", function(){
  console.log('列表中子元素被修改');
}, false);

Mutation 事件列表

DOMAttrModified
DOMAttributeNameChanged
DOMCharacterDataModified
DOMElementNameChanged
DOMNodeInserted
DOMNodeRemoved
DOMNodeInsertedIntoDocument
DOMSubtreeModified

其中DOMNodeRemoved，DOMNodeInserted 和 DOMSubtreeModified 分别用于监听元素子项的删除，新增，修改(包括删除和新增），
DOMAttrModified 是监听元素属性的修改，并且能够提供具体的修改动作。

Mutation Events遇到的问题

浏览器兼容性问题
IE9不支持Mutation Events
Webkit内核不支持DOMAttrModified特性，
DOMElementNameChanged和DOMAttributeNameChanged 在Firefox上不被支持。
性能问题
1.Mutation Events是同步执行的，它的每次调用，都需要从事件队列中取出事件，执行，然后事件队列中移除，期间需要移动队列元素。如果事件触发的较为频繁的话，每一次都需要执行上面的这些步骤，那么浏览器会被拖慢。
2.Mutation Events本身是事件，所以捕获是采用的是事件冒泡的形式，如果冒泡捕获期间又触发了其他的MutationEvents的话，很有可能就会导致阻塞Javascript线程，甚至导致浏览器崩溃。

Mutation Observer

Mutation Observer 是在DOM4中定义的，用于替代 mutation events 的新API，它的不同于events的是，所有监听操作以及相应处理都是在其他脚本执行完成之后异步执行的，并且是所以变动触发之后，将变得记录在数组中，统一进行回调的，也就是说，当你使用observer监听多个DOM变化时，并且这若干个DOM发生了变化，那么observer会将变化记录到变化数组中，等待一起都结束了，然后一次性的从变化数组中执行其对应的回调函数。

js事件循环机制-简介