js中的单线程
为什么js会设计为单线程：
由于js运行的环境（浏览器）决定的，反正多个线程同时操作dom，所以js被设计成单线程，这只是说js运行的环境是单线的。如一些io操作，耗时操作，如果单纯的单线程肯定是会阻塞ui，而js是非阻塞
事件循环（EventLoop）
由于js是单线的，所以在同一时间只能执行一个任务，如果这个任务是耗时操作，js是如何做到非阻塞的呢。
从类型上，任务可以分为两种：同步任务和异步任务。
同步任务
但js引擎之执行js代码时，碰到同步任务就是直接在主线程中执行
异步任务
当js引擎在执行js代码时，碰到异步任务，肯定是不会等它执行完之后再执行其他的任务，此时是将这个异步任务放在callback queue中，当主线程任务执行完之后再去callback queue中取出任务执行。不停的重复这个过程，这个循环其实就是我们一直所说的eventLoop
异步任务也分为两种：微任务（micro task）和宏任务（macro task）
浏览器
1.js引擎执行一块代码
2.执行同步方法
3.碰到异步任务
4.根据不同的任务类型将其放在不同的队列中（micro task 与macro task）
5.当主线程代码执行完毕，再循环执行micro task中的任务
6.当micro task 队列为空时，会先冲macro task中取出一条放在micro task中，再去循环执行micro task 中的任务
7.重复5，6知道macro task与micro task 都为空
- macro task
setTimeout
setInterval
setImmediate
I/O - micor task
promise
process.nextTick
setImmediate
MutationObserver
分析几个简单的demo
setTimeout(function(){
console.log('time1')
},0);
console.log('main')
//main
//time1
说明js执行并不会阻塞，异步任务一定是在之后执行的，time会放在macor task中
timeout与promise的顺序
setTimeout(function(){
console.log('time1')
},0);
Promise.resolve().then(function(){
console.log('promise1')
})
console.log('main')
//main
//promise1
//time1
从log可以看出来，promise是先执行的，如果time跟promise是同一个callback queue的话time应该会先执行，所以time跟promise是放在2个不同的队列中
setTimeout(function(){
console.log('time1')
},0);
Promise.resolve().then(function(){
setTimeout(function(){
console.log('time2')
},0);
Promise.resolve().then(function(){
console.log('promise2')
})
console.log('promise1')
})
setTimeout(function(){
console.log('time3')
},0);
console.log('main')
//main
//promise1
//promise2
//time1
//time3
//time2
如果在promise中再执行一个time 与一个promise，分析首先js加载代码，macor task队列中是放了time1跟time3，micro task 中只有一个promise1方法，
我们在执行micro task 中的promise1时候，又发现了2个异步任务，他会重复这个操作，再次区分任务的类型 将time2放在macor task中，promise2放在，micor task中，然后执行micro task 中的promise2，再去macro task取出time执行
注意
在浏览器中，执行优先级为 同步代码 > 微任务 > 宏任务，一次性执行所有的micor task
node eventLoop
node的事件轮询与浏览器的不太一样，如图
image.png
各个阶段
node 的macro task更为复杂，microTask是串在task的各个阶段执行的。
当 Node 启动时，回初始化 Event Loop ，每个 Loop 都有六个阶段
- timers 阶段：执行 setTimeout、setInterval 的 callback 回调。
- I/O callbacks阶段：执行除了 close 事件的 callbacks 、被timers(定时器，setTimeout、setInterval 等)设定的 callbacks 、setImmediate() 设定的 callbacks 之外的 callbacks
- idle，prepare阶段：node 内部使用，Process.nextTick 在此阶段执行
- poll 阶段：获取新的 I/O 事件, 适当的条件下 node 将阻塞在这里
- check 阶段：执行 setImmediate() 的回调函数
- close callbacks 阶段：执行 close 事件的 callback ，例如 socket.on('close', callback);
setImmediate(function immediate () {
console.log('immediate');
});
setTimeout(function timeout () {
console.log('timeout');
},0);
setImmediate
setTimeout
或
setTimeout
setImmediate
- 输出不固定
setTimeout/setInterval 的第二个参数取值范围是：[1, 2^31 - 1]，如果超过这个范围则会初始化为 1，即 setTimeout(fn, 0) === setTimeout(fn, 1)。 - setTimeout 的回调函数在 timer 阶段执行
- setImmediate的回掉在check阶段
1.timer 前的准备时间超过 1ms，满足 loop->time >= 1，即time函数已经注册，times阶段事件队列不为空，则执行 timer 阶段（setTimeout）的回调函数
2.timer 前的准备时间小于 1ms，即time函数未注册完成，times阶段事件队列为空，就会进入下一个阶段，则先执行 check 阶段（setImmediate）的回调函数，下一次 event loop 执行 timer 阶段（setTimeout）的回调函数
setImmediate(function immediate () {
console.log('immediate');
});
setTimeout(function timeout () {
console.log('timeout');
},0);
var data = Date.now();
while(Date.now() - data < 2) {
}
// 结果一定是
timeout
immediate
const fs = require('fs')
fs.readFile(__filename, () => {
setTimeout(() => {
console.log('setTimeout')
}, 0)
setImmediate(() => {
console.log('setImmediate')
})
})
//
immediate
timeout
- fs 的I/O callback 执行完成 ，进入poll 阶段
- poll阶段有两个主要功能
- 执行以及到时间的定时器
- 处理轮询队列中的事件
- 此时poll为空，进入check阶段
- check执行setImmediate()
- 进入close callbacks 再进入timer
- 所以setImmediate先执行
node里面的微任务
process.nextTick ，promise在各个阶段切换的中间执行,即从一个阶段切换到下个阶段前执行
var fs = require('fs');
fs.readFile(__filename, () => {
setTimeout(() => {
console.log('setTimeout');
}, 0);
setImmediate(() => {
console.log('setImmediate');
process.nextTick(()=>{
console.log('nextTick3');
})
});
process.nextTick(()=>{
console.log('nextTick1');
})
process.nextTick(()=>{
console.log('nextTick2');
})
});
//
nextTick1
nextTick2
setImmediate
nextTick3
setTimeout
- 此时执行的顺序是 I/O -->nextTick1-->nextTick2-->poll-->check-->nextTick3-->close-->timers
setTimeout(function () {
console.log('execute in first timeout');
Promise.resolve(3).then(res => {
console.log('execute in third promise');
});
}, 0);
setTimeout(function () {
console.log('execute in second timeout');
Promise.resolve(4).then(res => {
console.log('execute in fourth promise');
});
}, 0);
Promise.resolve(1).then(res => {
console.log('execute in first promise');
});
Promise.resolve(2).then(res => {
console.log('execute in second promise');
});
node 结果
execute in first promise
execute in second promise
execute in first timeout
execute in second timeout // node 先执行
execute in third promise
execute in fourth promise
浏览器结果
execute in first promise
execute in second promise
execute in first timeout
execute in third promise
execute in second timeout
execute in fourth promise
- 很明显，在不同的环境 js eventLoop得到不一样的结果
- 基于浏览器的eventLoop我们很容易得出下面的结果
- 基于node：
1.promise也就是micor task 在下个阶段之前被调用
2.当处于timers阶段时，会将对应的timer队列处理完，故 2个timeout会先被执行，再会进入下面一个状态，此时才会调用promise
