原来你是这样的setTimeout

Posted 2020-10-02

先上代码

1 console.log("start");
2 setTimeout(function(){
3     console.log("Hello");
4 },200);
5 setTimeout(function(){
6     console.log("World");
7 },100);
8 console.log("end");

start
end
undefined
World
Hello

如果看出了结果，那么我们修改一下代码

console.log("start");
setTimeout(function(){
    console.log("Hello");
},200);
setTimeout(function(){
    console.log("World");
},300);
for(var i = 0;i <= 1000; i++){
    console.log(i);
}
setTimeout(function(){
    console.log("I am here!");
},100);
console.log("end");

start

end

undefined
I am here!
Hello
World

是的，在我们看来这是正确的，没有错误的。

那我们再稍微修改一下我们的代码

console.log("start");
setTimeout(function(){
    console.log("Hello");
},200);
setTimeout(function(){
    console.log("World");
},300);
for(var i = 0;i <= 10000; i++){
    console.log(i);
}
setTimeout(function(){
    console.log("I am here!");
},100);
console.log("end");

start

end
undefined
Hello
World
I am here!

是不是很神奇。首先得从JS引擎说起。

JS引擎在内存中会分配堆区和栈区。

我们来看一段代码

1 function A(){
2     var a = 4;
3     b(a);
4 }
5 function B(num){
6     var newNum = num * num;
7     console.log(newNum);                
8 }
9 A();

步骤：运行A()方法，将A()入栈。A上下文中存在变量a = 4   

　　　调用B()方法，将B()入栈。B上下文中存在变量num = 4,newNum = 16

　　　调用B()方法中的console.log()，入栈，打印出16.

　　    继续运行，将console.log()、B()方法，出栈，A()方法运行完毕出栈，代码运行完毕，清空栈。

众所周知，JS引擎是单线程的，在某一个特定时间只能执行一个任务，并阻塞其他任务的执行，也就是说这些任务是串行的。用户不得不等待一个耗时的操作完成之后才能继续后面的操作，实际开发中我们可以使用异步代码来解决问题。

EventLoop事件循环

当异步方法比如这里的setTimeout()，或者Ajax请求、DOM事件执行的时候，会交由浏览器内核的其他模块去管理。当异步的方法满足触发条件之后，该模块就将方法推入到一个任务队列(task queue)中，当主线程代码执行完毕处于空闲状态的时候，就会检查任务队列，将队列中的第一个任务入栈执行，完毕后继续检查任务队列，如此循环。

前提条件：主线程处于空闲状态，这就是事件循环的模型。

我们来看一下第一个列子：

首先console.log()入栈，打印完毕之后出栈，紧接着执行到setTImeout()计时器，此时JS引擎会将定时器交给浏览器的另一个模块去管理，在这里我们称Timer()模块，紧接着第二个计时器也交给Timer模块。

然后执行到第二个console.log()，执行完毕后清空执行栈。

但是并没有结束，在主线程执行的同时，Timer()模块会检查其中的代码，一旦满足触发条件，就会将它添加到任务队列中，TImer2延迟100秒，所以在于Timer1被添加到队列开头。而主线程此时处于空闲状态，所以会检查任务队列是否有待执行的任务。

此时会将队列中的Timer2()执行，控制台打印，然后执行栈清空，继续检查任务队列，将Timer1()入栈并执行，控制台打印，清空执行栈。此时任务队列为空，清空执行栈。

然后我们来看第二段和第三段代码，就比较好玩了

和第一段不同的是，在最后一个定时器前加了一个for循环，我们模拟了一个1000和10000的for循环。

第三段比较奇怪。Timer3仅仅延迟了100毫秒，反而在两个Timer()之后执行了。

想想看，为什么？

原因很简单，因为在Timer1和Timer2加入到执行队列中后，主线程仍然执行着for循环中的代码，处于阻塞状态。队列中的Timer1和Timer2并不会得以执行。

当for循环结束，这时才将Timer3交由Timer模块去管理，继续执行后续代码打印"end"，清空执行栈。虽然Timer3的延迟时间很短，但是加入任务队列后还是会排在Timer1和Timer2的后面，所以此时会按顺序执行任务队列中的代码。同时需要注意的是，这种情况下的三个定时器延迟执行的时间已经远远超过了指定的时间。

总结：我们发现不论事件循环模型还是setTimeout机制，其实不是难点，但却是容易忽略的点。很多问题的产生是因为忽略了一些简单的原理导致的。