С какими неочевидными проблемами параллельности (горутин) ты сталкивался на реальных проектах и как их лечил?

В реальных проектах на Go сталкивался с несколькими неочевидными проблемами параллельности:

• Гонка данных (data race) — когда несколько горутин одновременно читают и пишут в общие переменные без синхронизации. Решал с помощью sync.Mutex, sync.RWMutex или каналов для передачи данных.
• Взаимная блокировка (deadlock) — например, когда две горутины ждут друг друга, удерживая мьютексы. Для решения анализировал порядок захвата блокировок, старался минимизировать время удержания мьютексов и использовать таймауты.
• Потеря сигналов в каналах — если горутина не успевает прочитать из канала, а другая пишет, можно получить блокировку или потерю данных. Использовал буферизированные каналы или контролировал порядок запуска горутин.
• Утечки горутин — когда горутины остаются заблокированными и не завершаются, например, из-за ожидания на канале, который никто не закроет. Для отладки применял профилирование и контексты (context.Context) для отмены операций.
• Непредсказуемый порядок выполнения — иногда сложно отследить последовательность событий. Использовал логирование с таймстампами и инструменты трассировки.

Пример использования мьютекса для защиты общего ресурса:

var mu sync.Mutex
var counter int

func increment() {
    mu.Lock()
    defer mu.Unlock()
    counter++
}

Главное — тщательно продумывать архитектуру параллельных компонентов и использовать встроенные механизмы синхронизации Go.