javascript线程解释（setTimeout,setInterval你不知道的事）

2013-10-07 03:06 youxin 阅读(8128) 评论(2) 编辑收藏举报

john resig写的一篇文章：

原文地址：http://ejohn.org/blog/how-javascript-timers-work/

作为入门者来说，了解JavaScript中timer的工作方式是很重要的。通常它们的表现行为并不是那么地直观，而这是因为它们都处在一个单一线程中。让我们先来看一看三个用来创建以及操作timer的函数。

var id = setTimeout(fn, delay); - 初始化一个单一的timer，这个timer将会在一定延时后去调用指定的函数。这个函数（setTimeout）将返回一个唯一的ID，我们可以通过这个ID来取消timer。
var id = setInterval(fn, delay); - 与setTimeout类似，只不过它会持续地调用指定的函数（每次都有一个延时），直到timer被取消为止。
clearInterval(id);, clearTimeout(id); - 接受一个timer的ID（由上述的两个函数返回的），并且停止timer的回调事件。

要搞明白timer在内部是怎么工作的，我们还需要知道一个很重要的概念：：定时器的延时是没有保证的。由于所有在游览器执行的js都是单线程异步事件(比如鼠标单击和定时器)，执行过程中只有在有空闲的时候才会被执行。通过下图可以很好的说明这一观点：

在上图中有很多信息是需要好好去消化下的，完全理解会让你对js的异步工作有更好的认识。上面图表是一维的：垂直表示时间，按毫秒计算。蓝色的盒子表示正在执行的部分js。如第一个js块执行的时间大约为18ms，鼠标点击块执行的时间大约为11ms,等等。
因为js只能在某一时刻执行一小段代码(由于它的单线程天性)，这些执行代码块中的每个都会"阻塞"其他异步事件的进行。这意味着当一个异步事件发生时(如鼠标单击事件，定时器触发，或者异步请求完成时)，它会排队等待执行(至于队列实际上是如何排列的,想必各个游览器表现都会不一样，所以这样考虑是一个简化)。

刚开始，在第一个JavaScript块中，有两个timer被初始化了：一个10ms的setTimeout和一个是10ms的setInterval。由于timer（这里的timer指setTimeout中的 timer，而下文中的interval则指setInvertal中的timer）开始的时间，实际上它在第一个代码块结束前就已经触发了。然而请注意，它并不会马上执行（事实上由于单线程的关系，它也无法做到马上执行）。相反的，这个被延期执行的函数进入队列中，等待在空闲的时候被执行。

此外，在第一个代码块里,我们看到一个鼠标单击事件发生。一个js回调函数被绑定于这个异步事件(我们不知道用户何时会点击，所以这被认为是异步的)，但不会被马上执行，它像开始的那个定时器一样，会进入队列等待执行。

在第一个js代码块初始化完成后，游览器会立刻询问：谁正在等待执行啊？这种情况下，鼠标单击事件处理函数和定时器回调函数正在等待执行。然后游览器挑选一个(鼠标单击事件处理函数)马上执行，定时器回调函数继续等待下一个可能的时间去执行。

注意当鼠标点击事件正在执行的时候第一次的interval事件也触发了，与timer一样，它的事件也进入队列等待之后执行。然而，注意，当interval再次触发的时候（这个时候timer的事件正在执行），这一次它的事件被丢弃了。如果你在一个大的JavaScript代码块正在执行的时候把所有的interval回调函数都囤起来的话，其结果就是在JavaScript代码块执行完了之后会有一堆的interval事件被执行，而执行过程中不会有间隔。因此，取代的作法是浏览器情愿先等一等，以确保在一个interval进入队列的时候队列中没有别的interval。

事实上，我们可以在例子中看出：当第三个interval触发的时候这个interval自身正在执行。这告诉我们一个重要的事实：interval是不管当前在执行些什么的，在任何情况下它都会进入到队列中去，即使这样意味着每次回调之间的时间就不准确了。

最后，当第二个interval回调执行完后，我们可以看到队列已经被清空，没有什么需要JavaScript引擎去执行的了。这表明浏览器现在等待一个新的异步事件发生。于是在50ms的时候我们看到interval又触发了。这一样，由于没有什么东西挡住了它的执行，它马上就触发了。

