GVL là gì và concurrency hoạt động thế nào trong Ruby?

Question

Accepted Answer

**GVL** (Global VM Lock, trước đây là GIL) trong MRI Ruby chỉ cho phép **một thread thực thi code Ruby tại một thời điểm** — nên thread không cung cấp song song CPU thực sự. Nhưng GVL được **giải phóng trong khi I/O**, nên thread *thực sự* giúp ích cho công việc thiên về I/O. Cho song song CPU, bạn dùng nhiều tiến trình. Điều này phản ánh tình huống GIL của Python.

## GVL: một thread chạy code Ruby tại một thời điểm

```text
MRI (Ruby chuẩn) có một GLOBAL VM LOCK:
  → chỉ MỘT thread thực thi code Ruby tại bất kỳ thời điểm nào (không có song song CPU từ thread)
  → NHƯNG GVL được GIẢI PHÓNG trong khi I/O bị chặn (mạng, file, DB)
Vậy: thread giúp ích cho công việc thiên về I/O, KHÔNG cho công việc thiên về CPU.
```

## Thread — tốt cho concurrency thiên về I/O

```ruby
# ✅ thiên về I/O — thread chồng lấp thời gian chờ (GVL giải phóng khi I/O) → lợi ích thực
threads = urls.map do |url|
  Thread.new { fetch(url) }      # khi một thread chờ mạng, các thread khác tiến hành
end
threads.each(&:join)

# ❌ thiên về CPU — thread KHÔNG tăng tốc việc này (GVL tuần tự hóa việc thực thi Ruby)
threads = data.map { |d| Thread.new { heavy_computation(d) } }  # không tăng tốc
```

Thread giúp ích cho công việc thiên về I/O (mạng, file, DB) vì GVL được giải phóng trong khi chờ, cho phép các thread khác chạy. Chúng **không** tăng tốc công việc thiên về CPU (GVL tuần tự hóa việc thực thi Ruby).

## Tiến trình — cho song song thiên về CPU

```ruby
# ✅ song song thiên về CPU → dùng nhiều TIẾN TRÌNH (mỗi cái có GVL riêng)
# fork, hoặc các gem như Parallel:
results = Parallel.map(data, in_processes: 4) { |d| heavy_computation(d) }
# → 4 tiến trình riêng biệt, song song thực sự trên các core
```

Cho song song thiên về CPU, dùng **nhiều tiến trình** (mỗi cái có GVL/interpreter riêng) — `fork`, gem `parallel`, hoặc chạy nhiều worker process (cách các server Rails như Puma mở rộng quy mô).

## Các công cụ concurrency hiện đại

```text
✓ Ractor (Ruby 3) — song song theo mô hình actor có thể CHẠY Ruby song song (không chia sẻ GVL
  cho mỗi Ractor) — thử nghiệm, song song thực sự
✓ Fiber / gem async — concurrency hợp tác nhẹ cho các tải nặng-I/O
✓ Background job (Sidekiq) — chuyển công việc sang các worker process riêng biệt
Lưu ý: các bản triển khai Ruby thay thế (JRuby, TruffleRuby) KHÔNG có GVL → song song thread thực sự
```

## Tại sao điều này quan trọng

Hiểu GVL và concurrency của Ruby là kiến thức quan trọng — và thường bị hiểu lầm — để xây dựng các ứng dụng Ruby hiệu năng cao, giống như tình huống GIL của Python.

Hiểu biết then chốt là **GVL của MRI Ruby chỉ cho phép một thread thực thi code Ruby tại một thời điểm**, nên thread *không* cung cấp song song CPU — một điểm gây nhầm lẫn thường gặp.

Quan trọng nhất, GVL được **giải phóng trong khi I/O**, có nghĩa cách tiếp cận concurrency đúng phụ thuộc vào loại tải: **thread hoạt động tốt cho các tác vụ thiên về I/O** (gọi mạng, truy cập file/database — nơi GVL được giải phóng trong khi chờ, cho phép các thread chồng lấp), nhưng **song song thiên về CPU yêu cầu nhiều tiến trình** (mỗi cái có GVL riêng, đạt song song thực sự trên các core — qua `fork`, gem `parallel`, hoặc nhiều worker process, đó là cách các server Rails mở rộng quy mô).

Hiểu lầm GVL dẫn đến code concurrency không hiệu quả (ví dụ dùng thread cho công việc nặng-CPU mong đợi tăng tốc).

Biết quyết định I/O-với-CPU (thread cho concurrency I/O, tiến trình cho song song CPU), các công cụ hiện đại (Ractor cho song song thực sự thử nghiệm, Fiber/async cho concurrency hợp tác nặng-I/O, các trình xử lý background job như Sidekiq), và rằng các bản triển khai thay thế (JRuby, TruffleRuby) không có GVL là quan trọng để viết Ruby concurrent thực sự hoạt động hiệu quả.

Vì concurrency là nhu cầu thường gặp và GVL về cơ bản định hình cách tiếp cận đúng, hiểu nó — vì sao thread không song song hóa công việc CPU, rằng chúng giúp ích cho I/O, và rằng tiến trình cần thiết cho song song CPU — là kiến thức cấp senior quan trọng ngăn một sai lầm thường gặp và là chủ đề phỏng vấn thường gặp phản ánh sự hiểu biết về mô hình concurrency của Ruby và ràng buộc GVL của nó.