什么是 GVL，Ruby 中的并发是如何工作的？

Question

Accepted Answer

MRI Ruby 中的 **GVL**（Global VM Lock，以前称为 GIL）允许**一次只有一个线程执行 Ruby 代码** — 所以线程不提供真正的 CPU 并行性。但 GVL **在 I/O 期间被释放**，所以线程*确实*帮助 I/O 密集型工作。对于 CPU 并行性，你使用多个进程。这与 Python 的 GIL 情况类似。

## GVL：一次一个线程运行 Ruby 代码

```text
MRI (the standard Ruby) has a GLOBAL VM LOCK:
  → only ONE thread executes Ruby code at any instant (no CPU parallelism from threads)
  → BUT the GVL is RELEASED during blocking I/O (network, file, DB)
So: threads help for I/O-bound work, NOT for CPU-bound work.
```

## 线程 — 适合 I/O 密集型并发

```ruby
# ✅ I/O-bound — threads overlap waiting (GVL released during I/O) → real benefit
threads = urls.map do |url|
  Thread.new { fetch(url) }      # while one waits on the network, others proceed
end
threads.each(&:join)

# ❌ CPU-bound — threads do NOT speed this up (GVL serializes Ruby execution)
threads = data.map { |d| Thread.new { heavy_computation(d) } }  # no speedup
```

线程对 I/O 密集型工作（网络、文件、数据库）很有帮助，因为 GVL 在等待期间被释放，让其他线程运行。它们**不会**加快 CPU 密集型工作的速度（GVL 序列化 Ruby 执行）。

## 进程 — 实现 CPU 密集型并行性

```ruby
# ✅ CPU-bound parallelism → use multiple PROCESSES (each has its own GVL)
# fork, or gems like Parallel:
results = Parallel.map(data, in_processes: 4) { |d| heavy_computation(d) }
# → 4 separate processes, true parallelism across cores
```

对于 CPU 密集型并行性，使用**多个进程**（每个都有自己的 GVL/解释器）— `fork`、`parallel` gem 或运行多个 worker 进程（Puma 等 Rails 服务器的扩展方式）。

## 现代并发工具

```text
✓ Ractors (Ruby 3) — actor-model parallelism that CAN run Ruby in parallel (no shared GVL
  per Ractor) — experimental, true parallelism
✓ Fibers / async gem — lightweight cooperative concurrency for high-I/O workloads
✓ Background jobs (Sidekiq) — offload work to separate worker processes
Note: alternative Ruby implementations (JRuby, TruffleRuby) have NO GVL → true thread parallelism
```

## 为什么这很重要

理解 GVL 和 Ruby 并发是重要的 — 且经常被误解的 — 构建高性能 Ruby 应用所需的知识，就像 Python 的 GIL 情况一样。

关键见解是 MRI Ruby 的 **GVL 允许一次只有一个线程执行 Ruby 代码**，所以线程*不*提供 CPU 并行性 — 这是一个常见的误解点。

至关重要的是，GVL **在 I/O 期间被释放**，这意味着正确的并发方法取决于工作负载：**线程适合 I/O 密集型任务**（网络调用、文件/数据库访问 — GVL 在等待期间被释放，让线程可以重叠），但 **CPU 密集型并行性需要多个进程**（每个都有自己的 GVL，在多个核心上实现真正的并行性 — 通过 `fork`、`parallel` gem 或多个 worker 进程，这是 Rails 服务器扩展的方式）。

对 GVL 的误解导致无效的并发代码（例如使用线程处理 CPU 密集型工作期望得到加速）。

了解 I/O-vs-CPU 决策（I/O 并发使用线程，CPU 并行性使用进程）、现代工具（用于实验性真正并行性的 Ractors、用于高 I/O 协作并发的 Fibers/async、Sidekiq 等后台作业处理器），以及替代实现（JRuby、TruffleRuby）缺乏 GVL 这一事实，对于编写真正高性能的并发 Ruby 至关重要。

由于并发是常见需求，且 GVL 从根本上决定了正确的方法，理解它 — 为什么线程不能并行化 CPU 工作，它们如何帮助 I/O，以及为什么 CPU 并行性需要进程 — 是重要的高级知识，可以防止常见错误，也是一个常见的面试话题，反映了对 Ruby 并发模型和 GVL 约束的理解。