Сколько весит пул в Go?
Что проверяют
Для начала, поняли ли вы вопрос: «пул» в Go это чаще всего sync.Pool, но спрашивать могут и про пул воркеров. Уточняющий вопрос здесь не слабость, а правильный ход. Дальше проверяют, понимаете ли вы, из чего складываются расходы памяти и зачем пул вообще нужен.
Как отвечать
Про sync.Pool: сама структура занимает несколько машинных слов, то есть десятки байт. Основной вес это внутренний массив локальных частей по числу P, то есть по GOMAXPROCS, и каждая такая часть выровнена по кэш-линии, чтобы ядра не толкались за одну строку кэша. Плюс вес самих лежащих в пуле объектов, и именно он обычно и интересен: пул ничем не ограничен сверху.
Ключевое про жизненный цикл: содержимое пула не вечно, его вычищает сборщик мусора, но не мгновенно. Есть промежуточный слой, куда объекты переезжают на один цикл, поэтому редко используемый пул переживает одну сборку и пустеет на следующей. Отсюда вывод: sync.Pool снижает давление на аллокатор в горячем пути, но это не кэш и не хранилище.
Если речь о пуле воркеров, счёт другой: горутина начинается со стека в пару килобайт, который растёт по мере надобности, плюс буфер канала с задачами.
Где спотыкаются
Считают, что пул удерживает объекты до конца работы процесса, и складывают туда соединения. Для соединений нужен контроль количества и корректное закрытие, а sync.Pool вправе выбросить объект в любой момент, ничего не спросив.
Второе: возвращают в пул раздутые буферы. Один большой запрос увеличивает буфер, тот уезжает обратно в пул и держит память до следующей сборки. Перед возвратом длину сбрасывают, а слишком большие экземпляры просто не кладут назад.
Третье: подбирают размер пула воркеров по числу ядер для задач, которые ждут сеть. Ограничение по GOMAXPROCS осмысленно для счётной нагрузки, а горутина в ожидании ввода-вывода поток не занимает.