sync.Pool помогает переиспользовать временные объекты и уменьшать число выделений памяти. Он не гарантирует сохранность объекта, ограниченный размер или возврат конкретного значения. Поэтому активные SSE-соединения нельзя использовать как ресурсы, жизненным циклом которых управляет sync.Pool. Для них нужен явный учёт клиентов и завершения; временные буферы подготовки событий можно переиспользовать отдельно.
Зачем использовать sync.Pool? Можно ли хранить SSE-соединения в sync.Pool?
sync.Pool предназначен для временных переиспользуемых объектов, а не для учёта живых соединений. Как разделить буферы и жизненный цикл SSE-клиента.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
sync.Pool используют как необязательную оптимизацию для временных объектов: например, буферов сериализации, которые после операции больше никому не нужны. Это может уменьшить число аллокаций и нагрузку на сборщик мусора. Пользу проверяют измерениями: сам факт применения пула не гарантирует ускорения.
У него принципиально другой контракт, чем у пула соединений:
- Объект может исчезнуть из пула без уведомления.
Getне обязан вернуть ранее положенный объект; при отсутствии значения используетсяNew, если она задана.- Нет встроенного ограничения числа живых ресурсов, ожидания свободного соединения или протокола обязательного закрытия.
Эти ограничения указаны в документации sync.Pool. Потокобезопасность самого пула не означает безопасность одновременного использования полученного объекта несколькими горутинами.
Активное SSE-подключение хранить таким способом нельзя как управляемый ресурс. Оно связано с конкретным клиентом, подписками, очередью событий и временем жизни HTTP-запроса. Потеря ссылки из пула не является корректным отключением клиента, а случайная выдача объекта другому обработчику нарушит принадлежность ресурса.
Для SSE нужен явный реестр клиентов либо другой механизм владения, ограниченные очереди, обработка медленных получателей и прекращение работы при отмене запроса или ошибке записи. Поведение контекста входящего запроса описано в net/http. Нельзя продолжать пользоваться ResponseWriter после завершения обработчика.
Отдельно можно переиспользовать буфер подготовки одного события: получить, заполнить, полностью закончить использование и только затем вернуть. После возврата обращаться к нему уже нельзя. Состояние сбрасывают перед повторным использованием; слишком большие буферы можно не возвращать. Сброс длины буфера сам по себе не гарантирует стирания конфиденциальных байтов из памяти.