Bagaimana cara mendiagnosis kebocoran goroutine dan meningkatkan versi ke Go 1.26 dengan aman?

1. Skenario dan kriteria keberhasilan

Layanan memulai beberapa worker untuk setiap batch dan menggabungkan hasilnya melalui sebuah channel. Ketika salah satu worker mengembalikan error, pemanggil kembali lebih awal. Selama lonjakan trafik, memori dan jumlah goroutine meningkat hingga memulai ulang instans membantu untuk sementara. Peningkatan versi harus menemukan goroutine yang tidak dapat membuka blokir, mempertahankan semantik pembatalan, membandingkan perilaku GC Go 1.26, dan menyediakan peluncuran yang dapat dibatalkan (reversible).

Mulailah dengan data dasar (baseline): persentil latensi permintaan, throughput, ukuran heap, CPU GC, goroutine aktif, kemiringan (slope) kebocoran, dan tingkat error. runtime.NumGoroutine saja tidak dapat memberi tahu goroutine mana yang sebenarnya bocor.

2. Perubahan relevan pada Go 1.26

Go 1.26 memperkenalkan profil pprof goroutineleak eksperimental untuk kelas goroutine yang terblokir secara permanen dan tidak dapat bangun. Aktifkan dengan GOEXPERIMENT=goroutineleakprofile dan ekspos melalui net/http/pprof. Ini bergantung pada keterjangkauan garbage-collector dan tidak dapat mengidentifikasi setiap kebocoran, jadi perlakukan ini sebagai sinyal diagnostik, bukan bukti ketidakhadiran kebocoran.

Rilis ini juga menyediakan pemodernisasi go fix, memungkinkan new menerima sebuah ekspresi, dan mengaktifkan Green Tea GC secara default. Evaluasi kemudahan bahasa, diagnostik eksperimental, dan perubahan runtime secara terpisah sehingga satu benchmark tidak mencampurkan variabel yang tidak terkait.

3. Buat reproduksi kebocoran minimal

Pola ini mengembalikan nilai pada error pertama sementara worker lain masih mengirim ke channel tanpa buffer dan akhirnya terblokir selamanya:

func processWorkItems(ctx context.Context, ws []WorkItem) ([]Result, error) {
    ch := make(chan result)
    for _, w := range ws {
        go func() {
            value, err := process(ctx, w)
            ch <- result{value: value, err: err}
        }()
    }

    results := make([]Result, 0, len(ws))
    for range ws {
        r := <-ch
        if r.err != nil {
            return nil, r.err
        }
        results = append(results, r.value)
    }
    return results, nil
}

Sisipkan error deterministik, ulangi eksekusi, dan tingkatkan ukuran batch sambil mengamati jumlah goroutine. Sertakan jalur pembatalan pemanggil, batas waktu, dan penyelesaian yang sukses sehingga perbaikan tidak hanya mencakup happy path.

4. Perbaiki pembatalan, penutupan, dan backpressure

Buat pengirim mematuhi ctx.Done() dan pastikan pembatalan penerima tidak meninggalkan pengirim di belakang. Channel dengan buffer yang memiliki kapasitas eksplisit dapat bekerja, begitu juga satu goroutine koordinator yang bertanggung jawab atas penutupan dan agregasi. Beberapa worker tidak boleh berlomba untuk menutup satu channel yang sama.

select {
case ch <- result{value: value, err: err}:
case <-ctx.Done():
}

Perbaikan lengkap membatalkan konteks turunan pada error pertama, menunggu semua worker keluar, lalu mengembalikan error tersebut. errgroup.WithContext dapat mengoordinasikan siklus hidup tersebut, tetapi setiap worker masih harus menyebarkan konteks dan menerapkan batas waktu pada I/O eksternal.

5. Aktifkan profil goroutineleak dan kumpulkan bukti

Bangun biner terisolasi dengan GOEXPERIMENT=goroutineleakprofile dan lakukan sampling pada endpoint pprof yang terlindungi. Bandingkan profil kebocoran, stack goroutine, profil heap, trace, dan metrik bisnis pada rentang waktu yang sama. Profil yang kosong tidak membuktikan bahwa tidak ada kebocoran: primitif pemblokiran yang dapat dijangkau dari variabel global mungkin tidak diklasifikasikan oleh mekanisme ini.

Lakukan sampling selama beban dan injeksi kesalahan, catat versi Go, flag eksperimen, beban permintaan, dan interval sampling. Di lingkungan produksi, batasi akses endpoint, frekuensi sampling, dan retensi agar diagnostik tidak menjadi celah paparan informasi.

6. Evaluasi Green Tea GC dan kompatibilitas pembaruan

Go 1.26 mengaktifkan Green Tea GC secara default. Catatan rilis menjelaskan tujuan lokalitas yang lebih baik dan skalabilitas CPU saat menandai dan memindai objek kecil, tetapi manfaatnya bergantung pada beban kerja. Pisahkan CPU GC, waktu jeda, puncak heap, dan latensi permintaan dalam benchmark dan bandingkan dengan versi lama pada perangkat keras, flag kompilator, dan lalu lintas yang identik.

Jika terjadi regresi, gunakan sementara GOEXPERIMENT=nogreenteagc sebagai kontrol diagnostik sebelum memutuskan apakah akan melaporkannya. Jangan mengubah opt-out eksperimental menjadi arsitektur permanen. Validasi perilaku race condition, cgo, plugin, dan dependensi dalam penerapan canary sebelum meningkatkan lalu lintas.

7. Gunakan go fix sebagai modernisasi yang dapat diaudit

go fix menggunakan kerangka analisis yang sama dengan go vet untuk menerapkan pemodernisasi yang mempertahankan perilaku; sintaks new(expr) Go 1.26 adalah target yang representatif. Jalankan pada sebuah branch dan tinjau setiap diff, lalu gunakan kompilasi, pengujian unit, deteksi race, dan benchmark untuk mengonfirmasi semantiknya.

Jangan menulis ulang seluruh basis kode hanya untuk mengikuti versi baru. Pisahkan perbaikan otomatis dari perbaikan kebocoran dan pembaruan GC sehingga satu risiko dapat dibatalkan (rollback) tanpa menghapus perbaikan lainnya. Gunakan arahan go eksplisit dan batasan build untuk kode yang dihasilkan dan modul lintas versi.

8. Rubrik dan tindak lanjut

Harus dijelaskan

• Jelaskan penyebab pemblokiran dan perbaiki masa pakai worker dengan pembatalan, penutupan, dan backpressure.
• Ketahui bahwa goroutineleak adalah profil eksperimental berbasis keterjangkauan yang tidak dapat mencakup setiap kebocoran.
• Pisahkan Green Tea GC, go fix, dan pembaruan versi ke dalam data dasar independen, pemeriksaan canary, dan langkah rollback.

Pertanyaan lanjutan

• Jika sebuah channel yang bocor dipegang oleh registry global, mengapa profil tersebut mungkin melewatkannya, dan bukti apa yang akan Anda tambahkan?
• Setelah error pertama, bagaimana Anda memastikan panggilan jaringan yang terblokir juga keluar?
• Kapan Anda akan menggunakan GOEXPERIMENT=nogreenteagc, dan bagaimana Anda menghindari penyamaran masalah yang sebenarnya?

Panduan penilaian

Jawaban yang sangat baik menghubungkan reproduksi, perbaikan siklus hidup, bukti diagnostik, dan tata kelola peningkatan: buat setiap worker dapat dibatalkan, konfirmasikan dengan profil dan stack, lalu buktikan keamanan runtime dengan benchmark terisolasi dan canary.