让我们来看一个例子，这个例子更好地阐释了setTimeout和setInveral之间的区别。

  setTimeout(function(){
    // 一个很长的代码块……
   setTimeout(arguments.callee, 10);
  }, 10);

  setInterval(function(){
    //一个很长的代码块……
  }, 10);

乍看上去，这两段代码在功能上似乎是相同的，可实际上并非如此。setTimeout的代码在前一次的回调执行完后总是至少会有10ms的延时（有可能会更多，但是绝对不会更少）；而setInterval则总是在每10ms的时候尝试执行一次回调，它不管上一次回调是什么时候执行的。

我们在此学到了很多，让我们重述一下：

JavaScript引擎只有一个线程，这使得异步事件必需列队等待执行。
setTimeout和setInterval在如何执行代码上有着本质地区别。
如果一个timer在将要执行的时候被阻塞，它将会等待下一个时机（比预期的延时要长）。
如果interval的执行时间较长（比指定的延时长），那么它们将连续地执行而没有延时。

以上这些知识是相当重要的。知道JavaScript引擎的工作方式，尤其是知道它在有很多异步事件发生的时候是怎么工作的，为我们在写进阶的应用程序代码打下了坚实的基础。

某人总结：

总结如下：

JavaScript engines only have a single thread, forcing asynchronous events to queue waiting for execution.
setTimeout and setInterval are fundamentally different in how they execute asynchronous code.
If a timer is blocked from immediately executing it will be delayed until the next possible point of execution (which will be longer than the desired delay).
Intervals may execute back-to-back with no delay if they take long enough to execute (longer than the specified delay).

无论是setTimeout还是setInterval，触发时，如果当前进程不为空，都得去排队等待执行，这一点上是无差异的。
区别是，setTimeout只需排一次队，setInterval则需要按照预设的间隔时间，每到时间点都去排一下。
setInterval去排队时，如果发现自己还在队列中未执行，则会被drop掉。也就是说，同一个inerval，在队列里只会有一个。
因为队列机制，无论是setTimeout还是setInterval，第一次触发时的时间，只会等于大于预设时间，不可能小于。
对于setInterval来说，如果执行时间大于预设间隔时间，很可能导致连续执行，中间没有时间间隔，这是很糟糕的，很可能会耗费大量cpu.

因此，对于动画来说，如果单帧的执行时间大于间隔时间，用setTimeout比用setInterval更保险。John Resig在回复中也表明了这个观点：

It really depends on the situation – and how the timers are actually being used. setInterval will, most likely, get you more ‘frames’ in the animation but will certainly tax your processor more. A lot of frameworks end up using setTimeout since it degrades more gracefully on slower computers.

一个简单的测试页面：timer_test.html（请在Chrome下运行，注意那些零值或接近零的值，setInterval没有interval了！）

因此，在这种情况下，采用setTimeout更保险：

setTimeout(function(){ setTimeout(arguments.callee, 10); }, 10);

当然，大部分情况下，单帧执行时间都小于预设的间隔时间，上面分析的差异，是感觉不大出来的。

------------------------

一道JavaScript面试题（setTimeout）

下面的代码，多久之后会弹出'end'？为什么？

var t = true;

setTimeout(function(){ t = false; }, 1000);

while(t){ }

alert('end');
这是以前在想有没办法实现阻塞javascript线程的时候（即实现sleep方法），想过的一种实现。

很简单，是吧？

是吗?

答案是：典型的死循环……js是单线程执行的，while里面死掉的时候setTimeout里面的函数是没机会执行的。

1、简单的settimeout

        setTimeout(function () { while (true) { } }, 1000);
        setTimeout(function () { alert('end 2'); }, 2000);
        setTimeout(function () { alert('end 1'); }, 100);
        alert('end');

执行的结果是弹出‘end’‘end 1’，然后浏览器假死，就是不弹出‘end 2’。也就是说第一个settimeout里执行的时候是一个死循环，这个直接导致了理论上比它晚一秒执行的第二个settimeout里的函数被阻塞，这个和我们平时所理解的异步函数多线程互不干扰是不符的。

2、ajax请求回调

