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

sync.Pool не гарантирует сохранность помещённых объектов: сборщик мусора может удалить их из пула. После этого следующий вызов Get не найдёт переиспользуемый объект и создаст новый, поэтому снижение аллокаций может исчезнуть после GC.

Исторический контекст

В высоконагруженных программах часто создаются временные объекты: буферы, промежуточные структуры, рабочие контейнеры. Их постоянная аллокация увеличивает давление на сборщик мусора, поэтому в Go появился потокобезопасный механизм повторного использования таких объектов без ручного управления их временем жизни.

sync.Pool предназначен именно для временных объектов, которые можно безопасно потерять и создать заново. Это не кеш и не средство гарантированного хранения ресурсов.

Постановка проблемы

Если приложение рассчитывает, что объект останется в пуле между двумя обращениями, оно делает неверное предположение. После GC пул может оказаться пустым или содержать меньше объектов, поэтому Get начнёт возвращать новые экземпляры через функцию New либо через явное создание.

Дополнительный риск возникает при помещении в пул крупных объектов. Пока объект удерживается пулом, он может оставаться частью живого графа памяти; кроме того, его внутренний буфер способен сохранять большую вместимость. В результате число аллокаций уменьшится, но потребление памяти или стоимость сканирования не обязательно улучшатся.

Подробное решение

При вызове Put объект становится доступным для последующего Get. Однако документация sync.Pool не обещает, что объект будет возвращён: среда выполнения может автоматически удалить любой элемент без уведомления. Сборка мусора является естественной точкой, в которой такие элементы могут быть отброшены.

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

Минимальный пример:

package main

import (
    "bytes"
    "sync"
)

var buffers = sync.Pool{
    New: func() any { return new(bytes.Buffer) },
}

func use() {
    b := buffers.Get().(*bytes.Buffer)
    b.Reset()
    defer buffers.Put(b)
    b.WriteString("temporary data")
}

Перед помещением объекта обратно его нужно привести в безопасное начальное состояние. Для bytes.Buffer это означает как минимум вызов Reset; для пользовательского объекта нужно также очистить ссылки на крупные или конфиденциальные данные.

sync.Pool эффективен, когда объекты короткоживущие, имеют сопоставимый размер и часто повторно используются между операциями. Он не подходит для ограничения верхнего предела памяти, долговременного кеширования или хранения редких дорогих ресурсов.

Оценивать результат следует по профилям и нагрузочным тестам. Нужно измерять не только число аллокаций, но и CPU-время GC, объём живой памяти, RSS, задержки и стоимость очистки объектов. Иногда пул уменьшает аллокации, но добавляет накладные расходы на сброс состояния или удерживает слишком большие буферы.

Ситуация из практики

HTTP-сервис формирует временные буферы для сериализации ответа. После добавления sync.Pool число аллокаций снизилось, но часть запросов стала удерживать много памяти: несколько редких больших ответов оставили в пуле буферы с большой вместимостью.

Первый вариант — отказаться от пула. Это упрощает жизненный цикл и предотвращает удержание больших буферов, но увеличивает частоту аллокаций и давление на GC для обычных запросов.

Второй вариант — помещать в пул любые буферы без ограничений. Он лучше переиспользует память, но может надолго сохранить нехарактерно крупные объекты и не даёт гарантии повторного использования после GC.

Выбранное решение — использовать пул только для буферов до заданного размера, а слишком крупные экземпляры не возвращать в него. Буфер также сбрасывается перед использованием и после завершения операции. Такой подход сохраняет пользу повторного использования для типичной нагрузки, не превращая пул в неконтролируемое хранилище больших объектов.

Что кандидаты часто упускают

Можно ли использовать sync.Pool как ограниченный кеш объектов?

Нет. У пула нет гарантии сохранности элементов, политики ограничения размера и семантики обязательного возврата. Если объект должен быть доступен позже, следует использовать явный кеш или другой контейнер с определёнными правилами вытеснения и временем жизни.

Почему недостаточно просто вызвать Reset перед Put?

Reset обычно очищает логическое содержимое, но не обязан уменьшать выделенную вместимость внутреннего буфера. Поэтому объект после редкого большого запроса может продолжать удерживать крупный массив памяти. Для контроля памяти нужно дополнительно отбрасывать объекты, превышающие допустимый размер, а не возвращать их в пул.

Означает ли уменьшение аллокаций, что GC обязательно станет дешевле?

Нет. Пул может удерживать больше живых объектов, чем требуется в данный момент, а их поля, особенно указатели, могут участвовать в обходе графа памяти. Кроме того, остаются затраты на получение, сброс и возврат объектов. Поэтому итоговый эффект определяется не одной метрикой аллокаций, а сочетанием живой памяти, стоимости сканирования, CPU-времени GC и задержек приложения.