Channel di Golang: Buffered, Unbuffered, Close, dan Range

Mengirim dan menerima

Channel adalah pipa bertipe di antara goroutine. ch <- v mengirim, <-ch menerima. Buat channel dengan make:

package main

import "fmt"

func main() {
	messages := make(chan string)

	go func() {
		messages <- "ping" // blocks until main receives
	}()

	msg := <-messages // blocks until the goroutine sends
	fmt.Println(msg)
}

Zero value dari tipe channel adalah nil, jadi var ch chan string tanpa make memberimu channel yang tertahan selamanya. Selalu buat channel dengan make.

Channel unbuffered menyinkronkan

make(chan T) membuat channel unbuffered. Pengiriman tertahan sampai ada penerima yang mengambil nilainya, dan penerimaan tertahan sampai ada pengirim yang memberikannya. Kedua goroutine bertemu di titik itu, sehingga channel unbuffered sama pentingnya sebagai alat sinkronisasi maupun sebagai pipa data. Saat <-done di bawah ini selesai, kamu tahu worker sudah menyelesaikan semua yang ada sebelum pengirimannya:

package main

import "fmt"

func main() {
	done := make(chan struct{})
	result := 0

	go func() {
		for i := 1; i <= 100; i++ {
			result += i
		}
		done <- struct{}{} // signal: finished
	}()

	<-done
	fmt.Println("sum:", result)
}

Membaca result di main aman di sini tanpa mutex. Model memori Go menjamin bahwa semua yang dilakukan worker sebelum pengiriman terlihat oleh main setelah penerimaan yang cocok. chan struct{} adalah tipe yang idiomatis untuk sinyal murni, karena struct{} tidak memakai memori.

Channel buffered

make(chan T, n) memberi channel ruang untuk n nilai. Pengiriman berhasil tanpa penerima sampai buffer penuh; penerimaan berhasil sampai buffer kosong. Nilai keluar dengan urutan yang sama seperti saat masuk.

package main

import "fmt"

func main() {
	ch := make(chan int, 3)

	ch <- 10
	ch <- 20
	fmt.Println("len:", len(ch), "cap:", cap(ch))

	ch <- 30 // buffer now full; a fourth send here would block forever

	fmt.Println(<-ch, <-ch, <-ch)
	fmt.Println("len:", len(ch))
}

Buffer memisahkan pengirim dan penerima sehingga lonjakan singkat tidak membuat pengirim macet. Buffer tidak memperbaiki producer yang selalu lebih cepat dari consumer-nya; buffer hanya menunda saat pengirim tertahan. Pilih ukuran buffer karena alasan yang jelas (jumlah pengirim, ukuran batch yang sudah diketahui), bukan untuk menghilangkan deadlock.

len(ch) hanyalah potret sesaat. Saat kamu bertindak berdasarkan nilainya, goroutine lain mungkin sudah mengubahnya, jadi jangan memakainya untuk menentukan apakah pengiriman akan tertahan. Untuk itu, pakai select dengan case default.

Close dan range

close(ch) memberi tahu penerima bahwa tidak akan ada nilai lagi yang dikirim. Setelah close:

• nilai yang sudah ada di buffer tetap dikirimkan,
• lalu setiap penerimaan langsung mengembalikan zero value,
• v, ok := <-ch melaporkan ok == false,
• for v := range ch berakhir.

package main

import "fmt"

func produce(n int) <-chan int {
	ch := make(chan int)
	go func() {
		defer close(ch) // the sender closes, when it is done
		for i := range n {
			ch <- i * i
		}
	}()
	return ch
}

func main() {
	for v := range produce(5) {
		fmt.Println(v)
	}

	ch := make(chan string, 1)
	ch <- "last"
	close(ch)
	v, ok := <-ch
	fmt.Printf("%q %v\n", v, ok)
	v, ok = <-ch
	fmt.Printf("%q %v\n", v, ok)
}

Penerimaan pertama setelah close masih mendapat "last" dengan ok == true. Penerimaan kedua mendapat zero value "" dan false.

Aturan yang menyebabkan panic:

• mengirim ke channel yang sudah ditutup akan panic dengan send on closed channel,
• menutup channel yang sudah ditutup akan panic,
• menutup channel nil akan panic.

Jadi hanya pihak pengirim yang menutup, dan hanya sekali. Dengan beberapa pengirim, tidak ada satu pengirim pun yang tahu kapan pengirim lain selesai; buat goroutine terpisah yang menunggu semua pengirim (dengan sync.WaitGroup) dan menutup channel setelah Wait selesai. Menutup channel hanya perlu kalau ada penerima yang menunggu akhirnya. Channel yang tidak ditutup dan tidak lagi dirujuk siapa pun dibersihkan oleh garbage collector seperti nilai lainnya.

