Всем, привет! А кто-нибудь сталкивался с проблемой, что горутины не

запускаются?

Код примерно такой

ch := make(chan int, 10000)

n := readFromEnvOrUseDefault() // т.е. тут всегда больше 0
for i := 0; i < n; i++ {
go StartMyGoroutine(i, ch) // i - нужна чтобы потом в логах понять кто косячит
}

sleep(5 * time.Second)

go sendDataToChannel(ch) // тут стартуем горутину, которая добавляет данные в ch

go startMonitorOfCh(ch) // горутина, которая следит, чтобы канал не переполнился. если len(ch) == cap(ch), то кидает панику

Если после for не написать sleep в 5 секунд(от балды написал 5 секунд и стало работать), то может оказаться так, что часть или все горутины от функции StartMyGoroutine не запустятся
В StartMyGoroutine добавил специальный тикер, который в логи кидает, что горутина жива и видно, что начинает кидать далеко не сразу, да и startMonitorOfCh от запуска к запуску стала падать в панику.

Запускается всё на более, чем мощном сервере с 24 ядрами (48, если считать HT). Количество горутин - 10.

Через функцию ниже проверял, что ядра видятся корректно и возвращает 48

func MaxParallelism() int {
maxProcs := runtime.GOMAXPROCS(0)
numCPU := runtime.NumCPU()

if maxProcs < numCPU {
return maxProcs
}

return numCPU
}

А есть детали - что значит не стартует? Вообще нет логов от них или зависают на конкретной операции? Предлагаю для начала локально дебаггером пройти, нежели катить на сервак

readFromEnvOrUseDefault() почти уверен, что здесь возвращается 0

А точно больше нету горутин? Консьюмеры похоже либо тупо заблочены, либо вытеснены другими горутинами. Ещё как вариант можно попробовать сначала продьюсер стартовать, а только потом консьюмить, тогда меньше шансов что горутины запаркуются

А нафиг выносить в отдельную горутину отслеживание заполненности канала? Имхо это было бы логично сделать через буферизованный канал и селект в продьюсере