Apa yang menyebabkan goroutine leaks dan bagaimana cara mencegahnya?

Question

Accepted Answer

A **goroutine leak** adalah goroutine yang tidak pernah berhenti — tetap terblokir atau berjalan selamanya, mengonsumsi memori (dan membuat objek yang dirujuknya tetap hidup) selama program berjalan. Karena goroutine murah untuk dimulai, mudah untuk membocornya, dan kebocoran terakumulasi secara diam-diam hingga layanan menurun atau kehabisan memori.

## Penyebab 1: terblokir pada channel tanpa pengirim/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
}
```

Goroutine yang terblokir pada pengiriman/penerimaan channel yang tidak pernah selesai akan menunggu **selamanya** — tidak pernah sampah dikumpulkan karena secara teknis masih "berjalan".

## Penyebab 2: tidak ada pembatalan / sinyal 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()
```

Memberikan setiap goroutine yang berumur panjang cara untuk dibatalkan (`<-ctx.Done()`) adalah pertahanan utama — memastikan goroutine berhenti ketika pekerjaan mereka tidak lagi diperlukan.

## Pencegahan 2: gunakan buffered channels 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: selalu tutup channels / drain mereka dengan benar

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

## Mendeteksi 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()` (hitungan yang terus meningkat menandakan kebocoran), memeriksa goroutine dumps melalui `pprof`, dan menggunakan `goleak` dalam tes adalah alat deteksi utama.

## Mengapa ini penting

Goroutine leaks adalah salah satu masalah paling umum dan berbahaya dalam layanan Go produksi.

Karena goroutine sangat murah untuk diluncurkan, pengembang membuatnya dengan bebas — tetapi goroutine yang terblokir selamanya (pada channel tanpa pasangan, atau dalam loop infinite tanpa pembatalan) **tidak pernah berhenti dan tidak pernah melepaskan memorinya** (termasuk semua yang dirujuknya).

Dalam server yang berjalan lama, kebocoran ini terakumulasi secara diam-diam, secara bertahap mengonsumsi memori hingga layanan menurun atau crash — dan sulit untuk dideteksi karena tidak ada kesalahan langsung.

Memahami penyebabnya (operasi channel yang terblokir, pembatalan yang hilang) dan pencegahannya (**pembatalan berbasis context** sebagai pertahanan utama, penutupan channel yang tepat, buffered channels, memastikan ada penerima) sangat penting untuk menulis Go konkuren yang andal.

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

Ini adalah topik yang kritis dan sering diuji yang membedakan pengembang yang dapat menulis Go konkuren tingkat produksi dari mereka yang menulis kode yang bocor di bawah beban berkelanjutan.