Chrome 多线程和多进程架构

Process or Threads Architecture

现在浏览器选择多进程架构 (内存空间独立)

• Browser Process - One (adress bar, back/forward stack / bookmarkds…file access)

• Render Process - each tab (try)

• GPU Process - One : Gpu task ，GPU 复制绘制整个电脑屏幕，浏览器区域可能只是其中一部分。各个进程将自己的显示数据提交给GPU帧缓冲，GPU 统一绘制整个屏幕。

• Utility Process - One

• Plugin Process - Chrome 插件

• Extesion Process

• …

• 只让当前活跃的窗口的进程工作，后台 tab 的渲染进程可以休眠。

• 进程的内存空间是独立的，方便实现数据安全隔离和沙盒。

• 如果到达系统资源上限，多个 tab 可

Because processes have their own private memory space, they often contain copies of common infrastructure (like V8 which is a Chrome's JavaScript engine). This means more memory usage as they can't be shared the way they would be if they were threads inside the same process

chrome 浏览器原理中的这句话很微妙，我的理解是由于多进程间的内存空间是独立的，也就是没有共享数据，这个类似于 V8 这样的引擎，就可以通过一套代码，在不同的进程上运行，还能互不影响。类似后端的一个 API 服务，可以工作到多个虚拟机实例上，而互不影响。

GPT 答：

你的理解是对的！这句话的核心意思是：由于 Chrome 采用多进程架构，每个进程有自己独立的内存空间，所以像 V8 这样的 JavaScript 引擎就需要在每个进程中独立运行，不能像多线程那样共享内存。

拆解理解

1. 进程 vs 线程

• 进程（Process）：每个进程有独立的内存空间，无法直接共享数据。

• 线程（Thread）：线程共享进程的内存，数据可以直接访问。

2. Chrome 的多进程架构

• Chrome 使用了多进程架构，不同的Tab 页面、插件、渲染引擎都在不同的进程中运行。

• 由于进程隔离，每个进程都有自己独立的 V8 引擎，无法直接共享 V8 已经解析过的 JavaScript 代码和 JIT 编译的结果。

3. 类比 API 服务

• 你用API 服务的例子很贴切！就像一个 API 服务可以运行在多个独立的虚拟机实例上，每个实例有自己的内存空间和资源，但它们运行的是相同的代码。

• 同样的，Chrome 中的多个进程都运行着独立的 V8 引擎实例，但 V8 本身的代码逻辑是一模一样的。

缺点

Chrome 的这种多进程架构虽然提高了安全性和稳定性（一个页面崩溃不会影响其他页面），但代价是更高的内存占用，因为：

• 每个进程都要维护自己的 V8 实例。

• 不能像多线程那样共享JIT 编译的代码、缓存等数据。

优化手段

• 共享代码（Code Caching）： Chrome 通过某些机制，比如共享已编译的 JavaScript 代码，来减少重复编译的成本。

• Zero-copy 共享数据： 通过某些 IPC 技术，可以减少进程间的数据拷贝。

• PartitionAlloc 和 V8 Snapshot： 这些优化手段可以减少进程启动的内存占用。

 

---