事件循环为何非阻塞？异步处理是关键

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《事件循环是非阻塞的核心原因在于它通过异步处理机制，避免了主线程被长时间阻塞。在传统的同步编程中，如果一个任务需要较长时间才能完成（如网络请求、文件读写等），程序会一直等待该任务结束，导致其他任务无法执行，这就是“阻塞”现象。 而事件循环采用的是非阻塞 I/O 模型，具体表现为： 1. **异步调用**：当遇到耗时操作时，程序不会等待其完成，而是将该操作交给系统或底层库去执行，然后继续处理其他任务。 2. **回调机制**：操作完成后，系统会将结果返回给事件循环，由事件循环触发相应的回调函数进行处理。 3. **单线程但高效**：虽然事件循环通常运行在单一线程上，但由于没有阻塞操作，它可以在极短时间内处理大量任务，实现高并发。 因此，事件循环之所以是非阻塞的，是因为它通过异步处理和回调机制，确保了主线程始终处于活跃状态，不会因等待某个任务而停滞不前。》，聊聊，我们一起来看看吧！

1.事件循环非阻塞的核心在于将耗时I/O操作委托给操作系统或线程池处理，主线程继续执行其他任务；2.它通过调用栈执行同步代码、Web API处理异步任务、任务队列（宏任务）和微任务队列调度回调，实现逻辑并发；3.同步代码若长时间运行会阻塞事件循环，导致界面无响应、定时器延迟、回调无法执行；4.Node.js与浏览器事件循环均基于单线程和异步I/O，但Node.js使用libuv处理I/O、特有setImmediate和process.nextTick，且无UI渲染，而浏览器需处理用户交互和页面更新。

事件循环之所以被称为“非阻塞”的，核心在于它允许主线程在执行耗时操作（比如I/O请求）时，不会停下来干等，而是能继续处理其他任务。它通过一种巧妙的机制，将这些耗时操作“委托”出去，等它们完成后再通知主线程来处理结果，从而避免了主线程的僵死。

解决方案

要理解事件循环的非阻塞性，我们得从JavaScript或Node.js的运行环境说起。它们都是单线程的，这意味着同一时间只能执行一个任务。这听起来似乎很矛盾，单线程怎么能做到非阻塞呢？关键就在于“事件循环”和“异步I/O”。

想想看，当你的程序需要从网络请求数据，或者读取一个大文件时，这些操作往往很慢。如果主线程傻傻地等着数据返回，那整个程序就会卡住，用户界面会冻结，其他任何操作都无法进行。这就是“阻塞”。

事件循环的解决方案是：当遇到这些耗时的I/O操作时，它不会让主线程等待。相反，它会将这些操作“交给”操作系统内核（或者Node.js中的libuv库，它会利用底层的线程池来处理一些真正的阻塞I/O，比如文件I/O），然后立即返回，让主线程继续执行后续的JavaScript代码。当I/O操作完成时，操作系统会通知事件循环，并将对应的回调函数（也就是你写来处理结果的代码）放入一个队列中。事件循环会不断地检查这个队列，一旦主线程空闲下来（即调用栈清空），它就会把队列中的回调函数取出来，放到调用栈上执行。

这个过程就像一个餐厅服务员（事件循环）接了你的点餐（I/O请求），他不会站在你旁边等你吃完，而是把订单交给后厨（操作系统/线程池），然后继续去服务其他客人。等你的菜做好了，后厨会叫他一声，他再把菜端给你。这样，餐厅（你的程序）就不会因为一个客人的点餐而停摆。

事件循环如何实现异步操作的并发性？

这确实是个有意思的问题。很多人会把“非阻塞”和“并发”混淆，甚至误以为是“并行”。其实，事件循环在单线程环境下实现的，是一种“伪并发”或者说“逻辑并发”。它不是真正意义上的同时处理多个任务，而是通过快速切换和调度，让多个任务看起来像是同时在进行。

它的实现机制主要依赖于几个核心组件：

1. 调用栈 (Call Stack)：这是JavaScript代码执行的地方，遵循“先进后出”的原则。当一个函数被调用时，它被推入栈中；函数执行完毕后，它被弹出。
2. Web APIs / Node.js APIs (或称“宿主环境”)：这是浏览器或Node.js环境提供的一些接口，用于处理那些耗时的异步操作，比如setTimeout、fetch、文件读写等。当你调用这些API时，它们会将对应的任务“注册”到宿主环境去执行。
3. 任务队列 (Task Queue / Callback Queue)：也叫宏任务队列 (Macrotask Queue)。当宿主环境中的异步操作完成时，它们对应的回调函数会被放入这个队列中排队。
4. 微任务队列 (Microtask Queue)：这是一个优先级更高的队列，通常包含Promise的回调（then/catch/finally）和process.nextTick（Node.js特有）。

事件循环的工作流程大致是这样的：

• 首先，它会执行调用栈中的所有同步代码，直到调用栈清空。
• 接着，它会检查微任务队列。如果微任务队列中有任务，它会清空整个微任务队列，将所有微任务按顺序推入调用栈执行，直到微任务队列再次清空。
• 微任务队列清空后，事件循环才会去检查宏任务队列。它会从宏任务队列中取出一个（注意：通常只取一个）任务，将其对应的回调函数推入调用栈执行。
• 当这个宏任务执行完毕，调用栈再次清空后，事件循环会重复上述过程：再次检查并清空微任务队列，然后再去宏任务队列取下一个任务。

正是这种“先清空微任务，再取一个宏任务”的循环往复，使得异步操作的回调能够被及时处理，而主线程又不会被长时间阻塞，从而实现了逻辑上的并发。