接着我们来测试一下通过xmlhttprequest实现ajax异步请求调用，主要代码如下：

        var xmlReq = createXMLHTTP();//创建一个xmlhttprequest对象
        function testAsynRequest() {
            var url = "/AsyncHandler.ashx?action=ajax";
            xmlReq.open("post", url, true);
            xmlReq.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
            xmlReq.onreadystatechange = function () {
                if (xmlReq.readyState == 4) {
                    if (xmlReq.status == 200) {
                        var jsonData = eval('(' + xmlReq.responseText + ')');
                        alert(jsonData.message);
                    }
                    else if (xmlReq.status == 404) {
                        alert("Requested URL is not found.");
                    } else if (xmlReq.status == 403) {
                        alert("Access denied.");
                    } else {
                        alert("status is " + xmlReq.status);
                    }
                }
            };
            xmlReq.send(null);
        }
        testAsynRequest();//1秒后调用回调函数
        
        while (true) {

        }

在服务端实现简单的输出：

        private void ProcessAjaxRequest(HttpContext context)
        {
            string action = context.Request["ajax"];
            Thread.Sleep(1000);//等1秒
            string jsonObject = "{\"message\":\"" + action + "\"}";
            context.Response.Write(jsonObject);
        }

理论上，如果ajax异步请求，它的异步回调函数是在单独一个线程中，那么回调函数必然不被其他线程”阻挠“而顺利执行，也就是1秒后，它回调执行弹出‘ajax’，可是实际情况并非如此，回调函数无法执行，因为浏览器再次因为死循环假死。

结论：根据实践结果，可以得出，javascript引擎确实是单线程处理它的任务队列（能理解成就是普通函数和回调函数构成的队列吗？）的。在javascript里实现异步编程很大程度上就是一种障眼法，单线程的引擎实现多线程的编程，如果要实现一些资源同步互斥之类的操作（一如C#、Java等语言的多线程），我感觉真正实现起来根本无法轻易得到保证。

补充：如何实现javascript的sleep呢？在stackoverflow上找到一篇javascript sleep，试了一下，效果是有了，但是执行的时候cpu很高，真还不如直接settimeout呢。

转自：http://www.cnblogs.com/jeffwongishandsome/archive/2011/06/13/2080145.html

深入理解JavaScript定时机制

容易欺骗别人感情的JavaScript定时器

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引擎与另外那些线程是怎样互动通信的.虽然每个浏览器内核实现细节不同,但这其中的调用原理都是大同小异.

Js线程图示

由图可看出,浏览器中的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.

案例2:ajax异步请求是否真的异步?

很多同学朋友搞不清楚,既然说JavaScript是单线程运行的,那么XMLHttpRequest在连接后是否真的异步?
其实请求确实是异步的,不过这请求是由浏览器新开一个线程请求(参见上图),当请求的状态变更时,如果先前已设置回调,这异步线程就产生状态变更事件放到JavaScript引擎的处理队列中等待处理,当任务被处理时,JavaScript引擎始终是单线程运行回调函数,具体点即还是单线程运行onreadystatechange所设置的函数.

-------------------------------

转自：http://www.cnblogs.com/dolphinX/archive/2013/04/05/2784933.html

setTimeout()和setInterval()经常被用来处理延时和定时任务。setTimeout() 方法用于在指定的毫秒数后调用函数或计算表达式,而setInterval()则可以在每隔指定的毫秒数循环调用函数或表达式，直到clearInterval把它清除。

从定义上我们可以看到两个函数十分类似，只不过前者执行一次，而后者可以执行多次，两个函数的参数也相同，第一个参数是要执行的code或句柄，第二个是延迟的毫秒数。

很简单的定义，使用起来也很简单，但有时候我们的代码并不是按照我们的想象精确时间被调用的，很让人困惑

简单示例

看个简单的例子,简单页面在加载完两秒后，写下Delayed alert!

setTimeout('document.write("Delayed alert!");', 2000);

看起来很合理，我们再看个setInterVal()方法的例子

var num = 0;
        var i = setInterval(function() {
            num++;
            var date = new Date();
            document.write(date.getMinutes() + ':' + date.getSeconds() + ':' + date.getMilliseconds() + '<br>');
            if (num > 10)
                clearInterval(i);
        }, 1000);

页面每隔1秒记录一次当前时间（分钟：秒：毫秒），记录十次后清除，不再记录。考虑到代码执行时间可能记录的不是执行时间，但时间间隔应该是一样的，看看结果

