O GVL (Global VM Lock, anteriormente GIL) em MRI Ruby permite que apenas uma thread execute código Ruby por vez — portanto, threads não oferecem paralelismo verdadeiro de CPU. Mas o GVL é liberado durante I/O, então threads fazem ajudar em trabalho vinculado a I/O. Para paralelismo de CPU, você usa múltiplos processos. Isso espelha a situação do GIL do Python.
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-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
Threads ajudam em trabalho vinculado a I/O (rede, arquivo, BD) porque o GVL é liberado durante a espera, permitindo que outras threads sejam executadas. Elas não aceleram trabalho vinculado a CPU (o GVL serializa a execução 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
Para paralelismo vinculado a CPU, use múltiplos processos (cada um com seu próprio GVL/interpretador) — fork, a gem parallel, ou executar múltiplos processos worker (como servidores Rails como Puma escalam).
✓ 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
Compreender o GVL e a concorrência em Ruby é conhecimento importante — e frequentemente mal compreendido — para construir aplicações Ruby de alto desempenho, assim como a situação do GIL do Python.
O insight-chave é que o GVL de MRI Ruby permite apenas uma thread executar código Ruby por vez, portanto threads não oferecem paralelismo de CPU — um ponto de confusão comum.
Criticamente, o GVL é liberado durante I/O, o que significa que a abordagem correta de concorrência depende da carga de trabalho: threads funcionam bem para tarefas vinculadas a I/O (chamadas de rede, acesso a arquivo/banco de dados — onde o GVL é liberado durante esperas, permitindo que threads se sobreponham), mas paralelismo vinculado a CPU requer múltiplos processos (cada um com seu próprio GVL, alcançando verdadeiro paralelismo entre núcleos — via fork, a gem parallel, ou múltiplos processos worker, que é como servidores Rails escalam).
Mal-entender o GVL leva a código de concorrência ineficaz (por exemplo, usar threads para trabalho intensivo em CPU esperando aceleração).
Saber a decisão I/O-vs-CPU (threads para concorrência de I/O, processos para paralelismo de CPU), ferramentas modernas (Ractors para paralelismo verdadeiro experimental, Fibers/async para concorrência cooperativa de alto I/O, processadores de job em background como Sidekiq), e que implementações alternativas (JRuby, TruffleRuby) carecem do GVL é importante para escrever Ruby concorrente que realmente tem desempenho.
Como concorrência é uma necessidade comum e o GVL molda fundamentalmente a abordagem correta, compreendê-lo — por que threads não paralelizam trabalho de CPU, que elas ajudam para I/O, e que processos são necessários para paralelismo de CPU — é conhecimento importante de nível sênior que previne um erro frequente e é um tópico comum em entrevistas refletindo compreensão do modelo de concorrência do Ruby e sua restrição de GVL.