深入javascript计划七：深入浅出Event loop

关注

原创最新推荐文章于 2026-06-02 13:36:31 发布 340 阅读 AI 写同款· GEO 优化 ›

从D3 00到FF FF：手把手解析RTCM3.2协议帧结构（附Python解析代码）本文深入解析RTCM3.2协议帧结构，从同步头标识到CRC校验算法，详细讲解如何通过Python代码实现二进制数据解析。文章包含完整的RTCM3.2解析器实现，涵盖消息类型解码、CRC校验等关键步骤，并附赠特定消息类型（如1005型基准站坐标）的解析示例，帮助开发者快速掌握GNSS差分数据传输协议的核心技术。阅读详情

为什么javascript是单线程？

因为最初javascript就是为了和浏览器交互而诞生的，如果 JS 是门多线程的语言话，我们在多个线程中处理 DOM 就可能会发生问题（一个线程中新加节点，另一个线程中删除节点），当然可以引入读写锁解决这个问题，为了避免复杂性，设计者还是把它设计成单线程模式。

后来，HTML5提出Web Worker标准, 允许JavaScript脚本创建多个线程，但是子线程完全受主线程控制，且不得操作DOM，所以这个新标准并没有改变JavaScript单线程本质。

Event Loop（浏览器、node）

什么是Event Loop？

一句话总结：Event Loop就是javascript运行机制。

为什么要有Event Loop？

因为Javascript设计之初就是一门单线程语言，因此为了实现主线程的不阻塞，Event Loop这样的方案应运而生。

任务队列

单线程就意味着，所有任务需要排队，前一个任务结束，才会执行后一个任务。如果前一个任务耗时很长，后一个任务就不得不一直等着。

如果排队是因为计算量大，CPU忙不过来，倒也算了。

但是很多时候CPU是闲着的，因为IO设备（输入输出设备）很慢（比如Ajax操作从网络读取数据），不得不等着结果出来，再往下执行。

JavaScript语言的设计者意识到，这时主线程完全可以不管IO设备，挂起处于等待中的任务，先运行排在后面的任务。等到IO设备返回了结果，再回过头，把挂起的任务继续执行下去。

于是，所有任务可以分成两种，一种是同步任务（synchronous），另一种是异步任务（asynchronous）。

同步任务指的是：在主线程上排队执行的任务，只有前一个任务执行完毕，才能执行后一个任务。

异步任务指的是：不进入主线程、而进入"任务队列"（task queue）的任务，只有"任务队列"通知主线程，某个异步任务可以执行了，该任务才会进入主线程执行。

（1）所有同步任务都在主线程上执行，形成一个执行栈（execution context stack）。

（2）主线程之外，还存在一个"任务队列"（task queue）。只要异步任务有了运行结果，就在"任务队列"之中放置一个事件。

（3）一旦"执行栈"中的所有同步任务执行完毕，系统就会读取"任务队列"，看看里面有哪些事件。那些对应的异步任务，于是结束等待状态，进入执行栈，开始执行。

（4）主线程不断重复上面的第三步。

只要主线程空了，就会去读取"任务队列"，这就是JavaScript的运行机制。这个过程会不断重复。

任务队列分类

不同的任务源会被分配到不同的任务队列（task queue）中。

任务源可以分为 微任务（microtask-在 ES6 规范中，microtask 称为 jobs）和 宏任务（macrotask-在 ES6 规范中，macrotask 称为 task）。

浏览器的Event loop

微任务：promise、MutationObserver

宏任务：script、setTimeout、setInterval、requestAnimationFrame、I/O

Event loop 执行顺序：

执行同步代码（script标签里面的代码---main script），这属于宏任务
执行栈为空，查询是否有微任务需要执行
执行所有微任务
必要的话渲染 UI
然后开始下一轮 Event loop，执行宏任务，然后到第二步

总结：宏任务->微任务->宏任务->微任务（这样循环）直至执行栈为空

通过上述的 Event loop 顺序可知，如果宏任务中的异步代码有大量的计算并且需要操作 DOM 的话，为了更快的界面响应，我们可以把操作 DOM 放入微任务中。

好了，我们看例子：

console.log('执行 script start')

setTimeout(function() {
  console.log('执行 setTimeout')
}, 0)

new Promise(resolve => {
  console.log('执行 Promise')
  resolve("执行 promise resolve")
}).then(function(res) {
    console.log(res)
})

for(let i=0; i<10000; i++) {
    console.log(i)
}

console.log('执行 script end')

// 执行 script start
// 执行 Promise
// 0
// 1
// ...
// 9999
// 执行 script end
// 执行 promise resolve
// 执行 setTimeout

