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请求），他不会站在你旁边等你吃完，而是把订单交给后厨（操作系统/线程池），然后继续去服务其他客人。等你的菜做好了，后厨会叫他一声，他再把菜端给你。这样，餐厅（你的程序）就不会因为一个客人的点餐而停摆。
事件循环如何实现异步操作的并发性？
这确实是个有意思的问题。很多人会把“非阻塞”和“并发”混淆，甚至误以为是“并行”。其实，事件循环在单线程环境下实现的，是一种“伪并发”或者说“逻辑并发”。它不是真正意义上的同时处理多个任务，而是通过快速切换和调度，让多个任务看起来像是同时在进行。
它的实现机制主要依赖于几个核心组件：
调用栈 (Call Stack)：这是JavaScript代码执行的地方，遵循“先进后出”的原则。当一个函数被调用时，它被推入栈中；函数执行完毕后，它被弹出。Web APIs / Node.js APIs (或称“宿主环境”)：这是浏览器或Node.js环境提供的一些接口，用于处理那些耗时的异步操作，比如setTimeout、fetch、文件读写等。当你调用这些API时，它们会将对应的任务“注册”到宿主环境去执行。任务队列 (Task Queue / Callback Queue)：也叫宏任务队列 (Macrotask Queue)。当宿主环境中的异步操作完成时，它们对应的回调函数会被放入这个队列中排队。微任务队列 (Microtask Queue)：这是一个优先级更高的队列，通常包含Promise的回调（then/catch/finally）和process.nextTick（Node.js特有）。
事件循环的工作流程大致是这样的：
首先，它会执行调用栈中的所有同步代码，直到调用栈清空。接着，它会检查微任务队列。如果微任务队列中有任务，它会清空整个微任务队列，将所有微任务按顺序推入调用栈执行，直到微任务队列再次清空。微任务队列清空后，事件循环才会去检查宏任务队列。它会从宏任务队列中取出一个（注意：通常只取一个）任务，将其对应的回调函数推入调用栈执行。当这个宏任务执行完毕，调用栈再次清空后，事件循环会重复上述过程：再次检查并清空微任务队列，然后再去宏任务队列取下一个任务。
正是这种“先清空微任务，再取一个宏任务”的循环往复，使得异步操作的回调能够被及时处理，而主线程又不会被长时间阻塞，从而实现了逻辑上的并发。
同步代码阻塞事件循环意味着什么？
理解了事件循环的非阻塞特性，反过来思考“阻塞”就变得很重要了。虽然事件循环的设计是为了非阻塞，但如果你在JavaScript代码中编写了长时间运行的同步任务，那它就真的会“阻塞”事件循环。
这意味着什么呢？简单来说，就是你的JavaScript代码会霸占住主线程，不给事件循环任何机会去处理其他任务。想象一下，如果你有一个for循环，里面执行了数百万次的计算，或者一个递归函数没有正确地终止，那么在它执行完成之前，事件循环就无法将任务队列中的任何回调函数推入调用栈。
这会导致一系列问题：
用户界面无响应：在浏览器环境中，如果主线程被阻塞，页面将无法响应用户的点击、滚动等操作，动画会停止，甚至页面会显示“无响应”的提示。网络请求延迟处理：即使你的网络请求已经返回了数据，但由于主线程忙于执行同步代码，处理这些数据的回调函数（它们在任务队列里排队呢）也无法被执行，导致数据迟迟无法被处理。定时器不准确：setTimeout和setInterval的回调会被延迟执行，因为它们也需要等待主线程空闲。一个setTimeout(0)并不意味着立即执行，而是“尽快执行”，但这个“尽快”的前提是主线程不被阻塞。
举个例子：
console.log('开始');// 这是一个会阻塞事件循环的同步操作let i = 0;while (i { 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（本质也是回调的语法糖）来处理。
不同点：
宏任务源 (Macrotask Sources)：
浏览器环境：常见的宏任务包括setTimeout、setInterval、I/O（如XHR请求完成）、UI渲染事件（如requestAnimationFrame）、用户交互事件（点击、键盘输入）等。浏览器事件循环还需要处理页面渲染和用户交互。Node.js环境：宏任务主要包括setTimeout、setInterval、I/O事件（文件系统、网络）、setImmediate。Node.js没有UI渲染的概念。
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）结束之后，但在事件循环进入下一个阶段之前立即执行。它的优先级比微任务队列中的任务还要高，可以理解为在当前调用栈清空后，立即执行，甚至在微任务之前。这使得它非常适合需要“立即”执行但又不想阻塞当前同步代码的任务。
I/O实现：
浏览器：通常依赖浏览器内核提供的底层API来处理网络I/O（如TCP/IP栈）和文件I/O（如FileReader）。Node.js：大量依赖libuv库。libuv是一个跨平台的异步I/O库，它抽象了底层操作系统的差异，并为Node.js提供了事件循环、线程池（用于处理文件I/O等阻塞操作）等核心功能。这意味着Node.js可以更直接地访问文件系统和网络接口。
UI渲染：
浏览器：事件循环与浏览器渲染引擎紧密集成，UI更新通常在事件循环的特定阶段进行，以确保页面流畅。Node.js：作为服务器端运行时，没有用户界面，因此也就不涉及UI渲染。
这些差异使得开发者在编写Node.js和浏览器代码时，需要对事件循环的细节有更深入的理解，尤其是在处理任务调度和性能优化方面。
以上就是为什么说事件循环是非阻塞的？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1511814.html
微信扫一扫 
支付宝扫一扫 
