本文主要对于javascript运行环境---浏览器的event loop机制的一些理解,不足之处,请多多指正。
Javascript单线程
JavaScript语言单线程的,也就是说,同一个时间只能做一件事。那么,为什么JavaScript只能是单线程呢?
JavaScript的单线程,与它的用途有关。作为浏览器脚本语言,JavaScript的主要用途是与用户互动,以及操作DOM。这决定了它只能是单线程,否则会带来很复杂的同步问题。比如,假定JavaScript同时有两个线程,一个线程在某个DOM节点上添加内容,另一个线程删除了这个节点,这时浏览器就不知道该以哪个线程为主。
虽然在Html5新规范中定义,允许JavaScript脚本创建多个线程,但是子线程完全受主线程控制,并且不得操作DOM。所以,这个新标准并没有改变JavaScript单线程的本质。
首先,我们来看看Javascript代码执行过程中都会有哪些东西?
代码执行栈(JavaScript execution context stack)
在代码执行过程中,主线程有一个栈,每一个函数执行的时候,都会生成新的execution context(执行上下文),执行上下文会包含一些当前函数的参数、局部变量之类的信息,它会被推入栈中, running execution context(正在执行的上下文)始终处于栈的顶部。当函数执行完后,它的执行上下文会从栈弹出。
现在我们来看看这段代码的执行顺序:
function foo2() {
console.log('foo2');
}
function foo1() {
console.log('foo1');
foo2();
}
foo1();
代码结果是:
// foo1
// foo2
具体流程如图所示
- 栈中代码的执行遵循先进后出原则
Javascript运行环境的运行机制
在Javascript中,所有任务可以分成两种,一种是同步任务(synchronous),另一种是异步任务(asynchronous)。同步任务指的是,在主线程上排队执行的任务,只有前一个任务执行完毕,才能执行后一个任务;异步任务指的是,不进入主线程、而进入"任务队列"(task queue)的任务,只有"任务队列"通知主线程,某个异步任务可以执行了,该任务才会进入主线程执行。
主要流程:
- 所有同步任务都在主线程上执行,形成一个执行栈(execution context stack)。
- 主线程之外,还存在一个"任务队列"(task queue)。只要异步任务有了运行结果,就在"任务队列"之中放置一个事件。
- 一旦"执行栈"中的所有同步任务执行完毕,系统就会读取"任务队列",看看里面有哪些事件。那些对应的异步任务,于是结束等待状态,进入执行栈,开始执行。
- 主线程不断重复上面的第三步。 根据这个流程画了一张简单的草图,不足之处,请大家指正,图示如下:
浏览器的event loop
浏览器的event loop在html5的规范中明确定义。事件、用户交互、脚本、渲染、网络这些都是我们所熟悉的东西,他们都是由event loop协调的。触发一个click事件,进行一次ajax请求,背后都有event loop在运作。
什么是event loop
主线程不断的从任务队列中获取事件来执行,这个过程是不断的循环的,这样的一种运行机制也就被称之为Event Loop(事件循环)
- 主线程在运行时,会生成堆和栈,里面存储的是调用的代码
- 栈中调用的代码会调用各种外部的API,这些代码执行会在任务队列中添加各种事件
- 只要栈中的代码执行完成,主线程就会去读取任务队列,依次执行任务队列中事件对应的回调函数
- 栈中的同步代码总会先于任务队列中的异步代码执行
现在我们来看这段代码在浏览器中是如何执行的:
console.log('1');
setTimeout(function () {
console.log('setTimeout 1')
}, 0);
Promise.resolve().then(function () {
console.log('promise 1');
}).then(function () {
console.log('promise 2');
});
console.log('2');
测试这段代码在不同的浏览器上显示的顺序
- 谷歌浏览器显示的是这样的
- safari 9.1.2浏览器中显示的却是promise1 promise2会在setTimeout的后边
为什么会出现不同浏览器解析这段代码输出不同的顺序? 在了解完macro-task和micro-task之后就明白了
macro-task
一个event loop有一个或者多个macro-task队列。 当用户代理安排一个任务,必须将该任务增加到相应的event loop的一个macri-tsak队列中。
每一个macro-task都来源于指定的任务源,比如可以为鼠标、键盘事件提供一个macro-task队列,其他事件又是一个单独的队列。可以为鼠标、键盘事件分配更多的时间,保证交互的流畅。
那么有哪些任务源是macro-task任务源呢?
- DOM操作任务源:此任务源被用来相应dom操作,例如一个元素以非阻塞的方式插入文档。
- 网络任务源:网络任务源被用来响应网络活动。
macro-task任务源包含的范围比较广泛,基本上我们对DOM元素进行事件绑定并且绑定的各个事件都是macro-task任务源,需要注意的是setTimeout、setInterval、setImmediate也是macro-task任务源。所以macro-task任务源可以总结为
- setTimeout
- setInterval
- setImmediate
- I/O
micro-task
除了macro-task还有一个micro-task,这一个概念是ES6提出Promise以后出现的。这个micro-task queue只有一个。并且会在且一定会在每一个macro-task后执行,且执行是按顺序的。加入到micro-task的事件类型有Promise.resolve().then(), process.nextTick()值得注意的是,event loop一定会在执行完micrtask以后才会寻找新的可执行的macrotask队列。
常见的产生micro-task事件的方法:
- process.nextTick
- promise
- Object.observe
- MutationObserver
在Promises/A+规范的Notes 3.1中提及了promise的then方法可以采用"宏任务(macro-task)"机制或者"微任务(micro-task)"机制来实现。所以开头提及的promise在不同浏览器的差异正源于此,有的浏览器将then放入了macro-task队列,有的放入了micro-task队列。
那让我们再来看一段代码:
setTimeout(function setTimeout2() {
console.log('setTimeout1');
}, 0);
setTimeout(function setTimeout2() {
console.log('setTimeout2');
Promise.resolve().then(function promise1() {
console.log('promise1');
});
}, 0);
Promise.resolve().then(function promise2() {
console.log('promise2');
setTimeout(function setTimeout1() {
console.log('setTimeout3');
Promise.resolve().then(function promise1() {
console.log('promise3');
});
}, 0);
});
我们来看这段代码在浏览器中执行的具体结果:
代码执行过程: script里的代码被列为一个macro-task,放入macro-task队列。
循环1:
- 【macro-task队列:script ;micro-task队列:】
- 从macro-task队列中取出script任务,推入栈中执行。
- promise2列为micro-task,setTimeout1列为macro-task,setTimeout2列为macro-task。
- 【task队列:setTimeout1 setTimeout2;micro-task队列:promise2】
- script任务执行完毕,执行micro-task checkpoint,取出micro-task队列的promise2执行。
循环2:
- 【macro-task队列:setTimeout1 setTimeout2;micro-task队列:】
- 从macro-task队列中取出setTimeout1,推入栈中执行,将promise1列为micro-task
- 【macro-task队列:setTimeout2;micro-task队列:promise1】
- 执行micro-task checkpoint,取出micro-task队列的promise1执行。
循环3:
- 【macro-task队列:setTimeout3;micro-task队列:】
- 从macro-task队列中取出setTimeout3,推入栈中执行。
- setTimeout3任务执行完毕,执行micro-task checkpoint。
- 【macro-task队列:;micro-task队列:promise3】
- 执行micro-task checkpoint,取出micro-task队列的promise3执行。
event loop的处理过程
event loop的处理过程(Processing model) 在规范的Processing model定义了event loop的循环过程:
一个event loop只要存在,就会不断执行下边的步骤:
- 在tasks队列中选择最老的一个task,用户代理可以选择任何task队列,如果没有可选的任务,则跳到下边的micro-tasks步骤。
- 将上边选择的task设置为正在运行的task。
- Run: 运行被选择的task。
- 将event loop的currently running task变为null。
- 从task队列里移除前边运行的task。
- micro-tasks: 执行micro-tasks任务检查点。(也就是执行micro-tasks队列里的任务)
- 更新渲染(Update the rendering)...
- 如果这是一个worker event loop,但是没有任务在task队列中,并且WorkerGlobalScope对象的closing标识为true,则销毁event loop,中止这些步骤,然后进行定义在Web workers章节的run a worker。
- 返回到第一步。
event loop会不断循环上面的步骤,概括说来:
event loop会不断循环的去取tasks队列的中最老的一个任务推入栈中执行,并在当次循环里依次执行并清空micro-task队列里的任务。