什么是 Event Loop?

作者: 阮一峰

日期: 2013年10月21日

[2014.10.08更新] 本文内容有错误,请参考新版本

Event Loop 是一个很重要的概念,指的是计算机系统的一种运行机制。

JavaScript语言就采用这种机制,来解决单线程运行带来的一些问题。

Event Loop

本文参考C. Aaron Cois的《Understanding The Node.js Event Loop》,解释什么是Event Loop,以及它与JavaScript语言的单线程模型有何关系。

想要理解Event Loop,就要从程序的运行模式讲起。运行以后的程序叫做"进程"(process),一般情况下,一个进程一次只能执行一个任务。

如果有很多任务需要执行,不外乎三种解决方法。

(1)排队。因为一个进程一次只能执行一个任务,只好等前面的任务执行完了,再执行后面的任务。

(2)新建进程。使用fork命令,为每个任务新建一个进程。

(3)新建线程。因为进程太耗费资源,所以如今的程序往往允许一个进程包含多个线程,由线程去完成任务。(进程和线程的详细解释,请看这里。)

以JavaScript语言为例,它是一种单线程语言,所有任务都在一个线程上完成,即采用上面的第一种方法。一旦遇到大量任务或者遇到一个耗时的任务,网页就会出现"假死",因为JavaScript停不下来,也就无法响应用户的行为。

你也许会问,JavaScript为什么是单线程,难道不能实现为多线程吗?

这跟历史有关系。JavaScript从诞生起就是单线程。原因大概是不想让浏览器变得太复杂,因为多线程需要共享资源、且有可能修改彼此的运行结果,对于一种网页脚本语言来说,这就太复杂了。后来就约定俗成,JavaScript为一种单线程语言。(Worker API可以实现多线程,但是JavaScript本身始终是单线程的。)

如果某个任务很耗时,比如涉及很多I/O(输入/输出)操作,那么线程的运行大概是下面的样子。

synchronous mode

上图的绿色部分是程序的运行时间,红色部分是等待时间。可以看到,由于I/O操作很慢,所以这个线程的大部分运行时间都在空等I/O操作的返回结果。这种运行方式称为"同步模式"(synchronous I/O)或"堵塞模式"(blocking I/O)。

如果采用多线程,同时运行多个任务,那很可能就是下面这样。

synchronous mode

上图表明,多线程不仅占用多倍的系统资源,也闲置多倍的资源,这显然不合理。

Event Loop就是为了解决这个问题而提出的。Wikipedia这样定义:

"Event Loop是一个程序结构,用于等待和发送消息和事件。(a programming construct that waits for and dispatches events or messages in a program.)"

简单说,就是在程序中设置两个线程:一个负责程序本身的运行,称为"主线程";另一个负责主线程与其他进程(主要是各种I/O操作)的通信,被称为"Event Loop线程"(可以译为"消息线程")。

asynchronous mode

上图主线程的绿色部分,还是表示运行时间,而橙色部分表示空闲时间。每当遇到I/O的时候,主线程就让Event Loop线程去通知相应的I/O程序,然后接着往后运行,所以不存在红色的等待时间。等到I/O程序完成操作,Event Loop线程再把结果返回主线程。主线程就调用事先设定的回调函数,完成整个任务。

可以看到,由于多出了橙色的空闲时间,所以主线程得以运行更多的任务,这就提高了效率。这种运行方式称为"异步模式"(asynchronous I/O)或"非堵塞模式"(non-blocking mode)。

这正是JavaScript语言的运行方式。单线程模型虽然对JavaScript构成了很大的限制,但也因此使它具备了其他语言不具备的优势。如果部署得好,JavaScript程序是不会出现堵塞的,这就是为什么node.js平台可以用很少的资源,应付大流量访问的原因。

(完)

珠峰培训

简寻

留言(41条)

这不是nodejs特有的机制,几乎所有语言都可以实现这个。所以“但也因此使它具备了其他语言不具备的优势。”,是错误的

异步和非阻塞是不同的概念

引用foo的发言:

这不是nodejs特有的机制,几乎所有语言都可以实现这个。所以“但也因此使它具备了其他语言不具备的优势。”,是错误的

我觉得可以这么说,JS默认使用这个机制,其它语言虽然支持而非默认。
比如Java需要网络访问,谁不是开一个新线程。

引用linbo的发言:

异步和非阻塞是不同的概念

确实是,同步和异步,阻塞和非阻塞,是两组不同的概念,两个之间没有必然的联系。

JavaScript在处理回调时也存在阻塞现象

这两天正在关注着方面的问题。正好解答了我的疑问!顶阮老师!哈哈

event loop只使用了一个线程,如果同时有多个并发的IO请求,那么这些请求也将在event loop线程中排队等待罗?

引用shawn的发言:

event loop只使用了一个线程,如果同时有多个并发的IO请求,那么这些请求也将在event loop线程中排队等待罗?

所以要用非阻塞

Python 可以用 gevent 来实现。

大哥这文章是给初级程序员看的吧?

阻塞有阻塞的好处,非阻塞有非阻塞的优势,有些非阻塞的消息,也需要主线程通过自旋来提取,其实耗费的也是大量的CPU。根据架构不同,生产场景不同,选择也不同。详见UNIX系统的IO模型

引用woosley的发言:

所以要用非阻塞

非阻塞的话就意味着多个线程,那这么我理解成用I/O完成端口,如果这样的话,就直接在主线程上好了,也是不阻塞,那么就不需要这个event loop线程了?

引用shawn的发言:

非阻塞的话就意味着多个线程,那这么我理解成用I/O完成端口,如果这样的话,就直接在主线程上好了,也是不阻塞,那么就不需要这个event loop线程了?

