大家先来看一道题：

a.onclick = function(){

setTimeout(function() {

//do something ...

},0);

};

JavaScript API 文档明确定义：setTimeout的第二个参数意义为隔多少毫秒后,回调方法就会被执行。那么可以推断出：这里设成0毫秒,就立即被执行了。

—————— 既然立即执行，为什么这段代码的作者为什么要 舍近求远？难道作者写代码的时候喝醉了？

显然不是！

这个问题 David Flanagan 在《Javascript 权威指南》中有阐述：当 setTimeout 的延迟时间设置为 0 的时候，回调函数不会马上执行，而是进入队列。

David Flanagan 在《Javascript权威指南》里并没有详细描述Javascript队列的具体运作方式，现在我来大致说一下这个问题。

JavaScript 引擎是单线程模式运行的，浏览器无论在什么时候都只且只有一个JavaScript线程在运行程序。

要说清楚这些问题，还得从浏览器内核处理定时器（setTimeout、setInterval）和响应浏览器事件说起。

浏览器内核实现允许多个线程异步执行，这些线程在内核制控下相互配合以保持同步。假设某一浏览器内核的实现至少有三个常驻线程：javascript引擎线程、界面渲染线程、浏览器事件触发线程。除些以外，也有一些执行完就终止的线程：如Http请求线程等，这些异步线程都会产生不同的异步事件。

下面通过一个图来阐明单线程的JavaScript引擎与另外那些线程是怎样互动通信的。虽然每个浏览器内核 （流行浏览器内核有：Trident[IE内核]、Gecko[Firefox内核]、Presto[Opera内核]、Webkit[Chrome、Safari] 等） 实现细节不同，但这其中的调用原理都是大同小异。

JavaScript定时机制、以及浏览器渲染机制 浅谈 javascript-thread

浏览器中的JavaScript引擎是基于事件驱动的。这里的事件可看作是浏览器派给它的各种任务，如调用setTimeout 添加一个任务，也可来自浏览器内核的其它线程，如界面元素鼠标点击事件、定时触发器时间到达通知、异步请求状态变更通知等。

从代码角度看来任务实体就是各种回调函数，JavaScript引擎一直等待着任务队列中任务的到来。由于单线程关系,这些任务得进行排队，一个接着一个被引擎处理。

图形界面渲染线程：

该线程负责渲染浏览器界面HTML元素，当界面需要重绘或由于某种操作引发回流时，该线程就会执行。

我今天想重点解释JavaScript定时机制，但这时有必要说说渲染线程，因为该线程与JavaScript引擎线程是互斥的！这一点Yahoo 前端攻城师在博客上有一篇详细文章描述这个问题。这也容易理解：因为JavaScript脚本是可操纵DOM元素，在修改这些元素属性同时渲染界面，那么渲染线程前后获得的元素数据就可能不一致了。

在JavaScript引擎运行脚本期间，浏览器渲染线程都是处于挂起状态的，也就是说被”冻结”了（题外话：YSlow优化网页建议指南指出：js文件要放在html内容的下面，就是因为加载 js 的时候，会阻塞 DOM树的构建。这一点可以再Yahoo工程师的前端优化方案里面看到）。

GUI事件触发线程：

JavaScript脚本的执行不影响html元素事件的触发，在Time1时间段内，用户点击鼠标键，点击事件被浏览器事件触发线程捕捉后，形成一个鼠标点击事件，对于JavaScript引擎线程来说，这事件是由其它线程异步传到任务队列尾的，由于引擎正在处理 Time1 时的任务，这个鼠标点击事件就会排队。

定时触发线程:

注意这里的浏览器模型定时计数器并不是由JavaScript引擎计数的，因为JavaScript引擎是单线程的，如果处于阻塞线程状态就不能计时，它必须依赖外部来计时并触发定时，所以队列中的定时事件也是异步事件。

更多信息请查看IT技术专栏