Tipe arah

Sebuah fungsi bisa menyatakan bahwa ia hanya mengirim atau hanya menerima pada sebuah channel. Compiler lalu menolak operasi yang lain.

chan T otomatis dikonversi ke salah satu tipe terbatas itu saat kamu mengirimnya ke fungsi. Karena itulah produce di atas bisa mengembalikan <-chan int: pemanggilnya bisa melakukan range atasnya, tetapi tidak bisa mengirim ke dalamnya atau menutupnya. Pakai tipe arah di setiap parameter fungsi yang cocok. Tipe arah mendokumentasikan kepemilikan dan mengubah penyalahgunaan menjadi error kompilasi.

Deadlock

Jika setiap goroutine tertahan dan tidak ada yang bisa membangunkan satu pun di antaranya, runtime menghentikan program:

package main

import "fmt"

func main() {
	ch := make(chan int)
	ch <- 1 // no other goroutine exists to receive
	fmt.Println(<-ch)
}

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan send]:
main.main()
	/tmp/main.go:7 +0x38
exit status 2

Dump goroutine memberi tahu operasi mana yang macet (di sini chan send, atau chan receive, sync.WaitGroup.Wait, select). Penyebab yang biasa:

• pengiriman ke channel unbuffered tanpa ada penerima yang berjalan,
• range atas channel yang tidak pernah ditutup,
• counter WaitGroup yang tidak pernah mencapai nol,
• dua goroutine yang saling menunggu.

Runtime hanya mendeteksi kasus ketika semua goroutine macet. Di server yang masih punya goroutine lain yang hidup (listener HTTP, ticker), bug yang sama tidak membuat apa pun crash; goroutine yang tertahan hanya bocor.

Channel nil

Pengiriman dan penerimaan pada channel nil tertahan selamanya. Kedengarannya tidak berguna, tetapi ini trik standar di dalam select: mengisi variabel channel dengan nil menonaktifkan case-nya. Contoh ini menggabungkan dua channel dan berhenti mendengarkan masing-masing begitu channel itu ditutup:

package main

import "fmt"

func main() {
	a := make(chan int)
	b := make(chan int)
	go func() { defer close(a); a <- 1; a <- 2 }()
	go func() { defer close(b); b <- 10 }()

	sum := 0
	for a != nil || b != nil {
		select {
		case v, ok := <-a:
			if !ok {
				a = nil // a is finished: never select it again
				continue
			}
			sum += v
		case v, ok := <-b:
			if !ok {
				b = nil
				continue
			}
			sum += v
		}
	}
	fmt.Println("sum:", sum)
}

Tanpa assignment nil, channel yang sudah ditutup selalu siap, dan perulangan akan terus berputar pada zero value.

Pipeline

Channel bisa disusun menjadi pipeline: setiap tahap adalah goroutine yang menerima dari satu channel dan mengirim ke channel berikutnya, lalu menutup output-nya saat input-nya selesai.

package main

import "fmt"

func generate(nums ...int) <-chan int {
	out := make(chan int)
	go func() {
		defer close(out)
		for _, n := range nums {
			out <- n
		}
	}()
	return out
}

func square(in <-chan int) <-chan int {
	out := make(chan int)
	go func() {
		defer close(out)
		for n := range in {
			out <- n * n
		}
	}()
	return out
}

func main() {
	total := 0
	for v := range square(square(generate(1, 2, 3))) {
		fmt.Println(v)
		total += v
	}
	fmt.Println("total:", total)
}

Setiap tahap berjalan secara konkuren, dan urutan output-nya pasti (1, 16, 81) karena setiap tahap adalah satu goroutine yang menjaga urutan. Penutupan berantai: generate menutup channel, yang mengakhiri range di square, yang lalu menutup output-nya, dan seterusnya sampai ke main.

Titik lemah pipeline ini: kalau main berhenti membaca lebih awal, tahap-tahapnya akan tertahan selamanya saat mengirim. Pipeline sungguhan menerima context.Context atau channel done dan melakukan select atasnya di samping setiap pengiriman.

Channel atau mutex

Channel dipakai untuk menyerahkan kepemilikan data dan memberi sinyal tentang suatu kejadian. sync.Mutex lebih sederhana untuk melindungi state bersama yang dibaca dan diubah langsung oleh banyak goroutine, seperti cache atau counter. Struct yang berisi mutex sering kali lebih jelas daripada goroutine yang memiliki state dan melayani permintaan lewat channel. Pakai yang membuat kodenya lebih pendek dan kepemilikannya jelas.

Referensi singkat