有关Eventloop+Promise的口试题约莫分以下几个版本——随心所欲版、游刃有余版、出神入化版、至高无上版和究极变态版。假定小伙伴们战到末了一题，今后碰到此类问题，都是所向无敌。固然假如口试官们还能想出更变态的版本，算我输。

版本一：随心所欲版

考点：eventloop中的实行递次，宏使命微使命的区分。

吐槽：这个不懂，没得救了，回家重新学习吧。

setTimeout(()=>{
   console.log(1) 
},0)
Promise.resolve().then(()=>{
   console.log(2) 
})
console.log(3) 

这个版本的口试官们就迥殊和睦，仅仅考你一个观点明白，相识宏使命(marcotask)微使命(microtask)，这题就是送分题。

笔者答案：这个是属于Eventloop的问题。main script运转终了后，会有微使命行列和宏使命行列。微使命先实行，以后是宏使命。

PS：观点问题

有时刻会有版本是宏使命>微使命>宏使命，在这里笔者须要讲清楚一个观点，以避免殽杂。这里有个main script的观点，就是一最先实行的代码（代码总要有最先实行的时刻对吧，不然宏使命和微使命的行列哪里来的），这里被定义为了宏使命（笔者喜好将main script的观点零丁拎出来，不和两个使命行列混在一同），然后依据main script中发生的微使命行列和宏使命行列，离别清空，这个时刻是先清空微使命的行列，再去清空宏使命的行列。

版本二：游刃有余版

这一个版本，口试官们为了磨练一下关于Promise的明白，会给问题加点料：

考点：Promise的executor以及then的实行体式格局

吐槽：这是个小坑，promise控制的闇练的，这就是人生的小插曲。

setTimeout(()=>{
   console.log(1) 
},0)
let a=new Promise((resolve)=>{
    console.log(2)
    resolve()
}).then(()=>{
   console.log(3) 
}).then(()=>{
   console.log(4) 
})
console.log(4) 

此题看似在考Eventloop，实则考的是关于Promise的控制水平。Promise的then是微使命人人都懂，然则这个then的实行体式格局是怎样的呢，以及Promise的executor是异步的照样同步的？

毛病树模：Promise的then是一个异步的历程，每一个then实行终了以后，就是一个新的轮回的，所以第二个then会在setTimeout以后实行。（没错，这就是某年某月某日笔者的一个回复。请给我一把枪，真想打死当时的自身。）

正确树模：这个要从Promise的完成来讲，Promise的executor是一个同步函数，即非异步，马上实行的一个函数，因而他应该是和当前的使命一同实行的。而Promise的链式挪用then，每次都邑在内部天生一个新的Promise，然后实行then，在实行的历程当中不停向微使命(microtask)推入新的函数，因而直至微使命(microtask)的行列清空后才会实行下一波的macrotask。

细致剖析

（假如人人不厌弃，可以参考我的另一篇文章，从零完成一个Promise，内里的诠释浅显易懂。）
我们以babel的core-js中的promise完成为例，看一眼promise的实行范例：

代码位置：promise-polyfill

PromiseConstructor = function Promise(executor) {
    //...
    try {
      executor(bind(internalResolve, this, state), bind(internalReject, this, state));
    } catch (err) {
      internalReject(this, state, err);
    }
};

这里可以很消灭地看到Promise中的executor是一个马上实行的函数。

then: function then(onFulfilled, onRejected) {
    var state = getInternalPromiseState(this);
    var reaction = newPromiseCapability(speciesConstructor(this, PromiseConstructor));
    reaction.ok = typeof onFulfilled == 'function' ? onFulfilled : true;
    reaction.fail = typeof onRejected == 'function' && onRejected;
    reaction.domain = IS_NODE ? process.domain : undefined;
    state.parent = true;
    state.reactions.push(reaction);
    if (state.state != PENDING) notify(this, state, false);
    return reaction.promise;
},

接着是Promise的then函数，很清楚地看到reaction.promise，也就是每次then实行终了后会返回一个新的Promise。也就是当前的微使命(microtask)行列清空了，然则以后又最先添加了，直至微使命(microtask)行列清空才会实行下一波宏使命(marcotask)。

