Горутини¶

Горутина (goroutine) — це функція, що виконується паралельно з усім іншим у програмі. Запускають її, поставивши go перед викликом. Це весь синтаксис — функція виконується незалежно, а викликач продовжує роботу, не чекаючи.

go doWork()        // запускає doWork паралельно; одразу повертає керування

Горутини — це не потоки ОС. Середовище виконання Go мультиплексує багато горутин на невеликий пул потоків (планувальник M:N), тож вони надзвичайно дешеві — кілька кілобайтів стеку кожна, і їх можуть бути сотні тисяч. Створення горутини коштовно ближче до виклику функції, ніж до породження потоку.

З погляду Python: горутина схожа на задачу, заплановану в циклі подій, але без «забарвлення» async/await — будь-яка функція може виконуватися в горутині — і середовище використовує справжні потоки ОС під капотом, тож горутини виконуються паралельно на кількох ядрах, а не лише конкурентно.

Головна горутина завершується — і забирає все з собою¶

Сам main виконується в горутині. Коли main повертає керування, програма завершується негайно, не чекаючи на інші горутини. Тому це часто не друкує нічого:

func main() {
    go fmt.Println("hello from a goroutine")
    // main повертає тут; програма може завершитися до запуску горутини
}

Горутина може не встигнути виконатися. Потрібна синхронізація — щоб main дочекався завершення роботи. Сон — це не синхронізація (це здогад); правильний інструмент — sync.WaitGroup.

Очікування через `sync.WaitGroup`¶

WaitGroup рахує незавершені горутини. Add(n) піднімає лічильник, кожна горутина викликає Done() після завершення (через defer), а Wait() блокує, доки лічильник не сягне нуля.

// checkHealth пінгує один сервіс. Sleep імітує реальну мережеву затримку.
func checkHealth(name string) string {
    time.Sleep(100 * time.Millisecond)
    return name + ": ok"
}

func main() {
    services := []string{"api", "db", "cache"}
    statuses := make([]string, len(services))

    var wg sync.WaitGroup
    for i, name := range services {
        wg.Add(1)
        go func() {
            defer wg.Done()
            statuses[i] = checkHealth(name)   // кожна горутина пише у свій слот
        }()
    }
    wg.Wait()                                 // блокувати, доки всі три перевірки не завершаться

    for _, s := range statuses {
        fmt.Println(s)
    }
}
// output:
// api: ok
// db: ok
// cache: ok

Ось навіщо потрібні горутини: перекривати незалежну повільну роботу. Кожен checkHealth триває 100 мс. Один за одним — це ~300 мс; запущені як горутини, вони всі чекають одночасно, тож увесь пакет завершується за ~100 мс. Замініть sleep на справжній HTTP-запит чи запит до БД — і це справжній конкурентний перевіряч стану.

Дві речі тримають це коректним:

Wait() гарантує, що кожна перевірка завершилася, перш ніж ми читаємо statuses.
Кожна горутина пише в різний слот зрізу, тож немає конкурентного запису в ту саму пам'ять (немає гонитви — перевірте go run -race).

Змінна циклу — на кожну ітерацію своя¶

Цикл вище захопив і i, і name у кожну горутину, і кожна ітерація має власну копію — тож горутина для "db" справді бачить name == "db", а не те значення, на якому цикл завершився. Це сучасна поведінка Go: кожна ітерація циклу for має свіжу змінну циклу.

У старішому Go це було сумнозвісним багом — єдина спільна змінна на момент запуску горутин зазвичай мала останнє значення циклу, тож кожна горутина використала б "cache". Це обходили, передаючи значення як аргумент:

for i, name := range services {
    wg.Add(1)
    go func(i int, name string) {   // старий обхід: передати копії як аргументи
        defer wg.Done()
        statuses[i] = checkHealth(name)
    }(i, name)
}

Це все ще працює, і ви побачите його в старому коді, але потреби в ньому більше немає.