javascript单线程，异步与执行机制

js的单线程模型与游览器的进程/线程息息相关，在了解js单线程与异步的时候，建议先看看这篇文章

为何是单线程

• 因为js是可操做dom的，若是js是多线程，在多线程的交互下，处于界面中的dom节点就可能成为一个临界资源。
• 这个时候，若是两个线程同时操做一个dom，一个负责修改，一个负责删除，这时就会出现问题。
• 虽然能够经过锁来解决上面的问题，但为了不由于引入了锁而带来更大的复杂性，js在最初就选择了单线程。

为何须要异步

• 因为js是可操纵dom的，若是在修改这些dom的同时渲染界面（即js线程和gui线程同时运行），那么渲染线程先后得到的元素数据就可能不一致了。
• 为了防止渲染出现不可预期的结果，浏览器将gui线程与js引擎线程设置为互斥关系，当js引擎执行时，gui线程会被挂起，等到js引擎线程空闲时才会被执行。
• 因此，若是js执行时间过长（同步ajax），就会让页面卡死，形成渲染阻塞。所以，js的异步特性就显得颇有必要了。

如何实现异步

• 经过事件驱动机制，来实现异步任务等待，同步任务先执行。
• 当js主线程执行完同步任务后，再自动去拿留待的异步任务去执行。

异步编程模型

• 传统异步回调的问题
  • 代码可读性
  • 流程控制
  • 异常和错误处理
• 异步编程的变革
  • Promise
  • Generator
  • Async/await

执行机制

• js执行涉及主线程和执行栈，全部的程序任务都会被放到执行栈中被主线程执行。
• js执行采用后进先出的原则。当函数执行的时候，会被添加到栈的顶部；当执行栈执行完后，就会从栈顶被移出，直到栈内被清空。
• 主线程执行，由js引擎线程负责；事件队列，由事件触发线程管理。

事件驱动机制

• 事件驱动机制（event driven）经过事件队列（event queue）和事件循环（event loop）来实现。
• 事件队列（event queue），也称消息队列/任务队列，由异步I/O操做发起，里面存放着各类事件消息，这些消息都关联着回调函数。
• 事件循环（event loop），是指js主线程重复从消息队列中取消息、执行的过程。
• 模型图示

任务类型

• 从执行时机的角度
  • 同步任务，存放在执行栈中，会被主线程依次执行的任务
  • 异步任务，存放在事件队列中，会在异步操做有告终果后，将注册回调放入这个队列，等待主线程空闲时，被拉取到执行栈中执行。（空闲时，意味着同步任务已被执行完，执行栈为空了）
• 从提供者的角度
  • 宏任务（macrotask），由宿主环境提供——全局script，setTimeout，setInterval，setImmediate，I/O，UI rendering，postMessage，MessageChannel
  • 微任务（microtask），由语言标准提供——Promise.then，process.nextTick，Object.observe(已废弃)，MutationObserver

任务机制

• 全部同步任务在执行完以前，任何的异步任务是不会执行的。

console.log("A");
setTimeout(function(){
   console.log("B");
},0);
while(true){}
// 结果为A。由于同步任务被死循环卡住了，任务队列里的任务不会被主线程拉取进执行栈

• 每执行一个宏任务后，就会执行全部微任务。

• 为了使js任务与dom任务可以有序执行，会在一个task执行结束后，在下一个task执行开始前，对页面进行从新渲染 （task(宏->微)->render->task(宏->微)-->...）

宏任务/微任务拓展

• 1个事件循环中，宏任务能够有多个，微任务只有1个。
• 以银行排号为例，1个柜台对应多个用户，每一个用户都是1个宏任务，当用户办完(宏)主任务后，忽然想到要办理不少(微)次任务，银行柜员会一次帮他解决全部需求，而不是让他从新排队
• 程序模型图示

• 执行机制详述

1. 执行一个宏任务，主栈中没有就从事件队列中获取。
2. 执行过程当中若是遇到微任务，就将它添加到微任务的任务队列中。
3. 宏任务执行完毕后，当即依次执行当前微任务队列中的全部微任务。
4. 当微任务执行完毕，开始检查渲染，而后gui线程接管渲染。
5. 渲染完毕后，js线程继续接管，开始下一个宏任务。

console.log('1');
setTimeout(function() {
    console.log('5');
    Promise.resolve().then(function() {
        console.log('6');
    })
}, 0);
Promise.resolve().then(function() {
    console.log('3');
}).then(function() {
    console.log('4');
});
console.log('2');

// 1，2，3，4，5，6
// 第一轮任务中，宏任务为全局script（恰好处于执行栈内，不用在事件队列中取），因此先是1，2；
// 同时，因为执行过程当中遇到了setTimeout，将其再放入宏任务队列，遇到了promise，将其放入微任务队列；
// 该轮宏任务执行完毕后，开始执行微任务，将微任务所有取出，一次执行，所以再是3，4；
// 开始第二轮任务，取出的宏任务为setTimeout回调，所以结果是5；
// 同时执行这轮宏任务回调时，又遇到promise，再将其放入微任务队列；
// 当这轮宏任务setTimeout回调结束后，当即刚才加入的微任务取出执行，所以结果为6；

• api优先级顺序
  • html5新特性MutationObserver属于微任务，优先级小于Promise
  • html5新特性MessageChannel属于宏任务，优先级是：setImmediate->MessageChannel->setTimeout。
  • 在node环境的微任务执行中，process.nextTick的优先级高于promise。
  • 在node环境的宏任务执行中，setImmediate的优先级高于setTimeout。
• Vue.nextTick实现
  • 2.4版本时，Vue经过利用MutationObserver来模拟nextTick（MutationObserver为H5新特性，用于监听一个dom变更， 当dom对象树发生任何变更时，Mutation Observer会获得通知）
  • 2.5版本开始，nextTick实现移除了MutationObserver的方式（兼容性缘由）， 取而代之的是使用MessageChannel （固然，默认状况仍然是Promise，不支持才兼容的）
  • 因为，js执行是单线程，在一个tick的过程当中，可能会存在屡次修改数据，vue会把这些数据修改先统一push到一个队列里，而后内部调用1次nextTick去更新视图。
  • 所以，vue从数据改变到dom视图变化是须要在下一个tick才能完成的，这种数据驱动变化的原理符合游览器的原理（js引擎线程和gui渲染互斥）和处理策略（task(宏->微)->render->task(宏->微)-->...）
  • 最终，Vue.nextTick采起的策略是默认走 microtask，对于一些dom交互事件，如v-on绑定的事件回调函数的处理，会强制走macrotask。对于macrotask的执行，vue优先检测是否支持原生setImmediate（高版本游览器支持），不支持的话再去检测是否支持原生的MessageChannel，若是也不支持的话就会降级为setTimeout 0。

参考

• http://www.javashuo.com/article/p-ffewwzss-bq.html
• http://www.imweb.io/topic/58e3bfa845e5c13468f567d5
• http://www.cnblogs.com/mininice/p/4298952.html
• http://www.javashuo.com/article/p-cmtsxzha-h.html
• http://www.dailichun.com/2018/01/21/js_singlethread_eventloop.html
• http://www.javashuo.com/article/p-xackczmh-cr.html