> За счет чего достигается параллелизм и кооперативность в Go (Go)

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

Параллелизм в Go достигается через горутины - легковесные потоки, которые планируются рантаймом поверх системных потоков ОС. Кооперативность обеспечивается точками переключения: явными (каналы, мьютексы, time.Sleep) и неявными (вызовы функций, аллокации, syscall). Рантайм использует модель M:N, где планировщик распределяет горутины по доступным потокам, а при блокировке одной горутины переключается на другую без участия ОС.

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

Go использует модель параллелизма, основанную на горутинах и планировщике рантайма. Ключевые механизмы:

• Горутины - это стек-ориентированные корутины с динамическим стеком (начинается с 2 КБ, растёт по мере необходимости). Они не являются потоками ОС и создаются практически бесплатно - десятки тысяч горутин на процесс - это норма.

• Планировщик рантайма реализует модель M:N: M - это системные потоки, N - горутины. Планировщик распределяет горутины по потокам, используя локальные очереди (per-P run queues) и глобальную очередь. Каждый процессор (P) имеет свою локальную очередь, что минимизирует contention.

• Кооперативность означает, что горутина не может быть вытеснена в произвольный момент. Переключение происходит только в точках, где горутина явно или неявно уступает управление:

  • явные: операции с каналами, sync.Mutex, runtime.Gosched(), time.Sleep
  • неявные: вызов любой функции (проверка асинхронного preemption), аллокация памяти, syscall

• Асинхронное вытеснение (с Go 1.14) - рантайм периодически проверяет флаг preemption при входе в функцию, что позволяет переключать даже бесконечные циклы без явных точек уступки. Это сделано через сигнал SIGURG, который доставляется потоку.

• Сетевой poller - отдельный механизм: когда горутина блокируется на сетевом I/O, она не занимает поток. Рантайм регистрирует файловый дескриптор в epoll/kqueue, а горутина переходит в состояние ожидания. Когда событие готово, горутина возобновляется на любом свободном потоке.

• Syscall handling - при блокирующем системном вызове поток, на котором выполняется горутина, может быть отдан ОС, а планировщик подхватывает другой поток для остальных горутин. Это позволяет не терять параллелизм при блокирующих операциях.

На практике

Для senior-позиции важно понимать, как эти механизмы влияют на проектирование:

• Каналы - основной инструмент синхронизации и передачи данных. Они не только передают значения, но и являются точками кооперативного переключения. Буферизованные каналы позволяют избежать блокировки отправителя, но не гарантируют отсутствие гонок.

• sync.Mutex - блокирует горутину, но не поток. Это значит, что при конкурентном доступе к мьютексу горутины встают в очередь, а потоки продолжают выполнять другие горутины.

• runtime.Gosched() - явная уступка процессора. Используется редко, но полезна в CPU-bound циклах без вызовов функций.

• sync.WaitGroup - для ожидания завершения группы горутин. Важно не забывать вызывать Done() через defer.

• Контекст и отмена - context.Context с cancel позволяет кооперативно завершать горутины через канал Done(). Это стандартный паттерн для graceful shutdown.

• Ограничение параллелизма - через буферизованный канал (worker pool) или semaphore.Weighted. Это критично для защиты внешних ресурсов (БД, API).

• Горутины и память - стек горутины растёт динамически, но при этом может вызывать копирование стека. Для long-running горутин с большим стеком это может быть дорого.

Пример кода

GO
package main

import (
    "context"
    "fmt"
    "sync"
    "time"
)

// worker pool с ограничением параллелизма через буферизованный канал
func processJobs(ctx context.Context, jobs []int, workers int) {
    sem := make(chan struct{}, workers)
    var wg sync.WaitGroup

    for _, job := range jobs {
        wg.Add(1)
        go func(job int) {
            defer wg.Done()
            select {
            case sem <- struct{}{}:
                defer func() { <-sem }()
                // здесь происходит кооперативное переключение
                // при блокировке на канале или I/O
                fmt.Printf("processing %d\n", job)
                time.Sleep(100 * time.Millisecond) // точка переключения
            case <-ctx.Done():
                return
            }
        }(job)
    }

    wg.Wait()
}

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel()

    jobs := make([]int, 10)
    for i := range jobs {
        jobs[i] = i
    }

    processJobs(ctx, jobs, 3) // максимум 3 горутины одновременно
}

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

Начните с модели M:N и горутин как легковесных сущностей. Затем перейдите к кооперативности: объясните, что переключение происходит только в определённых точках, и упомяните асинхронное вытеснение как современное дополнение. Обязательно свяжите это с практикой: почему каналы и мьютексы не блокируют потоки, как сетевой poller позволяет обрабатывать тысячи соединений. Если спросят про отличия от потоков ОС - подчеркните стоимость создания, размер стека и планирование.

Хороший ответ показывает понимание trade-off: кооперативность даёт предсказуемость и низкие накладные расходы, но требует аккуратности с CPU-bound задачами и блокирующими операциями.

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

• Понимание разницы между параллелизмом (concurrency) и параллельным исполнением (parallelism)
• Знание внутреннего устройства планировщика: P, M, G, локальные очереди
• Понимание кооперативного переключения и его ограничений
• Умение объяснить, почему горутины дешевле потоков
• Знание механизмов синхронизации и их влияния на планирование
• Понимание сетевого poller и обработки syscall
• Способность проектировать конкурентные системы с учётом ограничений планировщика

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

• Утверждение, что горутины - это потоки ОС или что они выполняются параллельно всегда (на одном ядре параллелизма нет)
• Игнорирование асинхронного вытеснения: "горутина в бесконечном цикле заблокирует всё" - это не так с Go 1.14
• Путаница между кооперативностью и вытесняющей многозадачностью
• Утверждение, что каналы всегда лучше мьютексов - это не так, для простых счётчиков мьютекс быстрее
• Забывание про GOMAXPROCS и его влияние на параллелизм
• Непонимание, что блокирующий syscall в горутине не блокирует другие горутины (благодаря механизму hand-off)
• Использование time.Sleep для синхронизации вместо каналов или WaitGroup