你开了一个视频，又开了10个网页，再开了20个标签页...Chrome 居然没崩？而其他软件早就卡死了。Chrome是怎么做到的？

今天用酒店的故事，聊聊 Chrome 的多进程架构。

进程与线程：有什么区别？

想象一下：

进程如同一个独立的厨房，有自己的灶台、冰箱、厨师。

线程如同厨房里的厨师，多个厨师共享同一个厨房的资源——灶台是共用的，冰箱是共用的，但每个厨师可以同时干活。

进程A（独立厨房）              进程B（独立厨房）
┌─────────────────┐            ┌─────────────────┐
│   厨师A1       │            │   厨师B1       │
│   厨师A2       │            │   厨师B2       │
│   厨师A3       │            │   厨师B3       │
│  ↓            │            │  ↓            │
│ 一个厨师中毒   │            │ 其他厨师正常   │
│ 其他厨师没事   │            │ 继续做饭       │
└─────────────────┘            └─────────────────┘

关键区别：

• 进程是"隔离的"：进程A崩溃了，进程B完全不受影响
• 线程共享资源：线程A1崩溃，可能影响整个进程A，其他线程都完蛋

IPC消息类型

Chrome中主要的消息类型：

IPC工作流程

点击链接时，Chrome 内部经历了：

┌───────────────────────────────────┐
│ 步骤1：渲染进程检测点击             │
│ JS事件监听器捕获 <a> 点击          │
└───────────────────────────────────┘
                │
                ▼ ViewMsg_LinkOpened
                │
┌───────────────────────────────────┐
│ 步骤2：主进程接收消息              │
│ 决定打开新标签页                   │
└───────────────────────────────────┘
                │
                ▼ HandleViewMsg_CreateWidget
                │
┌───────────────────────────────────┐
│ 步骤3：创建新渲染进程              │
│ 分配新内存空间，初始化V8引擎       │
└───────────────────────────────────┘
                │
                ▼ Channel_LoadURL
                │
┌───────────────────────────────────┐
│ 步骤4：新渲染进程加载URL           │
│ 网络请求、HTML解析、渲染           │
└───────────────────────────────────┘

整个过程仅需几十毫秒。

渲染进程内部：线程

每个渲染进程内部也不是单线程，而是多线程协作：

渲染进程内部：


┌───────────────────────────────────────┐
│            主线程（Main Thread）        │
│ • V8 JS引擎执行                       │
│ • HTML/CSS解析                        │
│ • DOM树构建·布局计算·事件处理         │
│ • requestAnimationFrame               │
└───────────────────────────────────────┘
                    │
        ┌───────────┴───────────┐
        ▼                       ▼
┌──────────────┐         ┌──────────────┐
│   合成线程    │         │   光栅线程     │
│（Compositor）│         │   （Raster）   │
├──────────────┤         ├──────────────┤
│• 图层合成    │         │• 绘制指令执行 │
│• 滚动·动画  │         │• 像素填充     │
│• 接收输入事件│         │• 纹理上传GPU │
└──────────────┘         └──────────────┘

传统方式（经过主线程）：
滚动事件 → 主线程处理 → 重新布局 → 重绘 → 合成
         ↑
       可能被JS阻塞


Chrome方式（合成线程直接处理）：
滚动事件 → 合成线程 → 直接合成 → 输出
         ↑
       完全不经过主线程

沙箱限制：


渲染进程能做的事：
├── ✅ 执行JS（V8引擎隔离）
├── ✅ 操作DOM（沙箱内DOM树）
├── ✅ 计算样式
└── ✅ 发送网络请求（通过IPC代理）


渲染进程不能做的事：
├── ❌ 直接读写文件系统
├── ❌ 直接访问摄像头/麦克风（需用户授权）
├── ❌ 直接访问系统剪贴板（全权）
├── ❌ 直接读取本机Cookie/密码
├── ❌ 直接创建网络连接（必须经过网络进程）
└── ❌ 直接调用系统API

标签页1 → 渲染进程A → 可以访问标签页1的内存
标签页2 → 渲染进程A → 可以访问标签页2的内存
                        ↓
                   同一个进程
                   理论上可以访问彼此

example.com 页面：
┌─────────────────────────────────────────┐
│  主页面（主框架）     → 渲染进程A         │
│    ├── iframe(ads.example.com)  → 渲染进程B │
│    ├── iframe(analytics.com)   → 渲染进程C │
│    └── iframe(cdn.example.com)  → 渲染进程D │
└─────────────────────────────────────────┘
         ↓
    进程级别完全隔离

为什么需要这么严格？

防止Spectre/Meltdown等侧信道攻击：

攻击场景：
1. evil.com 运行在 渲染进程A
2. victim.com 也在 渲染进程A（作为iframe）
3. 恶意JS利用Spectre漏洞
4. 通过侧信道 timing攻击 读取渲染进程A的内存
5. 理论上可以读到 victim.com 的数据！

有了 Site Isolation，即使 evil.com 被攻破，它的渲染进程也无法访问 victim.com 的数据——因为它们根本不在同一个进程里。

Site Isolation的代价

更严格的隔离带来更高的内存占用：

情况	进程数
10个同源标签页	10个渲染进程
10个跨源标签页	可能10+个渲染进程
一个页面有5个跨站iframe	6个渲染进程

Chrome为了安全，愿意付出更多内存代价。

---

为什么Chrome占用内存高？

很多人抱怨Chrome"吃内存"。

确实，多进程架构比单进程消耗更多内存，但这是故意的设计权衡：

 

Chrome的内存管理优化

虽然多进程更耗内存，但Chrome也做了很多优化：

1. 渲染进程合并：同源的多个标签页可能共享一个渲染进程

2. 内存共享：使用**共享内存（Shared Memory）**减少复制

3. 进程休眠：长时间未激活的标签页进程可以休眠

4. 垃圾回收优化：V8 的垃圾回收已经高度优化
   
   

什么时候会内存爆炸？

内存爆炸场景：
├── 开100个淘宝/京东商品页（每个都有大量JS）
├── 开50个在线文档（Google Docs、Notion）
├── 开20个视频网站（爱奇艺、优酷、B站）
└── 结果：内存占用轻松上10GB

这是Chrome的"有钱任性"设计哲学——用内存换稳定性和用户体验。

总结：Chrome核心知识点

 

核心思想：Chrome用"酒店"架构——每个房间（进程）独立，隔音好，一个房间出问题不影响其他；房间内有限制，不能动基础设施；甚至同一页面的不同访客也要隔开。

技术不复杂，但正是这套架构，让"100个网页同时运行"成为可能。

下次 Chrome 占用几百MB甚至几GB内存时，别急着骂它——那是它"有钱任性"的设计，是为了让你的浏览器更稳定、更安全、更流畅。