🔍 Почему у горутин нет ID

Разработчики, пришедшие из Java или Python удивляются: горутина запущена, но получить её идентификатор нельзя. Нет метода, нет структуры, нет ничего, что можно было бы сохранить и использовать потом. В Go это сделано намеренно.

❓ Как это устроено

Горутина — анонимный воркер. Она не имеет имени, не возвращает дескриптор при запуске, не регистрируется нигде в рантайме с точки зрения программиста.

Это не техническое ограничение. Рантайм Go знает о каждой горутине всё что нужно — стек, статус, планировщик. Но эта информация намеренно скрыта от прикладного кода.

Причина в том, что именованные горутины провоцируют плохой дизайн. Когда у потока есть ID, программисты начинают привязывать к нему состояние — «этот поток обрабатывает этот запрос, значит туда и кладём контекст». Именно так работает thread-local storage, и именно это создаёт проблемы в конкурентных системах.

Пример из реальной жизни: если бы net/http хранил состояние запроса в горутине по ID, сервер не мог бы распараллелить обработку одного запроса между несколькими горутинами. Вся архитектура стала бы жёстче.

➡️ Подводные камни

Опыт с графическими системами, где весь рендеринг должен идти через «главный поток», хорошо показывает, к чему ведёт именование. Программисты вынуждены постоянно маршрутизировать работу в конкретный поток, обходить ограничения, добавлять костыли. В конкурентном языке это особенно болезненно.

Похожая история возникает с goroutine-local storage — его периодически пытаются реализовать через runtime.Stack и парсинг вывода. Это работает, но Go-команда считает такой подход антипаттерном: он хрупкий, медленный и ломается при изменении формата стека.

➡️ Пример кода

Правильный способ передать состояние между горутинами — канал или context.Context:

func worker(ctx context.Context, jobs <-chan int, results chan<- int) {
    for {
        select {
        case j, ok := <-jobs:
            if !ok {
                return
            }
            results <- process(ctx, j)
        case <-ctx.Done():
            return
        }
    }
}

Горутина не знает своего ID. Но она знает, что делать, через аргументы и каналы. Этого достаточно.

Отсутствие goroutine ID — осознанное решение, которое держит архитектуру чистой. Вместо того чтобы привязывать состояние к конкретной горутине, Go предлагает передавать его явно — через каналы и контекст. Это делает код проще для тестирования и масштабирования.

У нашей рассылки есть ID. Вот он — https://clc.to/mKZg2A

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoDeep