单线程
因为javascript
是单线程的,所谓的单线程是指JS
引擎中负责解释和执行javascript
代码的线程只有一个,可以称为主线程。
除了主线程之外,还存在其他的线程。例如:处理 AJAX
请求的线程、处理 DOM
事件的线程、定时器线程、读写文件的线程(例如在Node.js
中)等等。
异步过程
一个异步过程通常是这样的:主线程发起一个异步的请求,相应的工作线程请求并告知主线程已经收到异步函数的返回;主线程可以继续执行后面的代码。同时工作线程执行异步任务。工作线程工作完成后,通知主线程;主线程收到通知后,执行一定的工作。
异步函数通常具有以下的形式:
A(args..., callbackFn)
它可以叫做异步过程的发起函数,或者叫做异步任务注册函数。args
是这个函数需要的参数。callbackFn
也是这个函数的参数,但是它比较特殊所以单独列出来。
所以,从主线程的角度看,一个异步过程包括下面两个要素:
- 发起函数(或叫注册函数)
A
- 回调函数
callbackFn
它们都是在主线程上调用的,其中注册函数用来发起异步过程,回调函数用来处理结果。
举个具体的例子:
setTimeout(fn, 1000);
其中的setTimeout
就是异步过程的发起函数,fn
是回调函数。
前面说的形式
A(args..., callbackFn)
只是一种抽象的表示,并不代表回调函数一定要作为发起函数的参数,例如:
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = xxx; // 添加回调函数
xhr.open('GET', url);
xhr.send(); // 发起函数
发起函数和回调函数就是分离的。
消息队列和事件循环
异步过程中,工作线程在异步操作完成后需要通知主线程,那么通知机制是怎么样的呢?就是利用消息队列和事件循环。
工作线程将消息放到消息队列,主线程通过事件循环过程去取消息。
- 消息队列: 消息队列是一个先进先出的队列,里面放着各种各样的消息;
- 事件循环: 事件循环是指主线程重复从消息队列中取消息,执行的过程。
实际上,主线程只会做一件事情,就是从消息队列里面取消息、执行消息,再取消息、再执行。当消息队列为空时,就会等待直到消息队列变成非空。而且主线程只有在将当前的消息执行完成后,才会去取下一个消息。这种机制就叫做事件循环机制,取一个消息并执行的过程叫做一次循环。
事件循环用代码表示大概是这样的:
while(true) {
var message = queue.get();
execute(message);
}
那么,消息队列中放的消息具体是什么东西?消息的具体结构当然跟具体的实现有关,但是为了简单起见,我们可以认为:
消息就是注册异步任务时添加的回调函数。
再次以异步AJAX
为例,假设存在如下的代码:
$.ajax('http://segmentfault.com', function(resp) {
console.log('我是响应:', resp);
});
// 其他代码
...
...
...
主线程在发起AJAX
请求后,会继续执行其他代码。AJAX
线程负责请求segmentfault.com
,拿到响应后,它会把响应封装成一个JavaScript
对象,然后构造一条消息:
// 消息队列中的消息就长这个样子
var message = function () {
callbackFn(response);
}
// 其中的callbackFn就是前面代码中得到成功响应时的回调函数。
主线程在执行完当前循环中的所有代码后,就会到消息队列取出这条消息(也就是message
函数),并执行它。到此为止,就完成了工作线程对主线程的通知,回调函数也就得到了执行。如果一开始主线程就没有提供回调函数,AJAX
线程在收到HTTP
响应后,也就没必要通知主线程,从而也没必要往消息队列放消息。
用图表示这个过程就是:
从上文中我们也可以得到这样一个明显的结论,就是:异步过程的回调函数,一定不在当前这一轮事件循环中执行。
异步和事件
上文中说的“事件循环”,为什么里面有个事件呢?那是因为:
消息队列中的每条消息实际上都对应着一个事件。
上文中一直没有提到一类很重要的异步过程:DOM
事件。
举例来说:
var button = document.getElement('#btn');
button.addEventListener('click', function(e) {
console.log();
});
从事件的角度来看,上述代码表示:在按钮上添加了一个鼠标单击事件的事件监听器;当用户点击按钮时,鼠标单击事件触发,事件监听器函数被调用。
从异步过程的角度看,addEventListener
函数就是异步过程的发起函数,事件监听器函数就是异步过程的回调函数。事件触发时,表示异步任务完成,会将事件监听器函数封装成一条消息放到消息队列中,等待主线程执行。
事件的概念实际上并不是必须的,事件机制实际上就是异步过程的通知机制。我觉得它的存在是为了编程接口对开发者更友好。
另一方面,所有的异步过程也都可以用事件来描述。例如:setTimeout
可以看成对应一个时间到了!的事件。前文的 setTimeout(fn, 1000)
;可以看成:
timer.addEventListener('timeout', 1000, fn);
理解 JS 代码的执行
栗子1
console.log('start');
// Timer1
setTimeout(function() {
console.log('hello');
},200);
// Timer2
setTimeout(function() {
console.log('world');
},100);
console.log('end');
我们分步骤来进行这个过程解答
js
执行引擎开始执行上述代码时,会先讲一个main()
方法加入执行栈。首先第一个console.log(‘start’)
入栈,console.log
方法是一个webkit
内核支持的普通方法,而不是WebAPIs
涉及的方法,所以这里log(‘start’)
方法立即出栈被引擎执行。引擎继续往下,将
setTimeout(callback,200)
添加到执行栈。setTimeout()
方法属于事件循环模型中WebAPIs
中的方法,引擎在将setTimeout()
方法出栈执行时,将延时执行的函数交给了相应模块,即图右方的timer
模块来处理。然后主线程继续向下执行,紧接着将第二个定时器也交给
Timer
模块,然后执行到第二个console.log()
,控制台打印'end'
,执行完毕后清空执行栈。但是并没有结束,在主线程执行的同时,
Timer
模块会检查其中的异步代码,一旦满足触发条件,就会将它添加到任务队列中。Timer2
延迟100ms
,所以会早于Timer1
被添加到队列排头。而主线程此时处于空闲状态,所以会检查任务队列是否有待执行的任务。此时会将Timer2
回调中的console.log()
执行,控制台打印’world’
,然后执行栈空闲后继续检查任务队列,将Timer1
的代码压入执行栈中执行,控制台打印’hello’
,清空执行栈,此时任务队列为空,执行结束,程序处理完毕,main()
方法也出栈。在这里再次强调一下,不是
setTimeout
加入了事件队列,而是setTimeout
里面的回调函数加入了事件队列。
栗子2
console.log(1);
// Time1
setTimeout(function() {
console.log(2);
},300);
// Time2
setTimeout(function() {
console.log(3)
},400);
for (var i = 0;i<10000;i++) {
console.log(4);
}
// Time3
setTimeout(function() {
console.log(5);
},100);
首先是打印出 1,然后是10000个4,那么Time1
、Time2
、Time3
是顺序是如何的呢?
在这个代码中,for
循环比较耗时,在Time1
和Timer
加入到执行队列中后,主线程依然还在执行for
循环中的代码,处于阻塞状态。队列中的Time1
和Time2
并不会得以执行。当for
循环结束,这时才将Time3
交由Timer
模块去管理,清空执行栈。虽然在这里Time3
的延迟时间最短,但是加入任务队列后还是会排在Time1
和Time2
的后面,所以此时按顺序执行任务队列中的代码,依次打印2、3、5。
栗子3
console.log(1);
//Time2
setTimeout(function() {
console.log(3)
},400);
//Time1
setTimeout(function() {
console.log(2);
},300);
for (var i = 0;i<10000;i++) {
console.log(4);
}
//Time3
setTimeout(function() {
console.log(5);
},100);
我们将Time1
和Time2
的顺序对换一下,按照前面的说法,Time2
先加入任务队列,然后是Time1
,再然后是Time3
。可是执行的结果还是1、4、2、3、5,这是为什么呢?虽然Time1
的执行时间短,可是它比Time2
晚加入任务队列啊。
为了验证这个问题,我们可以提出这样的一个假设:
如果
setTimeout
加入队列的阻塞时间大于两个setTimeout
执行的间隔时间,那么先加入任务队列的先执行,尽管它里面设置的时间比另一个setTimeout
的要大。
验证1
// Time2
setTimeout(function() {
console.log(2);
},400);
var start=new Date();
for (var i = 0;i<5000;i++) {
console.log('这里只是模拟一个耗时操作');
};
var end=new Date();
console.log('阻塞耗时:'+Number(end-start)+'毫秒');
// Time1
setTimeout(function() {
console.log(3)
},300);
Time1
比Time2
设定的执行时间早100ms,但是Time2
先加入任务队列,在Time2
和Time1
时间有一个阻塞的for
循环。
验证2
setTimeout(function() {
console.log(2);
},400);
var start=new Date();
for (var i = 0;i<500;i++) {
console.log('这里只是模拟一个耗时操作');
};
var end=new Date();
console.log('阻塞耗时:'+Number(end-start)+'毫秒');
// Time1
setTimeout(function() {
console.log(3)
},300);
此时,Time1
先执行,因为阻塞的耗时小于Time1
和Time2
的执行间隔时间100毫秒;
验证3
我们再来验证一下,把Time2
的执行时间设为350毫秒;
// Time2
setTimeout(function() {
console.log(2);
},350);
var start=new Date();
for (var i = 0;i<500;i++) {
console.log('这里只是模拟一个耗时操作');
};
var end=new Date();
console.log('阻塞耗时:'+Number(end-start)+'毫秒');
//Time1
setTimeout(function() {
console.log(3)
},300);
直接结果为:
Time2
先执行,因为阻塞的时间大于两个setTimeout
之间的间隔时间。
通过上面的假设,我们可以得出这样一个结论:如果
setTimeout
加入队列的阻塞时间大于两个setTimeout
执行的间隔时间,那么先加入任务队列的先执行,尽管它里面设置的时间可能比另一个setTimeout
的要大。