Коротко: в приведённом фрагменте deadlock не происходит — есть отправитель в отдельной горутине и приёмник в main, они синхронизируются через неблокирующий (точнее, синхронный) обмен по небуферизованному каналу. Но похожие конструкции легко приводят к взаимной блокировке. Причины и способы устранения:
Причина deadlock
- Небуферизованный канал требует одновременного присутствия отправителя и приёмника. Если все горутины блокируются на операциях send/receive и ни одна не может продолжить, рантайм выдаст panic: "all goroutines are asleep - deadlock".
Типичные сценарии, приводящие к deadlock
- Отсутствует соответствующая горутина-получатель или отправитель (например, сделали `ch <- 1` в main без другой горутины).
- Неправильный порядок операций/ожидание, когда и отправитель, и получатель блокируются в цепочке зависимостей.
Способы устранения
- Использовать буферизованный канал, чтобы один из участников не блокировался сразу: `ch := make(chan int, $1$)`.
- Координировать завершение/синхронизацию явно: `sync.WaitGroup` или другие механизмы синхронизации.
- Использовать `select` с `default` или таймаутом (`time.After`) для избежания бесконечной блокировки.
- Закрывать канал, если это логично, и проверять второе значение при приёме (`v, ok := <-ch`) чтобы корректно завершать при отсутствии данных.
- Пересмотреть архитектуру: избегать циклических зависимостей между горутинами.
Примеры исправлений (фрагменты):
- Буфер: `ch := make(chan int, $1$)`
- Select с таймаутом:
go func() {
select {
case ch <- 1:
case <-time.After(time.Second):
// обработать таймаут
}
}()
Вывод: сам код работает, но чтобы избежать deadlock в более сложных сценариях — добавить буфер, явную синхронизацию или таймауты/`select`.