GVL(グローバルVM ロック)とは何か、Ruby ではどのように並行処理が機能するのか?

Question

Accepted Answer

MRI Ruby の**GVL**(グローバル VM ロック、旧称 GIL)は、**同時に 1 つのスレッドだけが Ruby コードを実行できる**ため、スレッドは真の CPU 並列性を提供しません。しかし GVL は**I/O 中に解放される**ため、スレッドは*確かに* I/O バウンドな作業に役立ちます。CPU 並列性のためには、複数のプロセスを使用します。これは Python の GIL 状況と同じです。

## GVL: 一度に 1 つのスレッドが 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 バウンドな作業(ネットワーク、ファイル、DB)に役立ちます。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、または複数のワーカープロセスを実行します(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 の並行処理を理解することは重要であり、Python の GIL 状況と同様に頻繁に誤解されるナレッジです。

重要な洞察は、MRI Ruby の**GVL は同時に 1 つのスレッドだけが Ruby コードを実行できる**ため、スレッドは CPU 並列性を提供**しない**という、よくある混乱のポイントです。

重大なことに、GVL は**I/O 中に解放される**ため、正しい並行処理アプローチはワークロードによって異なります: **スレッドは I/O バウンドなタスク**(ネットワーク呼び出し、ファイル/データベースアクセス — GVL が待機中に解放され、スレッドが重複できる)に適しています。**CPU バウンドな並列性には複数のプロセス**(各自が独自の GVL を持つ、コアを超えて真の並列性を達成します — `fork`、`parallel` gem、または複数のワーカープロセス経由で、Rails サーバーがスケールする方法です)が必要です。

GVL を誤解すると、効果的でない並行処理コードになります(例えば、スピードアップを期待して CPU 集約的な作業にスレッドを使用する)。

I/O 対 CPU の決定(I/O 並行処理にはスレッド、CPU 並列性にはプロセス)、モダンツール(実験的な真の並列性のための Ractors、高 I/O 協調的並行処理のための Fibers/async、Sidekiq のようなバックグラウンドジョブプロセッサ)、および代替実装(JRuby、TruffleRuby)が GVL を持たないことを知ることは、実際にパフォーマンスする並行 Ruby を書くために重要です。

並行処理は一般的なニーズであり、GVL は基本的に正しいアプローチを形作るため、スレッドが CPU 作業を並列化しない理由、I/O に役立つこと、CPU 並列性にはプロセスが必要なこと を理解することは — 重大な誤りを防ぎ、Ruby の並行処理モデルとその GVL 制約の理解を反映する一般的なインタビュートピックである — 重要なシニアレベルの知識です。