Apakah yang menyebabkan kebocoran goroutine dan bagaimana anda mencegahnya?

Question

Accepted Answer

Sebuah **kebocoran goroutine** ialah goroutine yang tidak pernah tamat — ia kekal tersekat atau berjalan selama-lamanya, memakan memori (dan mengekalkan objek yang dirujuknya tetap hidup) sepanjang hayat program. Oleh kerana goroutine murah untuk dimulakan, ia mudah dibocorkan, dan kebocoran terkumpul secara senyap sehingga perkhidmatan merosot atau kehabisan memori.

## Sebab 1: tersekat pada channel tanpa penghantar/penerima

```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
}
```

Sebuah goroutine yang tersekat pada penghantaran/penerimaan channel yang tidak pernah selesai akan menunggu **selama-lamanya** — ia tidak pernah dikumpul sebagai sampah kerana secara teknikalnya ia masih "berjalan."

## Sebab 2: tiada pembatalan / isyarat selesai

```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
}
```

## Pencegahan 1: gunakan context untuk pembatalan

```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()
```

Memberi setiap goroutine berhayat panjang satu cara untuk dibatalkan (`<-ctx.Done()`) ialah pertahanan utama — ia memastikan goroutine tamat apabila kerjanya tidak lagi diperlukan.

## Pencegahan 2: gunakan channel buffered atau pastikan ada penerima

```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
```

## Pencegahan 3: sentiasa tutup channel / saliran dengan betul

```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) }
}()
```

## Mengesan kebocoran

```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
```

Memantau `runtime.NumGoroutine()` (kiraan yang meningkat secara berterusan menandakan kebocoran), memeriksa lambakan goroutine melalui `pprof`, dan menggunakan `goleak` dalam ujian ialah alat pengesanan utama.

## Mengapa ia penting

Kebocoran goroutine adalah antara masalah yang paling biasa dan licik dalam perkhidmatan Go pengeluaran.

Oleh kerana goroutine sangat murah untuk dilancarkan, pembangun menciptanya dengan bebas — tetapi goroutine yang tersekat selama-lamanya (pada channel tanpa pasangan, atau dalam gelung tak terhingga tanpa pembatalan) **tidak pernah tamat dan tidak pernah melepaskan memorinya** (termasuk segala yang dirujuknya).

Dalam pelayan berjalan lama, kebocoran ini terkumpul secara senyap, beransur-ansur memakan memori sehingga perkhidmatan merosot atau terhenti — dan ia sukar dikesan kerana tiada ralat segera.

Memahami punca (operasi channel tersekat, ketiadaan pembatalan) dan pencegahan (**pembatalan berasaskan context** sebagai pertahanan utama, penutupan channel yang betul, channel buffered, memastikan ada penerima) adalah penting untuk menulis Go serentak yang boleh dipercayai.

Mengetahui alat pengesanan (`runtime.NumGoroutine`, pprof, goleak) sama pentingnya.

Ini topik kritikal yang kerap diuji yang membezakan pembangun yang boleh menulis Go serentak gred pengeluaran daripada mereka yang menulis kod yang bocor di bawah beban berterusan.