> Приходилось ли работать с асинхронностью (Go)

Короткий ответ

Да, с асинхронностью работал плотно, в основном в Go. Это горутины, каналы, контексты, паттерны worker pool, fan-in/fan-out, graceful shutdown. Также приходилось работать с асинхронностью в других языках - Node.js (event loop, промисы), Python (asyncio), но именно в Go она является базовой моделью конкурентности, и там я чувствую себя наиболее уверенно.

Подробное объяснение

В Go асинхронность реализована через горутины - легковесные потоки, которыми управляет runtime. Ключевое отличие от потоков ОС - горутины имеют динамический стек, стартуют с нескольких килобайт, и их можно создавать десятками тысяч без проблем с памятью.

Основные инструменты:

• Горутины - запуск функции в отдельной единице выполнения через go func()
• Каналы - типизированные "трубы" для передачи данных между горутинами, поддерживают буферизацию и направленность
• Select - мультиплексирование операций с каналами, позволяет ждать несколько событий одновременно
• Context - механизм отмены и передачи deadline/timeout через всю цепочку вызовов
• Sync-пакет - мьютексы, WaitGroup, Once, Cond для низкоуровневой синхронизации

Важный момент - в Go нет async/await как в других языках. Модель конкурентности основана на CSP (Communicating Sequential Processes): горутины общаются через каналы, а не через разделяемую память. Это снижает риск гонок данных, но не устраняет его полностью - при работе с общими структурами всё равно нужны мьютексы или атомики.

На практике

Из реальных задач, где асинхронность критична:

• Обработка HTTP-запросов - каждый запрос обрабатывается в отдельной горутине, важно не блокировать их на I/O
• Worker pool - пул воркеров, которые читают задачи из канала и пишут результаты в другой канал
• Fan-out/fan-in - раздача задач на много горутин и сбор результатов
• Graceful shutdown - ожидание завершения всех горутин через context cancellation и WaitGroup
• Rate limiting - ограничение частоты запросов через тикеры или каналы с буфером

Типичные проблемы, с которыми сталкивался:

• Утечка горутин - горутина зависает на чтении из канала, который никто не закрывает. Решается через context или таймауты
• Гонки данных - когда несколько горутин пишут в общую map или слайс. Лечится мьютексами или пересмотром дизайна
• Deadlock - взаимная блокировка при неправильной работе с каналами
• Паника в горутине - паника в горутине роняет весь процесс, нужен recover

Пример кода

GO
// Worker pool с context и graceful shutdown
func WorkerPool(ctx context.Context, tasks <-chan Task, workers int) <-chan Result {
    results := make(chan Result)
    var wg sync.WaitGroup

    for i := 0; i < workers; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            for {
                select {
                case <-ctx.Done():
                    return
                case task, ok := <-tasks:
                    if !ok {
                        return
                    }
                    // обработка задачи
                    results <- process(task)
                }
            }
        }(i)
    }

    go func() {
        wg.Wait()
        close(results)
    }()

    return results
}

Как отвечать на собеседовании

Начни с конкретного примера из практики - это сразу показывает реальный опыт. Расскажи о проблеме, которую решал, и почему выбрал именно такой подход. Например: "Был сервис, который обрабатывал пачку внешних запросов, и нужно было ограничить параллелизм и уметь отменять всё при таймауте - сделал worker pool с context".

Покажи понимание trade-off между горутинами и каналами vs мьютексы. Упомяни, что каналы - это не серебряная пуля, иногда проще и надёжнее использовать мьютекс для защиты общего состояния.

Если спросят про отличия от других языков - подчеркни, что в Go нет async/await, и это осознанный дизайн: горутины дешевле, а каналы делают конкурентность более структурированной.

Что проверяет интервьюер

• Понимание базовой модели конкурентности в Go - горутины, каналы, select
• Умение проектировать конкурентные системы - worker pool, fan-in/fan-out, graceful shutdown
• Знание подводных камней - утечки горутин, гонки данных, deadlock
• Практический опыт - не просто теория, а реальные кейсы с проблемами и решениями
• Умение объяснять trade-off - когда использовать каналы, а когда мьютексы

Типичные ошибки

• Говорить только теорию - "горутины это легковесные потоки" без примеров из практики
• Не упоминать context - это ключевой механизм для отмены и таймаутов, его отсутствие в ответе сразу заметно
• Путать конкурентность и параллелизм - это разные вещи, и интервьюер может это проверить
• Забывать про гонки данных - если кандидат говорит, что каналы решают все проблемы, это красный флаг
• Не знать, как обнаруживать проблемы - не упоминать go test -race, pprof, трассировку
• Предлагать горутины для всего - иногда проще и надёжнее последовательный код или мьютекс