Channels en Golang: con y sin buffer, close y range

Enviar y recibir

Un channel es una tubería tipada entre goroutines. ch <- v envía, <-ch recibe. Se crea con 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)
}

El valor cero de un tipo channel es nil, así que var ch chan string sin make te da un channel que se bloquea para siempre. Crea siempre los channels con make.

Los channels sin buffer sincronizan

make(chan T) crea un channel sin buffer. Un envío se bloquea hasta que un receptor toma el valor, y una recepción se bloquea hasta que un emisor lo proporciona. Las dos goroutines se encuentran en ese punto, lo que convierte a un channel sin buffer en una herramienta de sincronización tanto como en una tubería de datos. Cuando <-done retorna en el siguiente ejemplo, sabes que el worker terminó todo lo que hizo antes de su envío:

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

Leer result en main es seguro aquí sin un mutex. El modelo de memoria de Go garantiza que todo lo que hizo el worker antes del envío es visible para main después de la recepción correspondiente. chan struct{} es el tipo idiomático para una señal pura, porque struct{} no ocupa memoria.

Channels con buffer

make(chan T, n) da al channel espacio para n valores. Los envíos tienen éxito sin receptor hasta que el buffer se llena; las recepciones, hasta que se vacía. Los valores salen en el mismo orden en que entraron.

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

Un buffer desacopla emisor y receptor para que las ráfagas cortas no frenen al emisor. No arregla un productor que es siempre más rápido que su consumidor; solo retrasa el momento en que el emisor se bloquea. Elige el tamaño del buffer por una razón (el número de emisores, un tamaño de lote conocido), no para que desaparezca un deadlock.

len(ch) es una instantánea. Para cuando actúas sobre ella otra goroutine puede haberla cambiado, así que no la uses para decidir si un envío se va a bloquear. Para eso usa select con un caso default.

Close y range

close(ch) indica a los receptores que no se enviarán más valores. Después de un close:

• los valores que ya están en el buffer se siguen entregando,
• después, cada recepción devuelve el valor cero de inmediato,
• v, ok := <-ch informa ok == false,
• for v := range ch termina.

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

La primera recepción después de close todavía obtiene "last" con ok == true. La segunda obtiene el valor cero "" y false.

Reglas que provocan panics:

• enviar a un channel cerrado provoca un panic con send on closed channel,
• cerrar un channel ya cerrado provoca un panic,
• cerrar un channel nil provoca un panic.

Así que solo cierra el lado emisor, y una sola vez. Con varios emisores, ninguno sabe cuándo han terminado los demás; haz que una goroutine aparte espere a todos los emisores (con un sync.WaitGroup) y cierre el channel cuando Wait retorne. Cerrar solo hace falta cuando un receptor espera el final. Un channel sin cerrar al que nadie hace referencia se recolecta como cualquier otro valor.

Tipos direccionales

Una función puede declarar que solo envía o solo recibe en un channel. El compilador rechaza entonces la otra operación.

Un chan T se convierte implícitamente a cualquiera de los tipos restringidos al pasarlo a una función. Por eso produce puede devolver un <-chan int: quien lo llama puede recorrerlo con range pero no enviar ni cerrarlo. Usa tipos direccionales en cada parámetro de función donde apliquen. Documentan quién es el dueño y convierten el mal uso en un error de compilación.

Deadlock

Si todas las goroutines están bloqueadas y nada puede despertar a ninguna, el runtime aborta el programa:

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

El volcado de goroutines te dice qué operación está atascada (aquí chan send, o también chan receive, sync.WaitGroup.Wait, select). Las causas habituales:

• un envío a un channel sin buffer sin ningún receptor en marcha,
• range sobre un channel que nunca se cierra,
• un contador de WaitGroup que nunca llega a cero,
• dos goroutines esperando cada una a la otra.

El runtime solo detecta el caso en que todas las goroutines están atascadas. En un servidor con otras goroutines vivas (un listener HTTP, un ticker), el mismo bug no hace caer nada; la goroutine bloqueada simplemente se fuga.

Channels nil

Los envíos y recepciones en un channel nil se bloquean para siempre. Parece inútil, pero es un truco estándar dentro de select: asignar nil a una variable de channel desactiva su caso. Este código combina dos channels y deja de escuchar cada uno cuando se cierra:

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

Sin las asignaciones a nil, un channel cerrado siempre está listo, y el bucle daría vueltas sobre valores cero.

Un pipeline

Los channels se componen en pipelines: cada etapa es una goroutine que recibe de un channel, envía al siguiente y cierra su salida cuando termina su entrada.

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

Cada etapa se ejecuta de forma concurrente, y el orden de salida es determinista (1, 16, 81) porque cada etapa es una sola goroutine que conserva el orden. Los cierres se encadenan: generate cierra, lo que termina el range de square, que cierra su salida, y así hasta main.

El punto débil de este pipeline: si main dejara de leer antes de tiempo, las etapas se bloquearían en sus envíos para siempre. Los pipelines reales reciben un context.Context o un channel done y hacen select sobre él junto a cada envío.

Channel o mutex

Los channels sirven para pasar la propiedad de los datos y para señalar eventos. Un sync.Mutex es más sencillo para proteger estado compartido que muchas goroutines leen y actualizan en el sitio, como una caché o un contador. Un struct con un mutex dentro suele ser más claro que una goroutine que posee el estado y atiende peticiones por channels. Usa lo que haga el código más corto y la propiedad más evidente.

Referencia rápida