深入理解JavaScript单线程模型与定时器运行机制

JavaScript单线程模型与定时器误区

例如

 
setTimeout( function(){ alert('你好!'); } , 0);
setInterval( callbackFunction , 100);

许多人依据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引擎线程、界面渲染线程和浏览器事件触发线程，此外还有如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(function(){
/* 代码块... */
setTimeout(arguments.callee, 10);
}, 10);
setInterval(function(){
/*代码块... */
}, 10);

这两段代码看起来效果一样，其实并非如此。第一段中回调函数内的setTimeout是JavaScript引擎执行后再设置新的setTimeout定时。假定上一个回调处理完到下一个回调开始处理为一个时间间隔，理论两个setTimeout回调执行时间间隔>=10ms。第二段自setInterval设置定时后，定时触发线程就会源源不断地每隔十秒产生异步定时事件并放到任务队列尾，理论上两个setInterval回调执行时间间隔<=10.

许多同学朋友搞不清楚，既然说JavaScript是单线程运行的，那么XMLHttpRequest在连接后是否真的异步？

其实请求确实是异步的，不过这请求是由浏览器新开一个线程请求（参见上图）。当请求的状态变更时，如果先前已设置回调，这异步线程就产生状态变更事件放到JavaScript引擎的处理队列中等待处理。当任务被处理时，JavaScript引擎始终是单线程运行回调函数，具体点即还是单线程运行onreadystatechange所设置的函数。