JS的运行机制之事件循环机制示例详解_javascript技巧

要想了解JavaScript的运行机制，首先得了解进程和线程是什么

进程（Process）是操作系统分配资源的基本单位

线程（Thread） 是程序执行的最小单位，一个进程中可以包含多个线程，共享内存资源。

  一个应用至少一个进程，每个进程之间相互独立，进程之间共享内存空间。

  一个进程至少一个线程，进程开启后会自动创建一个线程来运行代码，称为主线程。要是程序需要同时执行多块代码，就需要启动动更多线程来执行代码，所以一个进程可以包含多个进程。

而JavaScript本身就是 运行在浏览器中，而浏览器本身也是一个多进程、多线程的复杂应用

现代浏览器（如 Chrome）采用多进程架构，其主要进程包括：

网络进程：处理网络资源的下载（如 HTML、CSS、JS、图片等）。

GPU进程：处理与图形渲染相关的任务，包括3D CSS效果、页面UI的GPU加速绘制，以及视频解码等

 插件进程（Plugin Process）：独立运行浏览器插件（如Flash、广告拦截工具），防止插件崩溃影响浏览器或其他页面

辅助进程（根据场景启动）：跨页面共享的JavaScript线程，独立于渲染进程管理

浏览器插件种类繁多，但我们需要重点掌握JavaScript的运行机制。这就要从关键的渲染进程入手，它与前端页面渲染密切相关。

渲染进程内部，核心是渲染主线程，它负责：

计算样式、布局、绘制

JavaScript 的运行环境就在这个主线程中。因此，JavaScript 是单线程执行。

JavaScript 只运行在浏览器的渲染主线程中，渲染主线程就只有一个，而这个线程既要负责脚本执行，又要承担页面渲染、事件响应等工作。试想一下，如果我们让 JS 主线程一直执行某个任务（比如复杂的循环），那其他任务（如用户点击）就无法响应，页面也无法渲染更新，用户体验会极差。

我们先来分析一段代码

while (true) { // 模拟高消耗运算}

这段代码是一个死循环，它将让页面彻底卡死，因为主线程被死循环阻塞，无法响应任何操作。

为了防止主线程长时间阻塞，JavaScript 借助浏览器的其他线程（如计时器线程、网络线程等）来异步处理任务：

1.主线程将异步任务交由其他线程执行（如 setTimeout 的计时由 Web APIs 中的 Timer 线程负责）。

2.等任务完成后，将“回调函数”包装成任务加入任务队列。

3.主线程空闲后，从任务队列中取出这些任务执行。

这样就实现了非阻塞的异步模型。

JavaScript 是一门单线程语言，因为它运行在浏览器的渲染主线程上，而该线程是唯一的。

渲染主线程需要处理多项任务，包括页面渲染和执行 JavaScript 代码等。如果采用同步执行方式，可能会导致主线程阻塞，进而使消息队列中的其他任务无法及时执行。这不仅会造成主线程资源的浪费，还会导致页面更新延迟，给用户带来卡顿的体验。

为此，浏览器采用异步机制来解决这个问题。当遇到计时器、网络请求、事件监听等任务时，主线程会将这些任务交由其他线程处理，自身则继续执行后续代码。待其他线程完成任务后，会将回调函数封装成新任务，添加到消息队列末尾等待主线程调度执行。

这种异步机制有效避免了浏览器阻塞，确保了单线程运行的流畅性。

事件循环是浏览器或 Node.js 中控制异步执行的核心机制。它的本质就是一个不断循环的系统：

while (true) { // 1. 执行一个宏任务（task） // 2. 执行完立即清空所有微任务（microtasks） // 3. 如果需要更新界面，则进行渲染}

每一次完整的循环称为一个“tick”。在每个 tick 中，主线程都会从任务队列中取出一个宏任务执行，并在其执行完毕后立即清空微任务队列。

用户交互队列：如 click、input 等事件

这些消息队列中的任务采用先进先出机制，没有独立优先级，但消息队列本身具有优先级划分。

每个任务都有特定类型，同类型任务必须归入同一队列，不同类型任务可分配到不同队列。在单次事件循环中，浏览器可根据实际情况从不同队列中选取任务执行。

浏览器必须维护专门的微队列，该队列中的任务享有最高执行优先级。

当前主流队列按优先级排序为：延时队列（中优先级）、交互队列（高优先级）、微队列（最高优先级）。

根据上述对事件循环和异步任务的解释，可以得出浏览器中的一轮事件的循环过程

取出一个宏任务执行

执行过程中可能注册多个微任务（如 Promise.then）

执行完宏任务后，立即依次执行所有微任务

由于 JS 脚本的执行与页面渲染共用主线程，若 JS 长时间执行，渲染任务就会延后。

例如以下同步阻塞代码：

while(Date.now() < performance.now() + 2000) {}

页面会在 2 秒内完全无法响应。

此外，浏览器为了防止 JS 操作 DOM 导致的视觉中断，在 JS 执行期间通常会“暂停渲染”，等脚本执行完毕再统一渲染页面。

（1）计算机硬件和操作系统的限制

        CPU时钟精度问题，计算机没有原子钟，无法精确计算时间

        操作系统提供的计时 API（如 Windows 的 GetSystemTime）存在 1-15ms 的调用误差。

（2）浏览器的引擎机制

        嵌套超限补偿，当定时器嵌套层级超过 5 层时（如回调中再次调用 setTimeout），浏览器会强制增加 4ms 延迟：

// 假设这是第六次调用，调用开始产生额外延迟，即使设置延迟为0，也会有至少4ms延迟setTimeout(function recur() { setTimeout(recur, 0); // 实际延迟 ≥4ms}, 0);

        最小时间间隔，即使设置 setTimeout(fn, 0)，实际延迟通常被限制为 1ms（Chrome）或 4ms（旧版浏览器）。

（3）事件循环调度延迟

        主线程阻塞，当同步代码或长任务占用主线程时，计时器回调必须等待。   

        队列优先级竞争，即使准时到期，回调仍需等待：微任务队列清空、更高优先级的交互/动画任务、当前执行栈为空。

到此这篇关于JS的运行机制之事件循环机制的文章就介绍到这了,更多相关JS事件循环机制内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

上一篇：一文详解如何解决Threejs物体渲染的锯齿问

下一篇：Dayjs基础用法超详细举例讲解javascript技