🔍 Почему у горутин нет ID — 12 июля 2026 г. в 10:15:01.577
🔍 Почему у горутин нет 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