Goroutine — concurrency yang murah

Goroutine cuma butuh beberapa kilobita, jadi puluhan ribu sekaligus itu wajar. Justru karena murah, kesalahan yang paling sering terjadi adalah membuat goroutine yang tidak pernah selesai.

Menjalankan dan menunggu

go kirimEmail(u)         // jalan sekarang, tidak ditunggu

// Menunggu sekelompok goroutine selesai
var wg sync.WaitGroup
for _, u := range pengguna {
	wg.Add(1)
	go func() {
		defer wg.Done()
		kirimEmail(u)   // Go 1.22+: u aman dipakai langsung
	}()
}
wg.Wait()

Murah, tapi bukan gratis

Penjadwal Go memetakan banyak goroutine ke sedikit thread OS. Saat sebuah goroutine menunggu I/O — kueri database, panggilan HTTP — thread-nya dipakai goroutine lain. Inilah alasan satu proses Go bisa menangani puluhan ribu koneksi tanpa konfigurasi apa pun, dan kenapa "worker mode" yang jadi topik besar di dunia PHP tidak pernah jadi topik di Go.

Kebocoran goroutine

// ❌ BOCOR — tidak ada yang membaca dari ch, goroutine ini menunggu selamanya
func bocor() {
	ch := make(chan int)
	go func() {
		ch <- hitungLama()   // menggantung di sini, sampai proses mati
	}()
	// fungsi keluar tanpa membaca ch
}

Goroutine yang menunggu channel yang tidak akan pernah ditulis/dibaca tidak pernah dibersihkan oleh garbage collector — ia bukan sampah, ia hidup. Gejalanya khas: memori dan jumlah goroutine naik pelan selama berhari-hari, lalu container di-OOM-kill.

// ✅ Dua perbaikan: buffer 1, ATAU context yang membatasi
func aman(ctx context.Context) (int, error) {
	ch := make(chan int, 1)     // pengirim tidak pernah tertahan
	go func() { ch <- hitungLama() }()

	select {
	case v := <-ch:
		return v, nil
	case <-ctx.Done():
		return 0, ctx.Err()     // goroutine tetap bisa mengirim, lalu selesai
	}
}

Mendeteksinya

# jumlah goroutine hidup — endpoint pprof (Fase 9)
curl localhost:6060/debug/pprof/goroutine?debug=1 | head -20

Tiga kesalahan yang wajar terjadi sekali

1. main tidak menunggu

func main() {
	go kirimLaporan()   // kemungkinan besar tidak pernah jalan
}                        // proses keluar; semua goroutine dimatikan seketika

Tidak ada defer yang dijalankan di goroutine yang mati begini. Untuk server, ini yang membuat graceful shutdown (Fase 3) bukan hiasan: tanpa itu, permintaan yang sedang diproses terpotong di tengah.

2. Menyebar ke goroutine yang salah

// ❌ handler HTTP yang memakai r.Context() di goroutine latar
go func() {
	simpanAudit(r.Context(), data)   // ctx dibatalkan begitu respons terkirim
}()

// ✅ konteks baru yang lepas dari umur permintaan
ctx := context.WithoutCancel(r.Context())   // Go 1.21+
go func() {
	ctx, batal := context.WithTimeout(ctx, 10*time.Second)
	defer batal()
	simpanAudit(ctx, data)
}()

3. Tidak ada yang menangkap error

// ❌ error hilang, panic mematikan proses
go prosesBerkas(f)

// ✅ errgroup mengumpulkan error dan membatalkan sisanya
g, ctx := errgroup.WithContext(ctx)
for _, f := range berkas {
	g.Go(func() error { return prosesBerkas(ctx, f) })
}
if err := g.Wait(); err != nil { ... }

Aturan yang menghindarkan semuanya

1. Setiap goroutine punya pemilik yang tahu kapan ia berhenti — lewat WaitGroup, errgroup, atau context.
2. Setiap goroutine berumur panjang punya recover-nya sendiri (Fase 1) — kalau tidak, satu panic mematikan seluruh container.
3. Jangan buat goroutine di dalam pustaka tanpa memberi pemanggilnya cara menghentikan.
4. Batasi jumlahnya. "Satu goroutine per item" pada daftar sejuta item akan membuka sejuta koneksi — dan database-mu yang mati duluan.