JavaScript的那些坑之单线程

看了下面的评论，才知道考的js的单线程，而之前对于单线程也没多少了解，所以就趁着这个机会好好整理整理单线程的知识点。

setTimeout(function(){  
         /* 代码块... */
         setTimeout(arguments.callee, 10);
}, 10);
  setInterval(function(){
         /*代码块... */
 }, 10);

JS是单线程的

JS运行在浏览器中，所以是单线程的，即每个window一个JS线程。
单线程在程序执行时，所走的程序路径按照连续顺序排下来，前面的必须处理好，后面的才会执行。
而浏览器是事件驱动的（Event driven），浏览器中很多行为是异步的，会创建事件并放入执行队列中。JS的引擎是单线程处理它的任务队列，你可以理解成就是普通函数和回调函数构成的队列。当异步事件发生时，如mouse click（鼠标点击事件发生）, a timer firing（定时器触发事件发生）, or an XMLHttpRequest completing（XMLHttpRequest完成回调触发等），将他们放入执行队列，等待当前代码执行完成。

异步事件驱动

浏览器是事件驱动的，但是也有很多的行为是异步的。当一个异步事件发生的时候，它就进入事件队列。比如setTimeout，当调用的时候，js引擎会启动定时器timer，大约xxms以后执行xxx，当定时器时间到，就把该事件放到主事件队列等待处理（浏览器不忙的时候才会真正执行）。

setTimeout执行原理

setTimeout的时间延迟不能被保证。比如setTimeout(fn, 500)并不代表fn肯定在500毫秒之后马上就执行，延迟很可能会更长。

              16.7ms

DELAY : |------------|

CLOCK: |----------|----------|
         15.6ms    15.6ms
IE8及其之前的IE版本更新间隔为15.6毫秒。假设你设定的setTimeout延迟为16.7ms，那么它要更新两个15.6毫秒才会该触发延时。这也意味着无故延迟了 15.6 x 2 - 16.7 = 14.5毫秒。

所以即使你给setTimeout设定的延时为0ms，它也不会立即触发。就算timer resolution能够达到16.7ms，它还要面临一个异步队列的问题。因为异步的关系setTimeout中的回调函数并非立即执行，而是需要加入等待队列中。但问题是，如果在等待延迟触发的过程中，有新的同步脚本需要执行，那么同步脚本不会排在timer的回调之后，而是立即执行。所以setTimeout的回调函数还要接着等待。

再回到刚才的题目，乍一看两段代码没什么不同，setTimeout回调函数的执行和上一次执行之间的间隔至少有10ms（可能会更多，因为会在等待队列里等待，但不会少于10ms），而setInterval的回调函数将尝试每隔10ms执行一次，不论上次是否执行完毕。

总结

• JavaScript引擎是单线程的，强制所有的异步事件排队等待执行
• setTimeout 和 setInterval 在执行异步代码的时候有着根本的不同
  
• 如果一个计时器被阻塞而不能立即执行，它将延迟执行直到下一次可能执行的时间点才被执行（比期望的时间间隔要长些）
  
• 如果setInterval回调函数的执行时间将足够长（比指定的时间间隔长），它们将连续执行并且彼此之间没有时间间隔。