43:38:116
43:39:130
43:40:144
43:41:158
43:42:172
43:43:186
43:44:200
43:45:214
43:46:228
43:47:242
43:48:256

为什么

时间间隔几乎是1000毫秒，但不精确，这是为什么呢？原因在于我们对JavaScript定时器存在一个误解，JavaScript其实是运行在单线程的环境中的，这就意味着定时器仅仅是计划代码在未来的某个时间执行，而具体执行时机是不能保证的，因为页面的生命周期中，不同时间可能有其他代码在控制JavaScript进程。在页面下载完成后代码的运行、事件处理程序、Ajax回调函数都是使用同样的线程，实际上浏览器负责进行排序，指派某段程序在某个时间点运行的优先级。

我们把效果放大一下看看，添加一个耗时的任务

function test() {
            for (var i = 0; i < 500000; i++) {
                var div = document.createElement('div');
                div.setAttribute('id', 'testDiv');
                document.body.appendChild(div);
                document.body.removeChild(div);
            }
        }
        setInterval(test, 10);
        var num = 0;
        var i = setInterval(function() {
            num++;
            var date = new Date();
            document.write(date.getMinutes() + ':' + date.getSeconds() + ':' + date.getMilliseconds() + '<br>');
            if (num > 10)
                clearInterval(i);
        }, 1000);

我们又加入了一个定时任务，看看结果

47:9:222
47:12:482
47:16:8
47:19:143
47:22:631
47:25:888
47:28:712
47:32:381
47:34:146
47:35:565
47:37:406

这下效果明显了，差距甚至都超过了3秒，而且差距很不一致。

我们可以可以把JavaScript想象成在时间线上运行。当页面载入的时候首先执行的是页面生命周期后面要用的方法和变量声明和数据处理，在这之后JavaScript进程将等待更多代码执行。当进程空闲的时候，下一段代码会被触发

除了主JavaScript进程外，还需要一个在进程下一次空闲时执行的代码队列。随着页面生命周期推移，代码会按照执行顺序添加入队列，例如当按钮被按下的时候他的事件处理程序会被添加到队列中，并在下一个可能时间内执行。在接到某个Ajax响应时，回调函数的代码会被添加到队列。JavaScript中没有任何代码是立即执行的，但一旦进程空闲则尽快执行。定时器对队列的工作方式是当特定时间过去后将代码插入，这并不意味着它会马上执行，只能表示它尽快执行。

知道了这些后，我们就能明白，如果想要精确的时间控制，是不能依赖于JavaScript的setTimeout函数的。

重复的定时器

使用 setInterval() 创建的定时器可以使代码循环执行，到有指定效果的时候，清除interval就可以，如下例

var my_interval = setInterval(function () {
            if (condition) {
                //..........
            } else {
                clearInterval(my_interval);
            }
        }, 100);

但这个方式的问题在于定时器的代码可能在代码再次被添加到队列之前还没有执行完成，结果导致循环内的判断条件不准确，代码多执行几次，之间没有停顿。不过JavaScript已经解决这个问题，当使用setInterval（）时，仅当没有该定时器的其他代码实例时才将定时器代码插入队列。这样确保了定时器代码加入到队列的最小时间间隔为指定间隔。

这样的规则带来两个问题

1. 某些间隔会被跳过
2.多个定时器的代码执行之间的间隔可能比预期要小

为了避免这两个缺点，我们可以使用setTimeout（）来实现重复的定时器

setTimeout(function () {
            //code
            setTimeout(arguments.callee, interval);
        }, interval)

这样每次函数执行的时候都会创建一个新的定时器，第二个setTimeout（）调用使用了agrument.callee 来获取当前实行函数的引用，并设置另外一个新定时器。这样做可以保证在代码执行完成前不会有新的定时器插入，并且下一次定时器代码执行之前至少要间隔指定时间，避免连续运行。

setTimeout(function () {
            var div = document.getElementById('moveDiv');
            var left = parseInt(div.style.left) + 5;
            div.style.left = left + 'px';
            if (left < 200) {
                setTimeout(arguments.callee, 50);
            }
        }, 50);

这段定时器代码每次执行的时候，把一个div向右移动5px，当坐标大于200的时候停止。

刷新页面返回顶部

有心故我在