标签：
JavaScript的setTimeout与setInterval是两个很容易欺骗别人感情的方法,因为我们开始常常以为调用了就会按既定的方式执行, 我想不少人都深有同感, 例如
- setTimeout( function(){ alert(’你好!’); } , 0);
- setInterval( callbackFunction , 100);
认为setTimeout中的问候方法会立即被执行,因为这并不是凭空而说,而是JavaScript API文档明确定义第二个参数意义为隔多少毫秒后,回调方法就会被执行. 这里设成0毫秒,理所当然就立即被执行了.
同理对setInterval的callbackFunction方法每间隔100毫秒就立即被执行深信不疑!
但随着JavaScript应用开发经验不断的增加和丰富,有一天你发现了一段怪异的代码而百思不得其解:
- div.onclick = function(){
- setTimeout( function(){document.getElementById(’inputField’).focus();}, 0);
- };
既然是0毫秒后执行,那么还用setTimeout干什么, 此刻, 坚定的信念已开始动摇.
直到最后某一天 , 你不小心写了一段糟糕的代码:
- setTimeout( function(){ while(true){} } , 100);
- setTimeout( function(){ alert(’你好!’); } , 200);
- setInterval( callbackFunction , 200);
第一行代码进入了死循环,但不久你就会发现,第二,第三行并不是预料中的事情,alert问候未见出现,callbacKFunction也杳无音讯!
这时你彻底迷惘了,这种情景是难以接受的,因为改变长久以来既定的认知去接受新思想的过程是痛苦的,但情事实摆在眼前,对JavaScript真理的探求并不会因为痛苦而停止,下面让我们来展开JavaScript线程和定时器探索之旅!
拔开云雾见月明
出现上面所有误区的最主要一个原因是:潜意识中认为,JavaScript引擎有多个线程在执行,JavaScript的定时器回调函数是异步执行的.
而事实上的,JavaScript使用了障眼法,在多数时候骗过了我们的眼睛,这里背光得澄清一个事实:
JavaScript引擎是单线程运行的,浏览器无论在什么时候都只且只有一个线程在运行JavaScript程序.
JavaScript引擎用单线程运行也是有意义的,单线程不必理会线程同步这些复杂的问题,问题得到简化.
那么单线程的JavaScript引擎是怎么配合浏览器内核处理这些定时器和响应浏览器事件的呢?
下面结合浏览器内核处理方式简单说明.
浏览器内核实现允许多个线程异步执行,这些线程在内核制控下相互配合以保持同步.假如某一浏览器内核的实现至少有三个常驻线程:javascript引擎线程,界面渲染线程,浏览器事件触发线程,除些以外,也有一些执行完就终止的线程,如Http请求线程,这些异步线程都会产生不同的异步事件,下面通过一个图来阐明单线程的JavaScript引擎与另外那些线程是怎样互动通信的.虽然每个浏览器内核实现细节不同,但这其中的调用原理都是大同小异.
由图可看出,浏览器中的JavaScript引擎是基于事件驱动的,这里的事件可看作是浏览器派给它的各种任务,这些任务可以源自JavaScript引擎当前执行的代码块,如调用setTimeout添加一个任务,也可来自浏览器内核的其它线程,如界面元素鼠标点击事件,定时触发器时间到达通知,异步请求状态变更通知等.从代码角度看来任务实体就是各种回调函数,JavaScript引擎一直等待着任务队列中任务的到来.由于单线程关系,这些任务得进行排队,一个接着一个被引擎处理.
上图t1-t2..tn表示不同的时间点,tn下面对应的小方块代表该时间点的任务,假设现在是t1时刻,引擎运行在t1对应的任务方块代码内,在这个时间点内,我们来描述一下浏览器内核其它线程的状态.
t1时刻:
GUI渲染线程:
该线程负责渲染浏览器界面HTML元素,当界面需要重绘(Repaint)或由于某种操作引发回流(reflow)时,该线程就会执行.本文虽然重点解释JavaScript定时机制,但这时有必要说说渲染线程,因为该线程与JavaScript引擎线程是互斥的,这容易理解,因为JavaScript脚本是可操纵DOM元素,在修改这些元素属性同时渲染界面,那么渲染线程前后获得的元素数据就可能不一致了.
在JavaScript引擎运行脚本期间,浏览器渲染线程都是处于挂起状态的,也就是说被”冻结”了.
所以,在脚本中执行对界面进行更新操作,如添加结点,删除结点或改变结点的外观等更新并不会立即体现出来,这些操作将保存在一个队列中,待JavaScript引擎空闲时才有机会渲染出来.
GUI事件触发线程:
JavaScript脚本的执行不影响html元素事件的触发,在t1时间段内,首先是用户点击了一个鼠标键,点击被浏览器事件触发线程捕捉后形成一个鼠标点击事件,由图可知,对于JavaScript引擎线程来说,这事件是由其它线程异步传到任务队列尾的,由于引擎正在处理t1时的任务,这个鼠标点击事件正在等待处理.
定时触发线程:
注意这里的浏览器模型定时计数器并不是由JavaScript引擎计数的,因为JavaScript引擎是单线程的,如果处于阻塞线程状态就计不了时,它必须依赖外部来计时并触发定时,所以队列中的定时事件也是异步事件.
由图可知,在这t1的时间段内,继鼠标点击事件触发后,先前已设置的setTimeout定时也到达了,此刻对JavaScript引擎来说,定时触发线程产生了一个异步定时事件并放到任务队列中, 该事件被排到点击事件回调之后,等待处理.
同理, 还是在t1时间段内,接下来某个setInterval定时器也被添加了,由于是间隔定时,在t1段内连续被触发了两次,这两个事件被排到队尾等待处理.
可见,假如时间段t1非常长,远大于setInterval的定时间隔,那么定时触发线程就会源源不断的产生异步定时事件并放到任务队列尾而不管它们是否已被处理,但一旦t1和最先的定时事件前面的任务已处理完,这些排列中的定时事件就依次不间断的被执行,这是因为,对于JavaScript引擎来说,在处理队列中的各任务处理方式都是一样的,只是处理的次序不同而已.
t1过后,也就是说当前处理的任务已返回,JavaScript引擎会检查任务队列,发现当前队列非空,就取出t2下面对应的任务执行,其它时间依此类推,由此看来:
如果队列非空,引擎就从队列头取出一个任务,直到该任务处理完,即返回后引擎接着运行下一个任务,在任务没返回前队列中的其它任务是没法被执行的.
相信您现在已经很清楚JavaScript是否可多线程,也了解理解JavaScript定时器运行机制了,下面我们来对一些案例进行分析:
案例1:setTimeout与setInterval
这两段代码看一起效果一样,其实非也,第一段中回调函数内的setTimeout是JavaScript引擎执行后再设置新的setTimeout定时, 假定上一个回调处理完到下一个回调开始处理为一个时间间隔,理论两个setTimeout回调执行时间间隔>=10ms.第二段自setInterval设置定时后,定时触发线程就会源源不断的每隔十秒产生异步定时事件并放到任务队列尾,理论上两个setInterval回调执行时间间隔<=10.
案例2:ajax异步请求是否真的异步?
很多同学朋友搞不清楚,既然说JavaScript是单线程运行的,那么XMLHttpRequest在连接后是否真的异步?
其实请求确实是异步的,不过这请求是由浏览器新开一个线程请求(参见上图),当请求的状态变更时,如果先前已设置回调,这异步线程就产生状态变更事件放到JavaScript引擎的处理队列中等待处理,当任务被处理时,JavaScript引擎始终是单线程运行回调函数,具体点即还是单线程运行onreadystatechange所设置的函数.
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
虽然有越来越多的网站在应用AJAX技术进行开发，但是构建一个复杂的AJAX应用仍然是一个难题。造成这些困难的主要原因是什么呢？是与服务器的异步通信问题？还是GUI程序设计问题呢？通常这两项工作都是由桌面程序来完成的，那究竟为何开发一个可以实现同样功能的AJAX应用就这么困难呢？
让我们通过一个简单的例子来认识这个问题。假设你要建立一个树形结构的公告栏系统(BBS)，它可以根据用户请求与服务器进行交互，动态加载每篇文章的信息，而不是一次性从服务器载入所有文章信息。每篇文章有四个相关属性：系统中可以作为唯一标识的ID、发贴人姓名、文章内容以及包含其所有子文章ID的数组信息。首先假定有一个名为getArticle()的函数可以加载一篇文章信息。该函数接收的参数是要加载文章的ID，通过它可从服务器获取文章信息。它返回的对象包含与文章相关的四条属性：id，name，content和children。例程如下：
function ( id ) {
var a = getArticle(id);
document.writeln(a.name + "
" + a.content);
}
然而你也许会注意到，重复用同一个文章ID调用此函数，需要与服务器之间进行反复且无益的通信。想要解决这个问题，可以考虑使用函数 getArticleWithCache()，它相当于一个带有缓存能力的getArticle()。在这个例子中，getArticle()返回的数据只是作为一个全局变量被保存下来：
var cache = {};
function getArticleWithCache ( id ) {
if ( !cache[id] ) {
cache[id] = getArticle(id);
}
return cache[id];
}
现在已将读入的文章缓存起来，让我们再来考虑一下函数backgroundLoad()，它应用我们上面提到的缓存机制加载所有文章信息。其用途是，当读者在阅读某篇文章时，从后台预加载它所有子文章。因为文章数据是树状结构的，所以很容易写一个递归的算法来遍历树并且加载所有的文章：
function backgroundLoad ( ids ) {
for ( var i=0; i < ids.length; i++ ) {
var a = getArticleWithCache(ids[i]);
backgroundLoad(a.children);
}
}
backgroundLoad ()函数接收一个ID数组作为参数，然后通过每个ID调用前面定义过的getArticldWithCache()方法，这样就把每个ID对应的文章缓存起来。之后再通过已加载文章的子文章ID数组递归调用backgroundLoad()方法，如此整个文章树就被缓存起来。
到目前为止，一切似乎看起来都很完美。然而，只要你有过开发AJAX应用的经验，你就应该知晓这种幼稚的实现方法根本不会成功，这个例子成立的基础是默认 getArticle()用的是同步通信。可是，作为一条基本原则，JavaScript要求在与服务器进行交互时要用异步通信，因为它是单线程的。就简单性而言，把每一件事情（包括GUI事件和渲染）都放在一个线程里来处理是一个很好的程序模型，因为这样就无需再考虑线程同步这些复杂问题。另一方面，他也暴露了应用开发中的一个严重问题，单线程环境看起来对用户请求响应迅速，但是当线程忙于处理其它事情时(比如说调用getArticle())，就不能对用户的鼠标点击和键盘操作做出响应。
如果在这个单线程环境里进行同步通信会发生什么事情呢？同步通信会中断浏览器的执行直至获得通信结果。在等待通信结果的过程中，由于服务器的调用还没有完成，线程会停止响应用户并保持锁定状态直到调用返回。因为这个原因，当浏览器在等待服务器响应时它不能对用户行为作出响应，所以看起来像是冻结了。当执行 getArticleWithCache()和backgroundLoad()会有同样的问题，因为它们都是基于getArticle()函数的。由于下载所有的文章可能会耗费很可观的一段时间，因此对于backgroundLoad()函数来说，浏览器在此段时间内的冻结就是一个很严重的问题——既然浏览器都已经冻结，当用户正在阅读文章时就不可能首先去执行后台预加载数据，如果这样做连当前的文章都没办法读。
如上所述，既然同步通信在使用中会造成如此严重的问题，JavaScript就把异步通信作为一条基本原则。因此，我们可以基于异步通信改写上面的程序。 JavaScript要求以一种事件驱动的程序设计方式来写异步通信程序。在很多场合中，你都必须指定一个回调程序，一旦收到通信响应，这个函数就会被调用。例如，上面定义的getArticleWithCache()可以写成这样：
var cache = {};
function getArticleWithCache ( id, callback ) {
if ( !cache[id] ) {
callback(cache[id]);
} else {
getArticle(id, function( a ){
cache[id] = a;
callback(a);
});
}
}
这个程序也在内部调用了getArticle()函数。然而需要注意的是，为异步通信设计的这版getArticle()函数要接收一个函数作为第二个参数。当调用这个getArticle()函数时，与从前一样要给服务器发送一个请求，不同的是，现在函数会迅速返回而非等待服务器的响应。这意味着，当执行权交回给调用程序时，还没有得到服务器的响应。如此一来，线程就可以去执行其它任务直至获得服务器响应，并在此时调用回调函数。一旦得到服务器响应， getArticle()的第二个参数作为预先定义的回调函数就要被调用，服务器的返回值即为其参数。同样的，getArticleWithCache ()也要做些改变，定义一个回调参数作为其第二个参数。这个回调函数将在被传给getArticle()的回调函数中调用，因而它可以在服务器通信结束后被执行。
单是上面这些改动你可能已经认为相当复杂了，但是对backgroundLoad()函数做得改动将会更复杂，它也要被改写成可以处理回调函数的形式：
function backgroundLoad ( ids, callback ) {
var i = 0;
function l ( ) {
if ( i < ids.length ) {
getArticleWithCache(ids[i++], function( a ){
backgroundLoad(a.children, l);
});
} else {
callback();
}
}
l();
}
改动后的backgroundLoad()函数看上去和我们以前的那个函数已经相去甚远，不过他们所实现的功能并无二致。这意味着这两个函数都接受ID数组作为参数，对于数组里的每个元素都要调用getArticleWithCache()，再应用已经获得子文章ID递归调用backgroundLoad ()。不过同样是对数组的循环访问，新函数中的就不太好辨认了，以前的程序中是用一个for循环语句完成的。为什么实现同样功能的两套函数是如此的大相径庭呢？
这个差异源于一个事实：任何函数在遇到有需要同服务器进行通信情况后，都必须立刻返回，例如getArticleWithCache()。除非原来的函数不在执行当中，否则应当接受服务器响应的回调函数都不能被调用。对于JavaScript，在循环过程中中断程序并在稍后从这个断点继续开始执行程序是不可能的，例如一个for语句。因此，本例利用递归传递回调函数实现循环结构而非一个传统循环语句。对那些熟悉连续传送风格(CPS)的人来说，这就是一个 CPS的手动实现，因为不能使用循环语法，所以即便如前面提到的遍历树那么简单的程序也得写得很复杂。与事件驱动程序设计相关的问题是控制流问题：循环和其它控制流表达式可能比较难理解。
这里还有另外一个问题：如果你把一个没有应用异步通信的函数转换为一个使用异步通信的函数，那么重写的函数将需要一个回调函数作为新增参数，这为已经存在的APIs造成了很大问题，因为内在的改变没有把影响限于内部，而是导致整体混乱的APIs以及API的其它使用者的改变。
造成这些问题目的根本原因是什么呢？没错，正是JavaScript单线程机制导致了这些问题。在单线程里执行异步通信需要事件驱动程序设计和复杂的语句。如果当程序在等待服务器的响应时，有另外一个线程可以来处理用户请求，那么上述复杂技术就不需要了。
让我来介绍一下Concurrent.Thread，它是一个允许JavaScript进行多线程编程的库，应用它可以大大缓解上文提及的在AJAX开发中与异步通信相关的困难。这是一个用JavaScript写成的免费的软件库，使用它的前提是遵守Mozilla Public License和GNU General Public License这两个协议。你可以从他们的网站 下载源代码。
马上来下载和使用源码吧！假定你已经将下载的源码保存到一个名为Concurrent.Thread.js的文件夹里，在进行任何操作之前，先运行如下程序，这是一个很简单的功能实现：
<script type="text/javascript" src="Concurrent.Thread.js"></script>
<script type="text/javascript">
Concurrent.Thread.create(function(){
var i = 0;
while ( 1 ) {
document.body.innerHTML += i++ + "<br>";
}
});
</script>执行这个程序将会顺序显示从0开始的数字，它们一个接一个出现，你可以滚屏来看它。现在让我们来仔细研究一下代码，他应用while(1)条件制造了一个不会中止的循环，通常情况下，象这样不断使用一个并且是唯一一个线程的JavaScript程序会导致浏览器看起来象冻结了一样，自然也就不会允许你滚屏。那么为什么上面的这段程序允许你这么做呢？关键之处在于while(1)上面的那条Concurrent.Thread.create()语句，这是这个库提供的一个方法，它可以创建一个新线程。被当做参数传入的函数在这个新线程里执行，让我们对程序做如下微调：
<script type="text/javascript" src="Concurrent.Thread.js"></script>
<script type="text/javascript">
function f ( i ){
while ( 1 ) {
document.body.innerHTML += i++ + "<br>";
}
}
Concurrent.Thread.create(f, 0);
Concurrent.Thread.create(f, 100000);
</script> 在这个程序里有个新函数f()可以重复显示数字，它是在程序段起始定义的，接着以f()为参数调用了两次create()方法，传给create()方法的第二个参数将会不加修改地传给f()。执行这个程序，先会看到一些从0开始的小数，接着是一些从100,000开始的大数，然后又是接着前面小数顺序的数字。你可以观察到程序在交替显示小数和大数，这说明两个线程在同时运行。
让我来展示Concurrent.Thread的另外一个用法。上面的例子调用create()方法来创建新线程。不调用库里的任何APIs也有可能实现这个目的。例如，前面那个例子可以这样写：
<script type="text/javascript" src="Concurrent.Thread.js"></script>
<script type="text/x-script.multithreaded-js">
var i = 1;
while ( 1 ) {
document.body.innerHTML += i++ + "<br>";
}
</script> 在script 标签内，很简单地用JavaScript写了一个无穷循环。你应该注意到标签内的type属性，那里是一个很陌生的值(text/x- script.multithreaded-js)，如果这个属性被放在script标签内，那么Concurrent.Thread就会在一个新的线程内执行标签之间的程序。你应当记住一点，在本例一样，必须将Concurrent.Thread库包含进来。
有了Concurrent.Thread，就有可能自如的将执行环境在线程之间进行切换，即使你的程序很长、连续性很强。我们可以简要地讨论下如何执行这种操作。简言之，需要进行代码转换。粗略地讲，首先要把传递给create()的函数转换成一个字符串，接着改写直至它可以被分批分次执行。然后这些程序可以依照调度程序逐步执行。调度程序负责协调多线程，换句话说，它可以在适当的时候做出调整以便每一个修改后的函数都会得到同等机会运行。 Concurrent.Thread实际上并没有创建新的线程，仅仅是在原本单线程的基础上模拟了一个多线程环境。
虽然转换后的函数看起来是运行在不同的线程内，但是实际上只有一个线程在做这所有的事情。在转换后的函数内执行同步通信仍然会造成浏览器冻结，你也许会认为以前的那些问题根本就没有解决。不过你不必耽心，Concurrent.Thread提供了一个应用JavaScript 的异步通信方式实现的定制通信库，它被设计成当一个线程在等待服务器的响应时允许其它线程运行。这个通信库存于 Concurrent.Thread.Http下。它的用法如下所示：
<script type="text/javascript" src="Concurrent.Thread.js"></script>
<script type="text/x-script.multithreaded-js">
var req = Concurrent.Thread.Http.get(url, ["Accept", "*"]);
if (req.status == 200) {
alert(req.responseText);
} else {
alert(req.statusText);
}
</script> get()方法，就像它的名字暗示的那样，可以通过HTTP的GET方法获得指定URL的内容，它将目标URL作为第一个参数，将一个代表HTTP请求头的数组作为可选的第二个参数。get()方法与服务器交互，当得到服务器的响应后就返回一个XMLHttpRequest对象作为返回值。当get()方法返回时，已经收到了服务器响应，所以就没必要再用回调函数接收结果。自然，也不必再耽心当程序等待服务器的响应时浏览器冻结的情况了。另外，还有一个 post()方法可以用来发送数据到服务器：
<script type="text/javascript" src="Concurrent.Thread.js"></script>
<script type="text/x-script.multithreaded-js">
var req = Concurrent.Thread.Http.post(url, "key1=val1&key2=val2");
alert(req.statusText);
</script> post()方法将目的URL作为第一个参数，要发送的内容作为第二个参数。像get()方法那样，你也可以将请求头作为可选的第三个参数。
如果你用这个通信库实现了第一个例子当中的getArticle()方法，那么你很快就能应用文章开头示例的那种简单的方法写出getArticleWithCache(),backgroundLoad ()以及其它调用了getArticle()方法的函数了。即使是那版backgroundLoad()正在读文章数据，照例还有另外一个线程可以对用户请求做出响应，浏览器因此也不会冻结。现在，你能理解在JavaScript中应用多线程有多实用了？
我向你介绍了一个可以在JavaScript中应用多线程的库：Concurrent.Thread。这篇文章的内容只是很初级的东西，如果你想更深入的了解，我推荐您去看the tutorial。它提供有关Concurrent.Thread用法的更多内容，并列出了可供高级用户使用的文档，是最适合起步的材料。访问他们的网站也不错，那里提供更多信息。
标签：
原文地址：http://www.cnblogs.com/architects/p/4390671.html
