Channels em Golang: com buffer, sem buffer, close e range

Enviando e recebendo

Um channel é um cano tipado entre goroutines. ch <- v envia, <-ch recebe. Crie um com 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)
}

O valor zero de um tipo channel é nil, então var ch chan string sem make dá um channel que bloqueia para sempre. Sempre crie channels com make.

Channels sem buffer sincronizam

make(chan T) cria um channel sem buffer. Um envio bloqueia até um receptor pegar o valor, e um recebimento bloqueia até um remetente fornecer um. As duas goroutines se encontram nesse ponto, o que faz de um channel sem buffer uma ferramenta de sincronização tanto quanto um cano de dados. Quando <-done retorna abaixo, você sabe que o worker terminou tudo o que vinha antes do envio:

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

Ler result no main é seguro aqui sem mutex. O modelo de memória do Go garante que tudo o que o worker fez antes do envio fica visível para o main depois do recebimento correspondente. chan struct{} é o tipo idiomático para um sinal puro, porque struct{} não ocupa memória.

Channels com buffer

make(chan T, n) dá ao channel espaço para n valores. Os envios dão certo sem receptor até o buffer encher; os recebimentos dão certo até ele esvaziar. Os valores saem na ordem em que entraram.

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

Um buffer desacopla remetente e receptor para que rajadas curtas não travem o remetente. Ele não resolve um produtor que é permanentemente mais rápido que o seu consumidor; só adia o momento em que o remetente bloqueia. Escolha o tamanho do buffer por um motivo (o número de remetentes, um tamanho de lote conhecido), não para fazer um deadlock sumir.

len(ch) é um retrato do momento. Quando você age com base nele, outra goroutine pode já tê-lo mudado, então não o use para decidir se um envio vai bloquear. Use select com um case default para isso.

close e range

close(ch) avisa os receptores de que nenhum valor novo será enviado. Depois de um close:

• os valores que já estão no buffer ainda são entregues,
• depois disso todo recebimento devolve o valor zero na hora,
• 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)
}

O primeiro recebimento depois do close ainda pega "last" com ok == true. O segundo pega o valor zero "" e false.

Regras que causam panic:

• enviar em um channel fechado causa panic com send on closed channel,
• fechar um channel já fechado causa panic,
• fechar um channel nil causa panic.

Então só o lado que envia fecha, e só uma vez. Com vários remetentes, nenhum deles sabe quando os outros terminaram; faça uma goroutine separada esperar todos os remetentes (com um sync.WaitGroup) e fechar o channel depois que o Wait retornar. Fechar só é necessário quando um receptor espera pelo fim. Um channel não fechado que ninguém referencia é recolhido pelo coletor de lixo como qualquer outro valor.

Tipos com direção

Uma função pode declarar que só envia ou só recebe em um channel. O compilador então rejeita a outra operação.

Um chan T é convertido implicitamente para qualquer um dos tipos restritos quando você o passa para uma função. É por isso que produce, acima, pode devolver um <-chan int: quem chama pode percorrê-lo com range, mas não pode enviar nele nem fechá-lo. Use tipos com direção em todo parâmetro de função em que se aplicam. Eles documentam quem é dono do channel e transformam o uso errado em erro de compilação.

Deadlock

Se todas as goroutines estão bloqueadas e nada pode acordar nenhuma delas, o runtime aborta o 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

O dump de goroutines diz qual operação está travada (chan send aqui, ou chan receive, sync.WaitGroup.Wait, select). As causas de sempre:

• um envio em um channel sem buffer sem nenhum receptor rodando,
• range sobre um channel que nunca é fechado,
• um contador de WaitGroup que nunca chega a zero,
• duas goroutines esperando uma pela outra.

O runtime só detecta o caso em que todas as goroutines estão travadas. Em um servidor com outras goroutines vivas (um listener HTTP, um ticker), o mesmo bug não derruba nada; a goroutine bloqueada apenas vaza.

Channels nil

Envios e recebimentos em um channel nil bloqueiam para sempre. Parece inútil, mas é um truque padrão dentro de um select: definir uma variável de channel como nil desativa o case dela. Isto mescla dois channels e para de escutar cada um assim que ele é fechado:

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

Sem as atribuições de nil, um channel fechado está sempre pronto, e o laço ficaria girando sobre valores zero.

Um pipeline

Channels se combinam em pipelines: cada estágio é uma goroutine que recebe de um channel e envia para o próximo, e fecha a sua saída quando a entrada acaba.

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 estágio executa de forma concorrente, e a ordem da saída é determinística (1, 16, 81) porque cada estágio é uma única goroutine que preserva a ordem. Os fechamentos se propagam em cascata: generate fecha, o que encerra o range de square, que fecha a sua saída, e assim por diante até o main.

O ponto fraco deste pipeline: se o main parasse de ler antes do fim, os estágios ficariam bloqueados nos seus envios para sempre. Pipelines reais recebem um context.Context ou um channel done e fazem select nele ao lado de cada envio.

Channel ou mutex

Channels servem para passar a posse de dados e para sinalizar eventos. Um sync.Mutex é mais simples para proteger estado compartilhado que muitas goroutines leem e atualizam no lugar, como um cache ou um contador. Uma struct com um mutex dentro muitas vezes é mais clara que uma goroutine dona do estado atendendo requisições por channels. Use o que deixar o código mais curto e a posse dos dados óbvia.

Referência rápida