//state.reactions就是每次then传入的函数
 var chain = state.reactions;
  microtask(function () {
    var value = state.value;
    var ok = state.state == FULFILLED;
    var i = 0;
    var run = function (reaction) {
        //...
    };
    while (chain.length > i) run(chain[i++]);
    //...
  });

末了是Promise的使命resolve以后，最先实行then，可以看到此时会批量实行then中的函数，而且还给这些then中回调函数放入了一个microtask这个很显眼的函数当中，示意这些回调函数是在微使命中实行的。

那末在没有Promise的浏览器中，微使命这个行列是怎样完成的呢？

小学问：
babel中关于微使命的polyfill，假如是具有
setImmediate函数平台，则运用之，若没有则自定义则应用种种比方nodejs中的
process.nextTick，浏览器中支撑
postMessage的，或许是经由过程create一个script来完成微使命(microtask)。终究的终究，是运用setTimeout，不过这个就和微使命无关了，promise变成了宏使命的一员。

拓展思索：

为什么有时刻，then中的函数是一个数组？有时刻就是一个函数？

我们稍稍修正一下上述问题，将链式挪用的函数，变成下方的，离别挪用then。且不说这和链式挪用之间的差别用法，这边只从实践角度分辨二者的差别。链式挪用是每次都天生一个新的Promise，也就是说每一个then中回调要领属于一个microtask，而这类离别挪用，会将then中的回调函数push到一个数组当中，然后批量实行。再换句话说，链式挪用可以会被Evenloop中其他的函数插队，而离别挪用则不会（仅针对最一般的状态，then中无其他异步操纵。）。

let a=new Promise((resolve)=>{
     console.log(2)
     resolve()
})
a.then(()=>{
    console.log(3) 
})
a.then(()=>{
    console.log(4) 
})
 

下一模块会对此微使命(microtask)中的“插队”行动举行详解。

版本三：出神入化版

这一个版本是上一个版本的进化版本，上一个版本的promise的then函数并未返回一个promise，假如在promise的then中建立一个promise，那末效果该怎样呢？

考点：promise的进阶用法，关于then中return一个promise的控制

吐槽：promise也可以是地狱……

new Promise((resolve,reject)=>{
    console.log("promise1")
    resolve()
}).then(()=>{
    console.log("then11")
    new Promise((resolve,reject)=>{
        console.log("promise2")
        resolve()
    }).then(()=>{
        console.log("then21")
    }).then(()=>{
        console.log("then23")
    })
}).then(()=>{
    console.log("then12")
})

根据上一节末了一个microtask的完成历程，也就是说一个Promise一切的then的回调函数是在一个microtask函数中实行的，然则每一个回调函数的实行，又根据状态分为马上实行，微使命(microtask)和宏使命(macrotask)。

碰到这类嵌套式的Promise不要慌，首先要心中有一个行列，可以将这些函数放到相对应的行列当中。

Ready GO

第一轮

• current task: promise1是当之无愧的马上实行的一个函数，参考上一章节的executor，马上实行输出[promise1]
• micro task queue: [promise1的第一个then]

第二轮

• current task: then1实行中，马上输出了then11以及新promise2的promise2
• micro task queue: [新promise2的then函数,以及promise1的第二个then函数]

第三轮

• current task: 新promise2的then函数输出then21和promise1的第二个then函数输出then12。
• micro task queue: [新promise2的第二then函数]

第四轮

• current task: 新promise2的第二then函数输出then23
• micro task queue: []

END

终究效果[promise1,then11,promise2,then21,then12,then23]。

变异版本1：假如说这边的Promise中then返回一个Promise呢？？

new Promise((resolve,reject)=>{
    console.log("promise1")
    resolve()
}).then(()=>{
    console.log("then11")
    return new Promise((resolve,reject)=>{
        console.log("promise2")
        resolve()
    }).then(()=>{
        console.log("then21")
    }).then(()=>{
        console.log("then23")
    })
}).then(()=>{
    console.log("then12")
})

这里就是Promise中的then返回一个promise的状态了，这个考的重点在于Promise而非Eventloop了。这里就很好明白为什么then12会在then23以后实行，这里Promise的第二个then相称因而挂在新Promise的末了一个then的返回值上。

变异版本2：假如说这边不止一个Promise呢，再加一个new Promise是不是会影响效果？？