就不用讲解了，自行补充，如果有兴趣可以留言。

讲讲setTimeout

setTimeout() ：在指定的毫秒数后调用函数或计算表达式。

HTML5标准规定了setTimeout()的第二个参数的最小值（最短间隔），不得低于4毫秒，如果低于这个值，就会自动增加。

在此之前，老版本的浏览器都将最短间隔设为10毫秒。

另外，对于那些DOM的变动（尤其是涉及页面重新渲染的部分），通常不会立即执行，而是每16毫秒执行一次。

这时使用requestAnimationFrame()的效果要好于setTimeout()。

需要注意的是，setTimeout()只是将事件插入了"任务队列"，必须等到当前代码（执行栈）执行完，主线程才会去执行它指定的回调函数。要是当前代码耗时很长，有可能要等很久，所以并没有办法保证，回调函数一定会在setTimeout()指定的时间执行（看上面例子就知道了）。

讲讲setInterval

setInterval() ：指定某个任务每隔一段时间就执行一次，也就是无限次的定时执行，直到 clearInterval() 被调用或窗口被关闭。

HTML5标准规定了setInterval()的第二个参数的最小值（最短间隔），不得低于10毫秒，如果低于这个值，就会自动增加。

setInterval()将事件插入"任务队列"，跟settimeout一样。

讲讲requestAnimationFrame

requestAnimationFrame 比起 setTimeout、setInterval的优势主要有两点：

1、requestAnimationFrame 会把每一帧中的所有DOM操作集中起来，在一次重绘或回流（重排）中就完成，并且重绘或回流（重排）的时间间隔紧紧跟随浏览器的刷新频率，一般来说，这个频率为每秒60帧。

2、在隐藏或不可见的元素中，requestAnimationFrame将不会进行重绘或回流，这当然就意味着更少的的cpu，gpu和内存使用量。

如果你有循环定时器的需求，其实完全可以通过来requestAnimationFrame实现：

function setInterval(callback, interval) {
    let timer
    const now = Date.now
    let startTime = now()
    let endTime = startTime
    const loop = () => {
      timer = window.requestAnimationFrame(loop)
      endTime = now()
      if (endTime - startTime >= interval) {
        startTime = endTime = now()
        callback(timer)
      }
    }
    timer = window.requestAnimationFrame(loop)
    return timer
}
  
let a = 0
setInterval(timer => {
    console.log(1)
    a++
    if (a === 3) cancelAnimationFrame(timer)
}, 1000)

屏幕刷新频率：屏幕刷新率是指显示器的屏幕每秒钟会刷新多少次。

目前，大部分的显示器的刷新频率为60次/秒，也就是说，屏幕刷新的间隔时间为大约1000/60=16.67ms。

所以，一般来说，如果动画的执行频率跟屏幕的刷新频率一致，动画看起来就可以达到流畅的极限

首先 requestAnimationFrame 自带函数节流功能，基本可以保证在 16.6 毫秒内只执行一次（不掉帧的情况下），并且该函数的延时效果是精确的，没有其他定时器时间不准的问题，当然你也可以通过该函数来实现 setTimeout。

node的Event loop

我们都知道Node.js 是一个基于 Chrome V8 引擎的 JavaScript 运行环境，也就是能够让js在服务端运行。

但是Node中的Event Loop是用libuv模拟的，它将不同的任务分配给不同的线程，形成一个Event Loop，以异步的方式将任务的执行结果返回给V8引擎。

微任务：promise、process.nextTick、setImmediate

宏任务：script、setTimeout、setInterval、I/O

Node 中的 Event loop 和浏览器中的不相同，Node 的 Event Loop 分为 6 个阶段，它们会按照顺序反复运行。每当进入某一个阶段的时候，都会从对应的回调队列中取出函数去执行。当队列为空或者执行的回调函数数量到达系统设定的阈值，就会进入下一阶段。

timers

imers 阶段会执行 setTimeout（）和 setInterval（）回调，并且是由 poll 阶段控制的。

一个 timer 指定的时间并不是准确时间，而是在达到这个时间后尽快执行回调，可能会因为系统正在执行别的事务而延迟。

下限的时间有一个范围：[1, 2147483647] ，如果设定的时间不在这个范围，将被设置为 1。

I/O

I/O 阶段会执行除了 close 事件，定时器和 setImmediate 的回调。

idle, prepare

idle, prepare 阶段内部实现。

poll

poll 阶段很重要，这一阶段中，系统会做两件事情：

执行到点的定时器
执行 poll 队列中的事件

并且当 poll 中没有定时器的情况下，会发现以下两件事情：

