> Можно ли примерно оценить, когда запустится горутина после ее запуска? (Go)

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

Точную оценку дать невозможно: планировщик Go (runtime scheduler) не гарантирует детерминированного времени запуска горутины после вызова go func(). Горутина попадает в локальную или глобальную очередь раннера, и время старта зависит от текущей нагрузки, количества P (processor), блокировок, syscalls и работы GC. Можно говорить лишь о вероятностной оценке в пределах микросекунд на ненагруженной машине, но это не контракт, а эмпирика.

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

Планировщик Go - это M:N планировщик: M потоков ОС выполняют горутины, распределённые по P (логическим процессорам). При вызове go f() горутина не стартует немедленно, а помещается в run queue конкретного P (или в глобальную очередь, если локальная переполнена). Запуск происходит, когда:

• текущая горутина на P блокируется (channel, mutex, syscall, sleep);
• текущая горутина добровольно уступает (например, runtime.Gosched());
• срабатывает таймер вытеснения (preemption) - примерно каждые 10 мс;
• P становится свободным и забирает работу из глобальной очереди.

Ни один из этих моментов не предсказуем из пользовательского кода. Более того, планировщик может отложить запуск из-за:

• работы сборщика мусора (GC stop-the-world фазы);
• нехватки P (например, GOMAXPROCS ограничен);
• приоритетов: горутины, уже находящиеся в очереди, будут запущены раньше.

Единственное, что можно оценить - это порядок запуска при отсутствии конкуренции: на одном P с пустой очередью новая горутина стартует после того, как текущая горутина уступит или будет вытеснена. Но даже это не даёт временной оценки.

На практике

На практике для оценки времени запуска используют:

• бенчмарки с testing.B и b.ResetTimer() - измеряют среднее время от go до первого выполнения;
• профилирование с trace (runtime/trace) - показывает точные моменты постановки в очередь и старта;
• эмпирические замеры на целевой нагрузке.

Но в продакшене не стоит полагаться на такие числа. Если требуется гарантированная реакция (например, таймаут или heartbeat), используйте context.WithTimeout, time.AfterFunc или явные механизмы синхронизации. Для "примерной" оценки на ненагруженной машине можно ориентироваться на единицы микросекунд, но при нагрузке это значение может вырасти на порядки.

Пример кода

GO
package main

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

func main() {
	var wg sync.WaitGroup
	start := time.Now()

	wg.Add(1)
	go func() {
		defer wg.Done()
		fmt.Println("goroutine started after:", time.Since(start))
	}()

	// main goroutine продолжает работать, планировщик может запустить новую горутину
	// только когда main уступит или будет вытеснен
	time.Sleep(10 * time.Millisecond) // имитация работы
	wg.Wait()
}

Вывод недетерминирован: время может быть от ~0 до 10 мс и более, в зависимости от планировщика и версии Go.

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

Начните с прямого ответа: "точную оценку дать нельзя". Затем объясните модель планировщика: M, P, G, очереди, условия запуска. Упомяните, что время зависит от нагрузки, GOMAXPROCS, GC и вытеснения. Если спросят про "примерно" - скажите, что на пустой машине это микросекунды, но это не гарантия. Подчеркните, что для реальных требований нужны механизмы синхронизации, а не оценка планировщика. Хорошо добавить пример с time.Sleep в main, чтобы показать, что запуск отложен до уступа.

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

• Понимание модели планировщика Go (G, M, P, run queue).
• Осознание недетерминированности конкурентного выполнения.
• Умение отличать гарантии языка от эмпирических наблюдений.
• Практические навыки: знание trace, бенчмарков, context.
• Способность объяснить trade-off между простотой модели и предсказуемостью.

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

• Утверждение, что горутина запускается "сразу" или "через фиксированное время".
• Путаница между запуском горутины и началом выполнения её кода.
• Игнорирование влияния GOMAXPROCS и GC.
• Предложение использовать runtime.Gosched() как способ гарантировать запуск - это не гарантия, а лишь подсказка планировщику.
• Отсутствие упоминания, что порядок запуска не гарантирован даже для последовательных go вызовов.