GVL คืออะไร และ concurrency ทำงานอย่างไรใน Ruby?

Question

Accepted Answer

**GVL** (Global VM Lock เดิมคือ GIL) ใน MRI Ruby อนุญาตให้มีเพียง **เธรดเดียวเท่านั้นที่รันโค้ด Ruby ได้ในแต่ละช่วงเวลา** — ดังนั้นเธรดจึงไม่ให้ความขนานของ CPU ที่แท้จริง แต่ GVL จะ **ถูกปล่อยระหว่าง I/O** ดังนั้นเธรด *จึง* ช่วยได้สำหรับงานที่ผูกกับ I/O (I/O-bound) สำหรับความขนานของ 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.
```

## เธรด — ดีสำหรับ concurrency แบบ I/O-bound

```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-bound (network, file, DB) เพราะ GVL ถูกปล่อยระหว่างการรอ ทำให้เธรดอื่นรันได้ พวกมัน **ไม่** ช่วยเร่งความเร็วงานแบบ CPU-bound (GVL ทำให้การรัน Ruby เป็นแบบลำดับ)

## โปรเซส — สำหรับความขนานแบบ CPU-bound

```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-bound ให้ใช้ **หลายโปรเซส** (แต่ละตัวมี GVL/ตัวแปลภาษาของตัวเอง) — `fork`, gem `parallel` หรือการรัน worker หลายโปรเซส (เป็นวิธีที่ Rails server อย่าง Puma ขยายขนาด)

## เครื่องมือ concurrency สมัยใหม่

```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 และ concurrency ของ Ruby เป็นความรู้ที่สำคัญ — และมักถูกเข้าใจผิดบ่อย — สำหรับการสร้างแอปพลิเคชัน Ruby ที่มีประสิทธิภาพ คล้ายกับสถานการณ์ GIL ของ Python

ข้อมูลเชิงลึกหลักคือ **GVL ของ MRI Ruby อนุญาตให้มีเพียงเธรดเดียวรันโค้ด Ruby ได้ในแต่ละช่วงเวลา** ดังนั้นเธรดจึง *ไม่* ให้ความขนานของ CPU — เป็นจุดที่สับสนกันบ่อย

ที่สำคัญอย่างยิ่ง GVL จะ **ถูกปล่อยระหว่าง I/O** ซึ่งหมายความว่าแนวทาง concurrency ที่ถูกต้องขึ้นอยู่กับภาระงาน: **เธรดทำงานได้ดีสำหรับงานแบบ I/O-bound** (การเรียกผ่าน network, การเข้าถึงไฟล์/ฐานข้อมูล — ที่ GVL ถูกปล่อยระหว่างการรอ ทำให้เธรดทับซ้อนกันได้) แต่ **ความขนานแบบ CPU-bound ต้องใช้หลายโปรเซส** (แต่ละตัวมี GVL ของตัวเอง บรรลุความขนานที่แท้จริงข้ามคอร์ — ผ่าน `fork`, gem `parallel` หรือ worker หลายโปรเซส ซึ่งเป็นวิธีที่ Rails server ขยายขนาด)

การเข้าใจ GVL ผิดนำไปสู่โค้ด concurrency ที่ไม่มีประสิทธิภาพ (เช่น ใช้เธรดสำหรับงานที่ใช้ CPU หนักโดยคาดหวังว่าจะเร็วขึ้น)

การรู้การตัดสินใจระหว่าง I/O กับ CPU (เธรดสำหรับ concurrency แบบ I/O, โปรเซสสำหรับความขนานของ CPU), เครื่องมือสมัยใหม่ (Ractor สำหรับความขนานที่แท้จริงในเชิงทดลอง, Fiber/async สำหรับ concurrency แบบ cooperative ที่มี I/O สูง, ตัวประมวลผล background job อย่าง Sidekiq) และว่า implementation ทางเลือก (JRuby, TruffleRuby) ไม่มี GVL เป็นสิ่งสำคัญสำหรับการเขียน Ruby แบบ concurrent ที่ทำงานได้มีประสิทธิภาพจริง

เนื่องจาก concurrency เป็นความต้องการที่พบบ่อยและ GVL กำหนดแนวทางที่ถูกต้องโดยพื้นฐาน การเข้าใจมัน — ว่าทำไมเธรดไม่ทำให้งาน CPU ขนานกัน, ว่ามันช่วยสำหรับ I/O และว่าต้องใช้โปรเซสสำหรับความขนานของ CPU — จึงเป็นความรู้ระดับ senior ที่สำคัญซึ่งป้องกันความผิดพลาดที่พบบ่อยและเป็นหัวข้อสัมภาษณ์ที่พบบ่อยซึ่งสะท้อนความเข้าใจโมเดล concurrency ของ Ruby และข้อจำกัด GVL ของมัน