前言
javascript是单线程的语言，也就是说，同一个时间只能做一件事。而这个单线程的特性，与它的用途有关，作为浏览器脚本语言，JavaScript的主要用途是与用户互动，以及操作DOM。这决定了它只能是单线程，否则会带来很复杂的同步问题。比如，假定JavaScript同时有两个线程，一个线程在某个DOM节点上添加内容，另一个线程删除了这个节点，这时浏览器应该以哪个线程为准？
为了利用多核CPU的计算能力，HTML5提出Web Worker标准，允许JavaScript脚本创建多个线程，但是子线程完全受主线程控制，且不得操作DOM。所以，这个新标准并没有改变JavaScript单线程的本质
这是今天一个朋友发给我的一个面试题，
感觉还挺有意思的，
写个博客以供分享
先看看这个面试题目：
观察下面的代码，写出输出结果
console.log('0')
setTimeout(function () {
console.log('1');
});
new Promise(function(resolve,reject){
console.log('2')
resolve(3)
}).then(function(val){
console.log(val)
})
console.log(4)
输出结果： “0” “2” 4 3 “1”
今天主要是分析为什么输出结果是这样的？这就和 javascript 的执行机制密切相关了.
Event Queue 和 Event Loop
javascript 是一门单线程的语言, 这就意味着在执行代码的时候, 都只有一个主线程来处理所有的任务.
我们都知道 javascript 包括同步代码和异步代码, 那么 javascript 是怎么处理这两种情况的呢?
同步和异步任务分别进入不同的执行 场所, 同步的进入主线程，异步的进入 Event Table 并注册函数 当指定的事情完成时, Event Table 会将这个函数(回调函数)移入 Event Queue 主线程内的任务执行完毕为空, 会去 Event Queue 读取对应的函数，进入主线程执行 上述过程会不断重复, 也就是常说的 Event Loop(事件循环)这里我们引进了 Event Queue 事件队列这一概念. 所有异步操作的回调都会进入到这里. 然后等到主线程空闲, 就会从这里调取回调执行.
setTimeout
setTimeout 相信大家都有使用过, 可以延时执行并且是异步执行的.
但是有时候我们得到的结果往往是代码实际执行的时间比我们想要延时执行的时间要久。这又是为什么呢?
这就和我们之前所说的 Event Loop 有关了, 我们可以来具体看下 setTimeout 的执行步骤:
setTimeout(function () {
asyncFn()
}, 1000);
syncFn()
asyncFn 将异步执行函数放在 Event Table, 并且开始计时
开始执行 syncFn, 但是 syncFn 可能需要处理的内容很多, 执行时间超过 1 秒, 但是计时还在继续
计时到达 1 秒, setTimeout 延时完成, asyncFn 进入 Event Queue 事件队列, 但是主线程还在执行, 所以只能等待
syncFn 执行完成, 此时 asyncFn 从事件队列中进入主线程执行
所以有时候会出现代码实际执行时间比延时时间长的情况。
宏任务和微任务
之前我们说过异步任务会进入到事件队列中, 不同类型的任务会进入到不同的队列中, 比如宏任务会进入到宏任务队列中, 微任务会进入到微任务队列中.
我们只要记住 当当前执行栈执行完毕时会立刻先处理所有微任务队列中的事件，然后再去宏任务队列中取出一个事件。同一次事件循环中，微任务永远在宏任务之前执行
这时候我们就可以解释一开始的代码执行结果了:
主线程执行按顺序代码 遇到 setTimeout, 回调进入到宏任务队列上 遇到 Promise, 立即执行, then 函数进入到微任务队列 同步代码执行结束, 主线程检查是否存在微任务, 发现 then, 执行 微任务执行完毕, 再去查找宏任务 setTimeout, 执行 setTimeout 执行结束, 检查是否存在微任务, 不存在, 结束.以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对的支持。
