Каналы в Golang: буферизованные, небуферизованные, close и range

Отправка и получение

Канал это типизированная труба между горутинами. ch <- v отправляет, <-ch получает. Создаётся канал через 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)
}

Нулевое значение канального типа это nil, поэтому var ch chan string без make даёт канал, который блокируется навсегда. Всегда создавайте каналы через make.

Небуферизованные каналы синхронизируют

make(chan T) создаёт небуферизованный канал. Отправка блокируется, пока получатель не заберёт значение, а получение блокируется, пока отправитель его не даст. Две горутины встречаются в этой точке, поэтому небуферизованный канал в той же мере инструмент синхронизации, что и труба для данных. Когда ниже возвращается <-done, вы знаете, что воркер закончил всё, что было до его отправки:

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

Читать result в main здесь безопасно и без мьютекса. Модель памяти Go гарантирует, что всё, что воркер сделал до отправки, видно main после соответствующего получения. chan struct{} это идиоматичный тип для чистого сигнала, потому что struct{} не занимает памяти.

Буферизованные каналы

make(chan T, n) даёт каналу место под n значений. Отправки проходят без получателя, пока буфер не заполнится; получения проходят, пока он не опустеет. Значения выходят в том же порядке, в каком вошли.

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

Буфер развязывает отправителя и получателя, чтобы короткие всплески не останавливали отправителя. Он не спасает, если производитель постоянно быстрее потребителя; он только откладывает момент, когда отправитель заблокируется. Выбирайте размер буфера по причине (число отправителей, известный размер пачки), а не чтобы убрать deadlock.

len(ch) это снимок состояния. К тому моменту, когда вы на него отреагируете, другая горутина может его изменить, поэтому не используйте его, чтобы решить, заблокируется ли отправка. Для этого есть select с веткой default.

close и range

close(ch) сообщает получателям, что значений больше отправлено не будет. После закрытия:

• значения, уже лежащие в буфере, всё равно доставляются,
• затем каждое получение сразу возвращает нулевое значение,
• v, ok := <-ch сообщает ok == false,
• for v := range ch завершается.

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

Первое получение после close всё ещё даёт "last" с ok == true. Второе даёт нулевое значение "" и false.

Правила, нарушение которых вызывает панику:

• отправка в закрытый канал паникует с send on closed channel,
• закрытие уже закрытого канала паникует,
• закрытие nil-канала паникует.

Поэтому закрывает только отправляющая сторона, и только один раз. Когда отправителей несколько, ни один из них не знает, закончили ли остальные; пусть отдельная горутина дождётся всех отправителей (через sync.WaitGroup) и закроет канал после возврата Wait. Закрывать нужно, только когда получатель ждёт конца. Незакрытый канал, на который никто не ссылается, собирается сборщиком мусора, как любое другое значение.

Типы с направлением

Функция может объявить, что она только отправляет или только получает из канала. Тогда компилятор отвергнет другую операцию.

chan T неявно преобразуется в любой из ограниченных типов при передаче в функцию. Поэтому produce выше может вернуть <-chan int: вызывающий код может обходить его через range, но не может ни отправить в него, ни закрыть его. Используйте типы с направлением во всех параметрах функций, где это применимо. Они документируют владение и превращают неправильное использование в ошибку компиляции.

Deadlock

Если каждая горутина заблокирована и ничто не может разбудить ни одну из них, среда выполнения прерывает программу:

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

Дамп горутин говорит, какая операция застряла (здесь chan send, а бывает chan receive, sync.WaitGroup.Wait, select). Обычные причины:

• отправка в небуферизованный канал, когда не запущен ни один получатель,
• range по каналу, который никогда не закрывается,
• счётчик WaitGroup, который никогда не доходит до нуля,
• две горутины, каждая из которых ждёт другую.

Среда выполнения распознаёт только случай, когда застряли все горутины. В сервере, где живы другие горутины (HTTP-слушатель, тикер), та же ошибка ничего не роняет; заблокированная горутина просто утекает.

nil-каналы

Отправка и получение на nil-канале блокируются навсегда. Звучит бесполезно, но это стандартный приём внутри select: присвоив переменной канала nil, вы отключаете его ветку. Этот код объединяет два канала и перестаёт слушать каждый из них, как только тот закрыт:

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

Без присваиваний nil закрытый канал всегда готов, и цикл крутился бы на нулевых значениях.

Конвейер

Каналы складываются в конвейеры: каждая стадия это горутина, которая получает из одного канала, отправляет в следующий и закрывает свой выход, когда её вход закончился.

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

Все стадии работают конкурентно, а порядок вывода детерминирован (1, 16, 81), потому что каждая стадия это одна горутина, сохраняющая порядок. Закрытия идут каскадом: generate закрывается, это завершает range в square, та закрывает свой выход, и так далее до main.

Слабое место этого конвейера: если main перестанет читать раньше времени, стадии навсегда заблокируются на отправке. Настоящие конвейеры принимают context.Context или канал done и делают select по нему рядом с каждой отправкой.

Канал или мьютекс

Каналы нужны для передачи владения данными и для сигнализации о событиях. sync.Mutex проще для защиты общего состояния, которое многие горутины читают и обновляют на месте, например кеша или счётчика. Структура с мьютексом внутри часто понятнее, чем горутина, которая владеет состоянием и обслуживает запросы через каналы. Используйте то, что делает код короче, а владение очевидным.

Шпаргалка