说起JS的异步执行机制,如果百度一下,你首先会发现阮一峰的写过一篇关于异步机制的文章(http://www.ruanyifeng.com/blog/2014/10/event-loop.html),等你津津有味又一头雾水的看完,然后继续看百度的其他结果,然后会发现,阮一峰的这篇被另一个大牛朴灵给批判了
(http://www.360doc.com/content/14/1011/13/15077656_416048738.shtml)。
由此可见,关于异步执行机制到底是怎么回事,因为涉及到浏览器底层机制,所以不容易彻底了解清楚,就算是大牛阮一峰,也只是通过英文文献来了解,而且一知半解。我的这篇文章只是试图尽可能简单的描述一下JS的异步执行机制,坦白说,我现在并不能完全弄懂这个机制,所以也不能完全解释清这个机制,所以,如果我写的越严谨,就越容易出错,我只能简单但是较模糊的描述一下:
JS的运行环境是一个很复杂的环境,它里面有非常多的复杂的名词事物,用简单又不严谨的说法来说,运行环境里至少有下面这些事物:
- 堆 (Heap):存放变量、对象、函数等。简单地说,堆跟咱们这个异步机制主题相关度不大,当然实际上肯定有关联。
- 事件队列 (Event Queue):可能跟所谓“任务队列” (Task Queue) 指代同一个事物,它是一个列表,这个列表就是即将被执行的任务的列表,它负责给任务排序。事件队列不止一个,是有多个,比如输入事件有一个自己的队列,定时器有一个自己的队列,所有回调函数也有一个自己的队列,等等,然后这些队列又有优先级,某个队列的优先级注定高,比如输入事件,因为从用户感受来说,用户的输入如果优先级不高,用户会觉得浏览器响应慢,会觉得“卡”,甚至可能会把键盘或者电脑砸了,后果很严重。。。所以必须是第一优先级的,然后另有一些队列优先级低,比如回调函数队列。最终,这些队列会形成一个总队列,而且,这个总队列随时会变化,再而且,也是因为优先级的关系,经常会有插队的事情发生。
可以这样理解一下:
+++++++~~~~~~~~~~~=======########
以上代表总队列,分为若干个子队列,每一个子队列如果有新任务,也只会加到自己的队列的末尾,而不会加到总队列的末尾。有一个执行器会挨个执行总队列里的任务。 - 栈 (stack):它负责根据事件队列来执行任务,就是说,进来一个任务,然后执行,然后扔出去。栈相当于流水线上的干活的操作臂。(此处存疑,栈应该是某种存储空间,为何成了执行者?似乎执行者应该是主线程的某个事物。)
- 事件循环 (Event Loop):事件循环是事件队列和栈的关联的桥梁,它做的事情是:如果栈空了,事件队列还没空,那么事件循环就从事件队列拿出来一个任务,扔给栈。事件循环相当于一个有眼睛的机械臂,它看到栈空了,事件队列还有任务,就把任务的第一个抓出来扔给栈,它自己就完事了。
- 主线程:JS是单线程的没错,但这只是说JS引擎是单缸驱动的,但是一台车肯定不是只有发动机就能在路上跑,发动机还需要别的部件协助它才行。在咱们这,别的部件就是指HTTP线程、I/O线程、GUI线程等等,这些线程由浏览器提供,跟JS的线程是两回事了。JS的线程咱们称为主线程。那么主线程跟上面这些名词是什么关系呢?尤其是跟栈是什么关系呢?栈肯定是主线程的一个组成部分,任务队列似乎不是主线程的组成部分。事件循环跟主线程的关系我不明朗,也可能事件循环只是一个动词,而不是名词。上面几个名词解释的正确性我不确定,请先这么理解吧。
有一个国外的web app,专门用来讲解异步事件的门道Loupe,这个更接近真实情况。为什么我不讲解这个?因为更复杂了,我们并不打算研究浏览器的底层,不是么?
然后说一下任务队列里的任务。所有任务可以分成两种,一种是同步任务(synchronous),另一种是异步任务(asynchronous)。同步任务指的是,靠主线程自己就可以执行完成的任务;异步任务指的是,主线程执行开始之后,需要靠主线程之外的线程才能完成的任务。由主线程决定是否要动用其他线程。以下内容,不再提栈,只说主线程。
现在说重点:
异步任务的执行机制是:
当主线程遇到一个异步任务,比如一个ajax请求,当主线程执行到xhr.send()
的时候,这个send命令是立即执行的,并不会像一些人想象的,拖到所有同步任务的最后面。然后主线程向http线程发送指令,要求http线程向服务器发送请求。这里强调一下http线程,显然它不是主线程的一部分,因为它可以并发,如果你有100个ajax请求,每个都需要1秒钟,是不是http线程要花100秒呢?并不是,它会并发100个请求,总共耗时大约1.01秒就完成了。
主线程向以http线程为代表的几个线程发送指令之后,主线程就暂时不再管这个ajax任务了,而是去看任务队列里的下一个任务。
http线程发送了请求之后接收反馈,收到之后,形成一个新的事件(可以叫做“我收到啦!”事件),然后插入到回调函数队列中,因为回调函数队列的优先级很低,所以会排到总队列的最后面,其结果就是:主线程把同步任务都完成了,才开始执行异步事件的回调。注意,并不是异步任务在全体同步任务结束之后才开始,而是异步任务的回调通常在全体同步任务结束之后才开始!异步任务跟异步任务的回调是两回事!是两个任务!一个鲜明的例子就是setTimeout(fn, 1000)
,计时是从主线程遇到setTimeout()
任务,然后分配给计时器线程,计时器线程开始干活的时候就开始计时了!只不过要1秒之后fn
才执行!setTimeout()
和fn
是两个任务!setTimeout()
是立即执行,fn
才是1秒之后执行。但是setTimeout()
的执行,人眼是感受不到的,因为并没有什么地方有一个秒表告诉你setTimeout()
开始执行了;而fn的执行,人眼能感受到,所以人们会错误的以为fn才是异步任务,其实fn并不是,fn
是个回调任务,往往fn
是同步任务,比如fn
可能是console.log(123)
,这怎么会是异步任务。
所以,异步机制是浏览器的两个或以上常驻线程共同完成的,异步请求是JS主线程和其他某个线程共同完成的,JS的执行线程发起异步请求(这时浏览器会开一条新的HTTP请求线程来执行请求,这时JS自己的任务已完成,继续执行线程队列中剩下的其他任务),然后在未来的某一时刻"任务队列"线程监视到之前的发起的HTTP请求已完成,"任务队列"就会把完成事件插入到JS执行队列的尾部等待JS处理。
最后专门说说定时触发(settimeout和setinterval)。
定时触发是由浏览器的定时器线程执行的定时计数,然后在定时时间到达之后,定时器线程把定时处理函数的执行请求插入到JS回调队列的尾端。
setTimeout(function() {
alert(1);
}, 100);
sometask; // 是个同步任务,假设耗时1000毫秒
这个1到底是100毫秒之后弹出,还是1000毫秒(或更多时间)后弹出呢?又或是1100毫秒之后弹出?
答案是,1000毫秒多一点点之后弹出。
原因:浏览器会先执行setTimeout,也就是开始计时,然后开始执行sometask,执行了1000毫秒,然后去回调队列里看回调任务,alert(1);早就恭候了,因为定时100毫秒之后alert(1)就可以执行了。所以,等1000毫秒的任务完成,1就会立即弹出,所以答案是1000毫秒多一点点之后弹出。
所以用这两个函数的时候,实际的执行时间是大于或等于指定时间的,不保证能准确定时的。
最后强调一下setInterval。比如我希望每100毫秒打印一个1。然后,又有极端情况,就是sometask耗时1000毫秒。你以为sometask结束之后会打出10个1么?并不会,只会打出1个1,因为setInterval第一次读秒结束之后,回调队列出现了一个alert(1),根据之前的理论,并不会执行。又过了100毫秒之后,计时器线程会去观察回调队列是不是已经有了alert(1),如果有,就不再往回调队列里加alert(1),目的就是为了避免回调叠加执行。
总之,你需要记住,异步任务就是主线程在任务队列里看到了这个任务,看了一眼之后就然后安排别的线程帮忙,然后主线程就忙别的去了,别的线程帮忙完事之后,再在队列末尾放一个新任务叫“帮忙完毕”,到此异步任务本身就完事。主任务看到“帮忙完毕”任务之后,就去执行回调,回调执行完,这个异步任务连同回调就全都完事。然后,如果并没有回调。。。没有就没有呗。