JavaScript为何单线程？事件循环揭秘

积累知识，胜过积蓄金银！毕竟在文章开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《JavaScript为何单线程？事件循环如何实现异步？》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

JavaScript主执行线程是单线程的，1. 它通过事件循环机制实现异步非阻塞操作，将耗时任务委托给宿主环境处理并在完成后回调；2. 宏任务（如setTimeout、I/O）和微任务（如Promise回调）按优先级调度，每个宏任务执行后必先清空所有微任务再执行下一个宏任务；3. Web Workers和Node.js的libuv线程池在主线程外利用多线程处理计算或I/O密集型任务，并通过消息或回调安全地与主线程通信，保持主线程单线程本质的同时提升整体并发能力。

JavaScript在浏览器或Node.js环境中，其主执行线程确实是单线程的，这意味着它一次只能处理一个任务。但它并非不能处理耗时操作，而是通过事件循环（Event Loop）机制，将那些耗时或异步任务“委托”出去，并在完成后再回调主线程，从而在单线程的表象下，实现了非阻塞的异步操作。

JavaScript的单线程特性，从根本上讲，是为了简化编程模型。你想想看，如果DOM操作是多线程的，那多个线程同时修改同一个元素，会引发多少竞态条件和锁的问题？简直是噩梦。所以，它选择了一条相对简单且安全的路：一个主线程，负责执行所有的JS代码，包括DOM操作、变量赋值、函数调用等等。

这个选择带来了一个显而易见的问题：如果一个任务非常耗时，比如一个复杂的计算，或者网络请求，那主线程就会被“卡住”，页面会冻结，用户体验极差。这就是为什么我们需要异步机制。JavaScript本身并没有提供多线程能力（Worker除外，但那是另一个层面的东西，不影响主线程的单线程本质），它依赖宿主环境（浏览器或Node.js）提供的API，比如setTimeout, XMLHttpRequest, fetch, Promise等，将这些耗时操作交给宿主环境去处理。当这些操作完成时，宿主环境会将一个“事件”或“回调”放入一个队列中，等待主线程空闲时来处理。这个处理机制的核心，就是事件循环。

JavaScript主线程与任务队列（Task Queue）的关系是怎样的？

理解事件循环，得先搞清楚主线程和任务队列的互动。想象一下，主线程就像一个永不停歇的工人，它有一个“待办事项清单”（调用栈，Call Stack），里面的任务一个接一个地执行。当遇到一个异步任务时，比如发起一个网络请求，主线程不会傻傻地等着它完成。它会把这个任务交给宿主环境（比如浏览器的网络模块）去处理，然后自己继续执行“待办事项清单”上的下一个任务。

当宿主环境处理完这个异步任务后，它不会直接把结果扔回给主线程。相反，它会把一个与这个异步任务相关的“回调函数”或者说“事件消息”放到一个叫做“任务队列”（Task Queue，也叫消息队列或回调队列）的地方。这个队列里可能已经有其他完成的异步任务回调了。

主线程会在什么时候去这个队列里取任务呢？只有当它的“待办事项清单”（调用栈）完全清空，也就是当前正在执行的所有同步代码都跑完了，它才会去“事件循环”（Event Loop）那里询问：“任务队列里有新的任务吗？”如果有，事件循环就会把队列里的第一个任务（回调函数）推到主线程的调用栈上，让主线程去执行。这就是它们之间的基本协作模式。

宏任务（MacroTask）与微任务（MicroTask）在事件循环中如何调度？

事件循环的复杂性，很大程度上体现在它对不同类型任务的调度优先级上。并非所有异步任务的回调都一视同仁地排队。JavaScript引入了宏任务（MacroTask）和微任务（MicroTask）的概念，来精细化调度。

宏任务包括但不限于：setTimeout、setInterval、setImmediate（Node.js特有）、I/O操作、UI渲染事件（浏览器）。当一个宏任务的回调准备好时，它会被放到宏任务队列中。

微任务则包括：Promise的回调（then、catch、finally）、MutationObserver的回调、process.nextTick（Node.js特有）。微任务有更高的优先级。

事件循环的执行流程是这样的：

1. 执行当前的宏任务（通常是整个script脚本）：主线程首先执行调用栈中的所有同步代码，这可以看作是一个大的宏任务。
2. 清空微任务队列：当当前的宏任务执行完毕，调用栈清空后，事件循环会立即检查微任务队列。如果微任务队列不为空，它会把队列中的所有微任务依次取出并执行，直到微任务队列清空。
3. 执行下一个宏任务：微任务队列清空后，事件循环会去宏任务队列中取出一个宏任务来执行。
4. 重复步骤2和3：循环往复，直到两个队列都清空。

这意味着，在执行完一个宏任务之后、执行下一个宏任务之前，所有的微任务都会被优先执行。比如，你发起一个网络请求，它返回的Promise的then回调会作为微任务处理，而一个setTimeout的回调则作为宏任务。所以，即使setTimeout(0)，它也总是在当前所有的微任务执行完毕之后才有可能被执行。这种机制确保了某些高优先级、需要即时响应的异步操作（如Promise链）能更快地得到处理。

Web Workers和Node.js的I/O操作如何与JavaScript的单线程模型协同工作？

尽管JavaScript主线程是单线程的，但这并不意味着它完全无法利用多核CPU的优势，或者在处理I/O密集型任务时效率低下。这得益于宿主环境提供的额外机制。

在浏览器环境中，Web Workers提供了一种在后台线程中运行JavaScript脚本的能力。一个Web Worker是完全独立于主线程的，它有自己的全局作用域，不能直接访问DOM。它们之间通过postMessage方法进行通信。这意味着你可以把一些计算密集型的任务（比如大数据处理、图像处理）放到Worker线程中去执行，而不会阻塞主线程，从而保持页面的响应性。当Worker完成任务后，它会通过消息机制通知主线程，主线程再根据消息更新UI。这并非改变了主线程的单线程本质，而是提供了一种“绕过”单线程限制，利用多线程能力的手段。

而在Node.js环境中，情况略有不同。Node.js的强大之处在于其非阻塞I/O模型。虽然Node.js的JavaScript执行也是单线程的，但其底层是用C++编写的libuv库，这个库负责处理所有的I/O操作（文件读写、网络请求等）。libuv本身是多线程的（它维护了一个线程池），当Node.js的JavaScript主线程发起一个I/O请求时，libuv会将这个请求交给其内部的线程池去处理。当I/O操作完成时，libuv会将相应的回调函数放入Node.js的事件循环的宏任务队列中，等待JavaScript主线程空闲时去执行。

所以，无论是Web Workers还是Node.js的libuv，它们都是在JavaScript主线程之外，利用操作系统的多线程能力来处理耗时操作，然后通过事件循环机制将结果或回调安全地传递回单线程的JavaScript主线程，从而实现了看似“异步”和“并发”的效果，而主线程本身依然保持着其单线程的特性。这是一种非常巧妙且高效的设计。

今天关于《JavaScript为何单线程？事件循环揭秘》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！