Python 的 Tornado 框架就只一个线程。

引用zhong的发言:

我觉得可以这么说,JS默认使用这个机制,其它语言虽然支持而非默认。
比如Java需要网络访问,谁不是开一个新线程。

所以 Node.js 用起来很别扭,各种回调。同步操作最重复的一点就是方便,这也是为什么大部分语言默认使用同步方式。这也是为什么现在流行协程的原因。

另外,同步访问不意味着必须开一个新进程或者进程,编程语言底层可以使用事件 I/O 来处理。比如 Haskell 的 I/O 线程和 Erlang 的进程。

同步IO != 阻塞IO

如果在前一个回调执行完之前,后一个回调来了,也就是说,event loop的两个回调在时间上有重叠的部分会怎么样?

感觉这里大多的做前端的,对后台没有什么感觉。其实 javascript 语言与 event loop 一点关系都没有。javascript 才没有用 event loop 呢? javascript 的一个库node.js 采用了 event loop。但不能说 javascript 采用了 event loop。

"简单说,就是在程序中设置两个线程:一个负责程序本身的运行,称为"主线程";..."

"每当遇到I/O的时候,主进程就让Event Loop进程去通知相应的I/O程序"

这里是不是有矛盾?是线程还是进程?

@尹良灿:

谢谢指出,我太疏忽了,已经改过来了。

深入浅出,浅显易懂啊!!使用dojo的人也觉得很有用,受益匪浅!

这么说Event Loop内部也是通过异步方式跟IO打交道,不然也会有红色等待阶段,而Event Loop依赖Worker API来实现的异步?

"每当遇到I/O的时候,主线程就让Event Loop线程去通知相应的I/O程序,然后接着往后运行..."
主线程去通知Event loop线程的时候,是不是依旧存在短暂的阻塞,把控制权交给了Event Loop?只是这个过程很短暂,可以忽略?

大神,图挂了呀。

是阻塞吧?

引用foo的发言:

这不是nodejs特有的机制,几乎所有语言都可以实现这个。所以“但也因此使它具备了其他语言不具备的优势。”,是错误的

这跟语言没关系,应该是系统提供的功能,比如unix的select,poll,linux下的epoll,BSD下的kqueue等等

不是說js是單線程嗎?怎麼會有主線程又有event loop線程,不是矛盾嗎?

阮老师,你好,我想请教一下,你最新写的那本书“JavaScript 标准参考教程(alpha)”这个是在github上用github page搭的,是项目page,我想请问下能否有相关的这样的教程,我尝试过很多次,都没成功。多谢~~

引用老許的发言:

不是說js是單線程嗎?怎麼會有主線程又有event loop線程,不是矛盾嗎?

我也想问这个……

说了这么长,还是多线程解决的问题

我的理解是Nodejs 你写的主代码是起点,结束后进入事件循环,这时候有个叫事件队列的数据结构里已经存在了一些需要处理的任务,这些任务可能还会发新的任务。这个事件循环怎么理解,我想象的就像一个人每天都要做同样的工作,天天如此,这就是循环。每天的工作就是先收集事件,然后处理事件(或者先处理后收集,谁知道)然后下一天.....

Nodejs里有process.nextTick()函数,tick的意思是滴答声,暗含的意思就是秒针走了一秒,每一个tick里,nodejs都可以做一堆的事,比如 收事件 处理事件,如果发现再也没有新的事件到来,那就退出.

在其他地方见过这篇文章,今天在这看到原创了,又细读了一次,觉着这种设计理念真是不错。

LOOP里如果有多个任务一样还会阻塞吧

我理解多线程,但是我没有看明白你的文章
我理解着你应该说的是 异步和回调

Event Loop线程再把结果返回主线程.
此句说了2个线程,我想"Event Loop线程"应该是你说的单线程.而主线程应该为另一个线程--浏览器线程

异步有异步的好处,但是如果后面的代码需要用到前面回调函数里得出的值时我们该怎样去处理呢,特别是在处理数据库的时候,数据库处理占用时间很大,但又必须的获得前面的数据。

wowwow
喜欢你的博客

引用依云的发言:

所以 Node.js 用起来很别扭,各种回调。同步操作最重复的一点就是方便,这也是为什么大部分语言默认使用同步方式。这也是为什么现在流行协程的原因。

另外,同步访问不意味着必须开一个新进程或者进程,编程语言底层可以使用事件 I/O 来处理。比如 Haskell 的 I/O 线程和 Erlang 的进程。

你去看看Promise规范,它可以用同步的习惯进行编程。

如果主线程一直没有结束,那么事件循环中的回调函数是不是一直没有机会得以执行呢?

引用shawn的发言:

event loop只使用了一个线程,如果同时有多个并发的IO请求,那么这些请求也将在event loop线程中排队等待罗?

是这样的。event loop只是让线程能一直处理该线程本身应该处理的东西,不会因为需要非本线程的资源而空闲。但如果线程本身就要处理多个运算的话,上一个运算没有结束,下一个运算是不会进行的。

node.js底层本身应该也是多线程的

引用学良的发言:

阻塞有阻塞的好处,非阻塞有非阻塞的优势,有些非阻塞的消息,也需要主线程通过自旋来提取,其实耗费的也是大量的CPU。根据架构不同,生产场景不同,选择也不同。详见UNIX系统的IO模型

顶!

引用ffflow的发言:

同步IO != 阻塞IO

请举例说明?

阮一峰的文章最大的有点在于其科普性和简洁性,我想这是阮一峰的真正目的。
最近看到很多抱怨文章深度不够,我想说,够深度的内容都在草案里,你们可以去找相关规范草案进行深度挖掘。
因此,阮一峰的博文就是一个字典。

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接