อะไรเป็นสาเหตุของ goroutine leak และคุณจะป้องกันได้อย่างไร?

Question

Accepted Answer

**goroutine leak** คือ goroutine ที่ไม่เคยสิ้นสุด มันค้างอยู่ในสถานะ block หรือทำงานไปตลอด ใช้หน่วยความจำ (และทำให้ object ที่มัน reference ยังคงอยู่) ตลอดช่วงชีวิตของโปรแกรม เนื่องจาก goroutine มีต้นทุนต่ำในการสร้าง จึง leak ได้ง่าย และ leak จะสะสมเงียบ ๆ จนกระทั่ง service เสื่อมประสิทธิภาพหรือหน่วยความจำหมด

## สาเหตุที่ 1: block อยู่บน channel ที่ไม่มี sender/receiver

```go
// ❌ LEAK — this goroutine blocks forever waiting to send
func leak() {
    ch := make(chan int)   // unbuffered
    go func() {
        ch <- 42           // blocks forever — NOBODY ever receives
    }()                     // the goroutine is stuck, never exits
    // function returns without reading ch → the goroutine leaks
}
```

goroutine ที่ block อยู่บนการ send/receive ของ channel ที่ไม่เคยเสร็จสมบูรณ์จะรอ **ตลอดไป** มันไม่เคยถูก garbage collect เพราะในทางเทคนิคมันยัง "กำลังทำงาน" อยู่

## สาเหตุที่ 2: ไม่มี cancellation / done signal

```go
// ❌ LEAK — a goroutine in an infinite loop with no way to stop
func worker(jobs <-chan int) {
    for {
        job := <-jobs      // blocks forever if jobs is never closed and stops sending
        process(job)
    }                       // no exit condition — leaks when no longer needed
}
```

## การป้องกันที่ 1: ใช้ context สำหรับ cancellation

```go
// ✅ the goroutine can be told to stop
func worker(ctx context.Context, jobs <-chan int) {
    for {
        select {
        case job := <-jobs:
            process(job)
        case <-ctx.Done():       // cancellation signal → exit cleanly
            return                // the goroutine terminates, no leak
        }
    }
}
// caller: ctx, cancel := context.WithCancel(...); defer cancel()
```

การให้ทุก goroutine ที่อยู่นานมีวิธีถูกยกเลิก (`<-ctx.Done()`) เป็นแนวป้องกันหลัก มันรับประกันว่า goroutine จะสิ้นสุดเมื่องานไม่จำเป็นอีกต่อไป

## การป้องกันที่ 2: ใช้ buffered channel หรือมั่นใจว่ามี receiver

```go
// ✅ ensure a receiver exists, or use a buffered channel so the send doesn't block
ch := make(chan int, 1)   // buffered → the send completes even if no one receives yet
go func() { ch <- 42 }()   // doesn't block
```

## การป้องกันที่ 3: ปิด channel เสมอ / drain ให้เหมาะสม

```go
// ✅ close channels so range loops terminate
go func() {
    defer close(results)    // signal completion → for-range over results ends
    for _, job := range jobs { results <- process(job) }
}()
```

## การตรวจจับ leak

```go
runtime.NumGoroutine()         // monitor the goroutine count — steady growth = leak
import _ "net/http/pprof"      // pprof exposes goroutine stacks (/debug/pprof/goroutine)
// the goleak library asserts no leaked goroutines in tests
```

การ monitor `runtime.NumGoroutine()` (จำนวนที่ไต่ขึ้นเรื่อย ๆ เป็นสัญญาณของ leak), การตรวจสอบ goroutine dump ผ่าน `pprof` และการใช้ `goleak` ใน test คือเครื่องมือตรวจจับหลัก

## ทำไมจึงสำคัญ

goroutine leak เป็นหนึ่งในปัญหาที่พบบ่อยที่สุดและร้ายกาจที่สุดใน Go service ระดับ production

เนื่องจาก goroutine มีต้นทุนต่ำมากในการเรียกใช้ นักพัฒนาจึงสร้างมันอย่างอิสระ แต่ goroutine ที่ block ตลอดไป (บน channel ที่ไม่มีคู่ หรือใน infinite loop ที่ไม่มี cancellation) **จะไม่เคยสิ้นสุดและไม่เคยปล่อยหน่วยความจำของมัน** (รวมถึงทุกอย่างที่มัน reference)

ใน server ที่ทำงานยาวนาน leak เหล่านี้จะสะสมเงียบ ๆ ค่อย ๆ กินหน่วยความจำจนกระทั่ง service เสื่อมประสิทธิภาพหรือ crash และมันยากที่จะสังเกตเพราะไม่มี error ที่เกิดขึ้นทันที

การเข้าใจสาเหตุ (การ block บน channel operation, การขาด cancellation) และการป้องกัน (**context-based cancellation** เป็นแนวป้องกันหลัก, การปิด channel อย่างเหมาะสม, buffered channel, การมั่นใจว่ามี receiver) เป็นสิ่งจำเป็นสำหรับการเขียน Go ที่ concurrent และเชื่อถือได้

การรู้จักเครื่องมือตรวจจับ (`runtime.NumGoroutine`, pprof, goleak) ก็สำคัญไม่แพ้กัน

นี่คือหัวข้อสำคัญที่ถูกถามบ่อย ซึ่งแยกแยะนักพัฒนาที่สามารถเขียน Go แบบ concurrent ระดับ production ออกจากผู้ที่เขียนโค้ดที่ leak ภายใต้ภาระงานต่อเนื่อง