如果 poll 队列不为空，会遍历回调队列并同步执行，直到队列为空或者系统限制
如果 poll 队列为空，会有两件事发生
- 如果有 setImmediate 需要执行，poll 阶段会停止并且进入到 check 阶段执行 setImmediate
- 如果没有 setImmediate 需要执行，会等待回调被加入到队列中并立即执行回调

如果有别的定时器需要被执行，会回到 timer 阶段执行回调。

check

check阶段执行setImmediat()的回调。

close callbacks

close callbacks 阶段执行 close 事件

例如：

console.log("---script----")
setTimeout(() => {
    console.log('timeout1')
    Promise.resolve().then(() => {
        console.log('promise1')
    })
    Promise.resolve().then(() => {
        console.log('promise2')
    })
}, 0)

setTimeout(() => {
    console.log('timeout2')
    Promise.resolve().then(() => {
        console.log('promise3')
    })
}, 0)

Promise.resolve().then(() => {
    console.log('script- promise')
})

process.nextTick(() => {
    console.log('script- nextTick')
})

for (let i=0; i< 100; i++) {
    console.log(i)
}

console.log("---end script----")
// ---script----
// 0
// 1
// ....
// 99
// ---end script----
// script- nextTick
// script- promise
// timeout1
// promise1
// promise2
// timeout2
// promise3

讲解：

先执行script里面的代码，执行console.log("---script----")，

把第一个定时器setTimeout扔进宏任务，

把第二个定时器扔进宏任务，

把script里的Promise扔进微任务，

把script里的process扔进微任务，

执行到forconsole.log(i)

for结束，执行console.log("---end srcipt----")

检查微任务，发现process，执行console.log('script- nextTick')

检查微任务，发现Promise，执行console.log('script- promise')

微任务执行完，开始检查宏任务，发现第一个定时器

执行console.log('timeout2')，把第一个Promise扔进微任务，把第二个Promise扔进微任务

宏任务执行完，这时候检查微任务，发现有两个，依次console.log('promise1')，console.log('promise2')

现在在检查宏任务发现第二个定时器，执行console.log('timeout2')，发现Promise把它扔进微任务，

当前宏任务执行完，检查微任务，执行Promise，console.log('promise3')

个别例子：

并且在 Node 中，有些情况下的定时器执行顺序是随机的

setTimeout(() => {
    console.log('setTimeout')
}, 0)
setImmediate(() => {
    console.log('setImmediate')
})

讲解：

可能输出 setTimeout、setImmediate

可能也会相反的输出，这取决于性能

因为可能进入 event loop 用了不到 1 毫秒，这时候会执行 setImmediate

否则会执行 setTimeout

当然在这种情况下，执行顺序是相同的

var fs = require('fs')

fs.readFile(__filename, () => {
  setTimeout(() => {
    console.log('timeout')
  }, 0)
  setImmediate(() => {
    console.log('immediate')
  })
})

讲解：

因为 readFile 的回调在 poll 中执行

发现有 setImmediate ，所以会立即跳到 check 阶段执行回调

再去 timer 阶段执行 setTimeout

所以以上输出一定是 setImmediate，setTimeout

上面介绍的都是宏任务（macrotask ）的执行情况，微任务（microtask ）会在以上每个阶段完成后立即执行。

setTimeout(() => {
  console.log('timer1')

  Promise.resolve().then(function() {
    console.log('promise1')
  })
}, 0)

setTimeout(() => {
  console.log('timer2')

  Promise.resolve().then(function() {
    console.log('promise2')
  })
}, 0)

讲解：

以上代码在浏览器和 node 中打印情况是不同的

浏览器中一定打印 timer1, promise1, timer2, promise2

node 中可能打印 timer1, timer2, promise1, promise2

也可能打印 timer1, promise1, timer2, promise2

Node 中的 process.nextTick 会先于其他微任务（microtask ）执行。

setTimeout(() => {
  console.log('timer1')

  Promise.resolve().then(function() {
    console.log('promise1')
  })
}, 0)

process.nextTick(() => {
  console.log('nextTick')
})
// nextTick, timer1, promise1

参考：

https://juejin.im/post/59e85eebf265da430d571f89

https://yuchengkai.cn/docs/frontend/browser.html#close-callbacks

http://47.98.159.95/my_blog/js-v8/006.html#_1-%E4%B8%89%E5%A4%A7%E5%85%B3%E9%94%AE%E9%98%B6%E6%AE%B5

http://www.ruanyifeng.com/blog/2014/10/event-loop.html

https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/

https://juejin.im/post/5b63b4cb6fb9a04fb4017f5a

收录于