new Promise((resolve,reject)=>{
    console.log("promise1")
    resolve()
}).then(()=>{
    console.log("then11")
    new Promise((resolve,reject)=>{
        console.log("promise2")
        resolve()
    }).then(()=>{
        console.log("then21")
    }).then(()=>{
        console.log("then23")
    })
}).then(()=>{
    console.log("then12")
})
new Promise((resolve,reject)=>{
    console.log("promise3")
    resolve()
}).then(()=>{
    console.log("then31")
})

笑颜逐步变态，一样这个我们可以自身心中排一个行列：

第一轮

• current task: promise1，promise3
• micro task queue: [promise2的第一个then，promise3的第一个then]

第二轮

• current task: then11，promise2，then31
• micro task queue: [promise2的第一个then，promise1的第二个then]

第三轮

• current task: then21，then12
• micro task queue: [promise2的第二个then]

第四轮

• current task: then23
• micro task queue: []

终究输出:[promise1,promise3,then11,promise2,then31,then21,then12,then23]

版本四：至高无上版

考点：在async/await之下，对Eventloop的影响。

槽点：别被async/await给骗了，这题不难。

置信人人也看到过此类的问题，我这里有个相称浅易的诠释，不知人人是不是有兴致。

async function async1() {
    console.log("async1 start");
    await  async2();
    console.log("async1 end");
}

async  function async2() {
    console.log( 'async2');
}

console.log("script start");

setTimeout(function () {
    console.log("settimeout");
},0);

async1();

new Promise(function (resolve) {
    console.log("promise1");
    resolve();
}).then(function () {
    console.log("promise2");
});
console.log('script end'); 

async/await仅仅影响的是函数内的实行，而不会影响到函数体外的实行递次。也就是说async1()并不会壅塞后续顺序的实行，await async2()相称于一个Promise，console.log("async1 end");相称于火线Promise的then以后实行的函数。

根据上章节的解法，终究输出效果：[script start,async1 start,async2,promise1,script end,async1 end,promise2,settimeout]

假如相识async/await的用法，则并不会以为这题是难题的，但如果不相识或许一孔之见，那末这题就是灾害啊。

• 此处唯一有争议的就是async的then和promise的then的优先级的问题，请看下方详解。*

async/await与promise的优先级详解

async function async1() {
    console.log("async1 start");
    await  async2();
    console.log("async1 end");
}
async  function async2() {
    console.log( 'async2');
}
// 用于test的promise，看看await究竟在什么时候实行
new Promise(function (resolve) {
    console.log("promise1");
    resolve();
}).then(function () {
    console.log("promise2");
}).then(function () {
    console.log("promise3");
}).then(function () {
    console.log("promise4");
}).then(function () {
    console.log("promise5");
});

先给人人出个题，假如让你polyfill一下async/await，人人会怎样polyfill上述代码？下方先给出笔者的版本：

function promise1(){
    return new Promise((resolve)=>{
        console.log("async1 start");
        promise2().then(()=>{
            console.log("async1 end");
            resolve()
        })
    })
}
function promise2(){
    return new Promise((resolve)=>{
        console.log( 'async2'); 
        resolve() 
    })
}

在笔者看来，async自身是一个Promise，然后await一定也随着一个Promise，那末新建两个function，各自返回一个Promise。接着function promise1中须要守候function promise2中Promise完成后才实行，那末就then一下咯~。

依据这个版本得出的效果：[async1 start,async2,promise1,async1 end,promise2,...]，async的await在test的promise.then之前，实在也可以从笔者的polifill中得出这个效果。

然后让笔者惊奇的是用原生的async/await，得出的效果与上述polyfill不一致！得出的效果是：[async1 start,async2,promise1,promise2,promise3,async1 end,...]，由于promise.then每次都是一轮新的microtask，所以async是在2轮microtask以后，第三轮microtask才得以输出（关于then请看版本三的诠释）。

/ 突如其来的缄默沉静 /

这里插播一条，async/await由于要经由3轮的microtask才完成await，被以为开支很大，因而以后V8和Nodejs12最先对此举行了修复，概况可以看
github上面这一条pull

