[!info] related notes

• 所属 MOC: javascript-in-browser-moc, javascript-moc
• 上位主题: javascript-in-browser
• 上位背景: 进程&线程&协程
• 调度与并发: js事件循环, ecmascript-promises-and-async, browser-web-workers
• Node 对比: worker-threads

JavaScript中的进程、线程与协程

这篇笔记不单独讲操作系统理论，而是回答一个更具体的问题：浏览器里的 JavaScript 到底处在怎样的并发结构里。

一条主线

• 浏览器整体通常是多进程架构
• 单个页面的 JavaScript 主执行流通常是单线程
• 异步并发主要靠事件循环和任务调度
• 真正的并行计算通常靠 Web Worker 等额外线程

浏览器为什么常见为多进程

现代浏览器通常把标签页、网络、GPU、浏览器主控等能力拆到不同进程里，核心目标是隔离、稳定性和安全性。

这也是为什么一个页面卡死或崩溃，不一定把整个浏览器一起拖垮。

JavaScript 为什么常被说成单线程

对前端开发最关键的主线程来说，JavaScript 需要和 DOM、样式计算、布局、绘制协同工作。

如果多个线程同时无序修改 DOM，页面一致性和同步成本会非常复杂，所以浏览器把绝大多数页面脚本放在单条主执行线上处理。

协程这个说法在 JavaScript 里怎么理解

在 JavaScript 语境里，协程通常不是指操作系统线程，而是指一种可暂停、可恢复的协作式执行体验。

• Generator 提供显式暂停点
• async/await 让异步流程看起来像顺序代码
• 真正让它们恢复执行的，仍然是 Promise 与事件循环调度

所以这里更适合把“协程”理解成语言层的控制流表达，而不是浏览器里真的多了一条系统线程。

什么时候会出现真正的多线程

当任务是 CPU 密集型，单靠 await 不能避免卡顿时，可以把工作移到 browser-web-workers。

Worker 可以并行执行脚本，但不能直接操作 DOM，通常通过消息传递把结果发回主线程。

该把这篇放回哪里看

• 看浏览器宿主全景：javascript-in-browser
• 看回调何时恢复执行：js事件循环
• 看真正的后台线程能力：browser-web-workers