同步代码阻塞事件循环意味着什么？

理解了事件循环的非阻塞特性，反过来思考“阻塞”就变得很重要了。虽然事件循环的设计是为了非阻塞，但如果你在JavaScript代码中编写了长时间运行的同步任务，那它就真的会“阻塞”事件循环。

这意味着什么呢？简单来说，就是你的JavaScript代码会霸占住主线程，不给事件循环任何机会去处理其他任务。想象一下，如果你有一个for循环，里面执行了数百万次的计算，或者一个递归函数没有正确地终止，那么在它执行完成之前，事件循环就无法将任务队列中的任何回调函数推入调用栈。

这会导致一系列问题：

• 用户界面无响应：在浏览器环境中，如果主线程被阻塞，页面将无法响应用户的点击、滚动等操作，动画会停止，甚至页面会显示“无响应”的提示。
• 网络请求延迟处理：即使你的网络请求已经返回了数据，但由于主线程忙于执行同步代码，处理这些数据的回调函数（它们在任务队列里排队呢）也无法被执行，导致数据迟迟无法被处理。
• 定时器不准确：setTimeout和setInterval的回调会被延迟执行，因为它们也需要等待主线程空闲。一个setTimeout(0)并不意味着立即执行，而是“尽快执行”，但这个“尽快”的前提是主线程不被阻塞。

举个例子：

console.log('开始');

// 这是一个会阻塞事件循环的同步操作
let i = 0;
while (i < 1000000000) { // 假设这是一个非常大的循环
  i++;
}

console.log('同步任务完成');

setTimeout(() => {
  console.log('setTimeout 回调');
}, 0);

fetch('https://api.example.com/data')
  .then(response => response.json())
  .then(data => {
    console.log('Fetch 回调:', data);
  });

console.log('结束');

在这段代码中，while循环会长时间霸占主线程。你会发现'同步任务完成'会比'setTimeout 回调'和'Fetch 回调'先打印出来，即使setTimeout的延迟是0，fetch请求可能已经完成了。这就是同步代码阻塞事件循环的典型表现。

所以，在编写JavaScript代码时，尤其是在Node.js服务器端或浏览器前端，我们总是强调要避免编写长时间运行的同步代码，而是尽可能地将耗时操作异步化，以保持事件循环的畅通无阻。

Node.js 和浏览器环境下的事件循环有何异同？

虽然Node.js和浏览器都基于JavaScript，并共享事件循环的核心概念，但它们在实现细节和侧重点上还是存在一些差异，这主要是因为它们所处的运行环境和需要处理的任务类型不同。

共同点：

• 单线程执行JS代码：这是最根本的共同点。无论Node.js还是浏览器，JavaScript代码的执行都是在单个线程上进行的。
• 异步I/O：两者都依赖异步I/O来避免阻塞主线程，无论是网络请求、文件操作还是定时器。
• 调用栈、任务队列、微任务队列：这些核心组件和它们的工作原理在两者中是相似的。都遵循“执行完同步代码 -> 清空微任务队列 -> 取一个宏任务执行”的循环模式。
• 基于回调机制：异步操作的结果通常通过回调函数或Promise（本质也是回调的语法糖）来处理。

不同点：

1. 宏任务源 (Macrotask Sources)：

   • 浏览器环境：常见的宏任务包括setTimeout、setInterval、I/O（如XHR请求完成）、UI渲染事件（如requestAnimationFrame）、用户交互事件（点击、键盘输入）等。浏览器事件循环还需要处理页面渲染和用户交互。
   • Node.js环境：宏任务主要包括setTimeout、setInterval、I/O事件（文件系统、网络）、setImmediate。Node.js没有UI渲染的概念。

2. setImmediate 与 process.nextTick (Node.js特有)：

   • setImmediate：这是Node.js特有的一个宏任务调度函数，它的回调会在当前事件循环的“check”阶段执行，通常在I/O回调之后、setTimeout(0)之前（但在实际运行时，由于计时器精度等因素，setTimeout(0)和setImmediate的执行顺序可能不确定，但在I/O回调内部，setImmediate总是优先于setTimeout(0)）。
   • process.nextTick：这也是Node.js特有的，但它不属于宏任务或微任务队列。process.nextTick的回调会在当前操作（current operation）结束之后，但在事件循环进入下一个阶段之前立即执行。它的优先级比微任务队列中的任务还要高，可以理解为在当前调用栈清空后，立即执行，甚至在微任务之前。这使得它非常适合需要“立即”执行但又不想阻塞当前同步代码的任务。

3. I/O实现：

   • 浏览器：通常依赖浏览器内核提供的底层API来处理网络I/O（如TCP/IP栈）和文件I/O（如FileReader）。
   • Node.js：大量依赖libuv库。libuv是一个跨平台的异步I/O库，它抽象了底层操作系统的差异，并为Node.js提供了事件循环、线程池（用于处理文件I/O等阻塞操作）等核心功能。这意味着Node.js可以更直接地访问文件系统和网络接口。

4. UI渲染：

   • 浏览器：事件循环与浏览器渲染引擎紧密集成，UI更新通常在事件循环的特定阶段进行，以确保页面流畅。
   • Node.js：作为服务器端运行时，没有用户界面，因此也就不涉及UI渲染。

这些差异使得开发者在编写Node.js和浏览器代码时，需要对事件循环的细节有更深入的理解，尤其是在处理任务调度和性能优化方面。

本篇关于《事件循环为何非阻塞？异步处理是关键》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！