那末，笔者换一种体式格局来polyfill，置信人人都已充足相识await背面是一个Promise，然则假定这个Promise不是好Promise怎样办？异步是好异步，Promise不是好Promise。V8就很横暴，加了分外两个Promise用于处置惩罚这个问题，简化了下源码，大概是下面这个模样：

// 不太正确的一个形貌
function promise1(){
    console.log("async1 start");
    // 暗中存在的promise，笔者以为是为了保证async返回的是一个promise
    const implicit_promise=Promise.resolve()
    // 包含了await的promise，这里直接实行promise2，为了保证promise2的executor是同步的觉得
    const promise=promise2()
    // https://tc39.github.io/ecma262/#sec-performpromisethen
    // 25.6.5.4.1
    // throwaway，为了范例而存在的，为了保证实行的promise是一个promise
    const throwaway= Promise.resolve()
    //console.log(throwaway.then((d)=>{console.log(d)}))
    return implicit_promise.then(()=>{
        throwaway.then(()=>{
            promise.then(()=>{
                console.log('async1 end');
            })
        }) 
    })
}

ps:为了强行推延两个microtask实行，笔者也是挖空心思。

总结一下：async/await有时刻会推延两轮microtask，在第三轮microtask实行，重要原因是浏览器关于此要领的一个剖析，由于为相识析一个await，要分外建立两个promise，因而斲丧很大。厥后V8为了下降消耗，所以剔除了一个Promise，而且减少了2轮microtask，所以如今最新版本的应该是“零本钱”的一个异步。

版本五：究极变态版

贪吃大餐，什么变态的内容都往内里加，想一想就很丰厚。能考到这份上，只能说口试官人狠话也多。

考点：nodejs事宜+Promise+async/await+佛系setImmediate

槽点：笔者都不晓得谁人可以先涌现

async function async1() {
    console.log("async1 start");
    await  async2();
    console.log("async1 end");
}
async  function async2() {
    console.log( 'async2');
}
console.log("script start");
setTimeout(function () {
    console.log("settimeout");
});
async1()
new Promise(function (resolve) {
    console.log("promise1");
    resolve();
}).then(function () {
    console.log("promise2");
});
setImmediate(()=>{
    console.log("setImmediate")
})
process.nextTick(()=>{
    console.log("process")
})
console.log('script end'); 

行列实行start

第一轮：

• current task：”script start”，”async1 start”，’async2’，”promise1″，“script end”
• micro task queue：[async,promise.then,process]
• macro task queue：[setTimeout,setImmediate]

第二轮

• current task：process，async1 end ,promise.then
• micro task queue：[]
• macro task queue：[setTimeout,setImmediate]

第三轮

• current task：setTimeout,setImmediate
• micro task queue：[]
• macro task queue：[]

终究效果：[script start，async1 start，async2，promise1，script end,process,async1 end,promise2,setTimeout,setImmediate]

一样”async1 end”,”promise2″之间的优先级，因平台而异。

笔者干货总结

在处置惩罚一段evenloop实行递次的时刻：

• 第一步确认宏使命，微使命

  • 宏使命：script，setTimeout，setImmediate，promise中的executor
  • 微使命：promise.then，process.nextTick
• 第二步剖析“拦路虎”，涌现async/await不要慌，他们只在标记的函数中可以横行霸道，出了这个函数照样随着大军队的潮水。
• 第三步，依据Promise中then运用体式格局的差别做出差别的推断，是链式照样离别挪用。

• 末了一步记着一些迥殊事宜

  • 比方，process.nextTick优先级高于Promise.then

参考网址，引荐浏览：

有关V8中怎样完成async/await的，更快的异步函数和 Promise

有关async/await范例的，ecma262

另有babel-polyfill的源码，promise

跋文

Hello~Anybody here?

原本笔者是不想写这篇文章的，由于有种5年高考3年模仿的既视感，怎样口试官们都太横暴了，为了“熬煎”口试者无所不用其极，怎样变态怎样来。不过因而笔者算是完全控制了Eventloop的用法，塞翁失马吧~

有小伙伴看到末了嘛？来和笔者聊聊你碰到过的的Eventloop+Promise的变态问题。

迎接转载~但请说明出处~首发于掘金~Eventloop不恐怖，恐怖的是赶上Promise

题外话：来segmentfault试水~啊哈哈哈啊哈哈