Что такое GVL и как работает параллелизм в Ruby?

Question

Accepted Answer

**GVL** (Global VM Lock, ранее GIL) в MRI Ruby позволяет **только одному потоку одновременно выполнять код Ruby** — поэтому потоки не обеспечивают истинный параллелизм на CPU. Но GVL **освобождается во время операций ввода-вывода**, поэтому потоки *действительно* помогают для работы с I/O. Для параллелизма на CPU используются несколько процессов. Это отражает ситуацию с GIL в Python.

## 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`, gem `parallel` или запуск нескольких рабочих процессов (так масштабируются серверы Rails, такие как Puma).

## Современные инструменты параллелизма

```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, подобно ситуации с GIL в Python.

Ключевое понимание заключается в том, что **GVL в MRI Ruby позволяет только одному потоку одновременно выполнять код Ruby**, поэтому потоки *не* обеспечивают параллелизм на CPU — это частый источник ошибок.

Критически важно, что GVL **освобождается во время операций ввода-вывода**, что означает, что правильный подход к параллелизму зависит от типа рабочей нагрузки: **потоки хорошо работают для задач, связанных с I/O** (сетевые вызовы, доступ к файлам/базам данных — где GVL освобождается во время ожидания, позволяя потокам перекрываться), но **параллелизм на CPU требует нескольких процессов** (каждый со своим GVL, достигая истинного параллелизма на нескольких ядрах — через `fork`, gem `parallel` или несколько рабочих процессов, что является способом масштабирования серверов Rails).

Неправильное понимание GVL приводит к неэффективному коду параллелизма (например, использование потоков для CPU-интенсивной работы в ожидании ускорения).

Знание решения для выбора между I/O и CPU (потоки для параллелизма I/O, процессы для параллелизма CPU), современные инструменты (Ractors для экспериментального истинного параллелизма, Fibers/async для кооперативного параллелизма с высоким I/O, обработчики фоновых задач, такие как Sidekiq), и то, что альтернативные реализации (JRuby, TruffleRuby) не имеют GVL — это важно для написания параллельного кода на Ruby, который действительно работает эффективно.

Поскольку параллелизм — это частая потребность и GVL принципиально определяет правильный подход, понимание его — почему потоки не параллелизируют работу CPU, что они помогают для I/O, и что процессы необходимы для параллелизма CPU — это важное знание уровня старшего разработчика, которое предотвращает частую ошибку и является распространённой темой собеседования, отражающей понимание модели параллелизма Ruby и её ограничения GVL.