Senior Go Interview Prep

- Core Go: https://go.vbloher.org/docs/01-core-go/
- Система типов Go: defined types, alignment, memory layout: https://go.vbloher.org/docs/01-core-go/type-system/
- Указатели в Go: https://go.vbloher.org/docs/01-core-go/pointers/
- Внутреннее устройство слайсов в Go: https://go.vbloher.org/docs/01-core-go/slices/
- Устройство map в Go: https://go.vbloher.org/docs/01-core-go/maps/
- Строки, руны и байты в Go: https://go.vbloher.org/docs/01-core-go/strings-runes-bytes/
- Интерфейсы в Go: https://go.vbloher.org/docs/01-core-go/interfaces/
- Встраивание структур и интерфейсов (Embedding): https://go.vbloher.org/docs/01-core-go/embedding/
- Ошибки в Go: error, wrapping, errors.Is/As/Join: https://go.vbloher.org/docs/01-core-go/errors/
- Механика defer в Go: https://go.vbloher.org/docs/01-core-go/defer/
- panic / recover: механика, раскрутка стека и runtime-паники: https://go.vbloher.org/docs/01-core-go/panic-recover/
- Замыкания и переменная цикла (Go 1.22): https://go.vbloher.org/docs/01-core-go/closures-loopvar/
- Дженерики в Go (1.18+): https://go.vbloher.org/docs/01-core-go/generics/
- encoding/json и теги структур: https://go.vbloher.org/docs/01-core-go/json-encoding/
- Рефлексия в Go (reflect): https://go.vbloher.org/docs/01-core-go/reflection/
- Модули, версионирование и зависимости: https://go.vbloher.org/docs/01-core-go/go-modules/
- Concurrency: https://go.vbloher.org/docs/02-concurrency/
- Горутины: жизненный цикл, стоимость, стек: https://go.vbloher.org/docs/02-concurrency/goroutines-lifecycle/
- Планировщик GMP: https://go.vbloher.org/docs/02-concurrency/scheduler-gmp/
- Каналы: устройство hchan: https://go.vbloher.org/docs/02-concurrency/channels/
- Буферизованные vs небуферизованные каналы: https://go.vbloher.org/docs/02-concurrency/buffered-unbuffered/
- select: https://go.vbloher.org/docs/02-concurrency/select/
- sync.WaitGroup: https://go.vbloher.org/docs/02-concurrency/waitgroup/
- sync.Mutex и sync.RWMutex: https://go.vbloher.org/docs/02-concurrency/mutex-rwmutex/
- sync/atomic: https://go.vbloher.org/docs/02-concurrency/atomic/
- sync.Once: https://go.vbloher.org/docs/02-concurrency/once/
- sync.Cond: https://go.vbloher.org/docs/02-concurrency/cond/
- sync.Map и sync.Pool: https://go.vbloher.org/docs/02-concurrency/sync-map-pool/
- errgroup: группа горутин с ошибкой и отменой: https://go.vbloher.org/docs/02-concurrency/errgroup/
- context: https://go.vbloher.org/docs/02-concurrency/context/
- Канал vs Mutex: когда что выбрать: https://go.vbloher.org/docs/02-concurrency/channel-vs-mutex/
- Паттерны конкурентности: https://go.vbloher.org/docs/02-concurrency/patterns/
- Утечки горутин, дедлоки, livelock, starvation: https://go.vbloher.org/docs/02-concurrency/common-leaks-deadlocks/
- Race Detector (гонки данных и -race): https://go.vbloher.org/docs/02-concurrency/race-detector/
- Runtime и память: https://go.vbloher.org/docs/03-runtime-memory/
- Стек vs Куча: где живут данные в Go: https://go.vbloher.org/docs/03-runtime-memory/stack-vs-heap/
- Escape Analysis: когда переменная убегает в кучу: https://go.vbloher.org/docs/03-runtime-memory/escape-analysis/
- Паттерны аллокаций и снижение давления на GC: https://go.vbloher.org/docs/03-runtime-memory/allocation-patterns/
- Сборщик мусора Go: concurrent tri-color mark-sweep: https://go.vbloher.org/docs/03-runtime-memory/gc/
- Тюнинг GC: GOGC и GOMEMLIMIT: https://go.vbloher.org/docs/03-runtime-memory/gogc-gomemlimit/
- GOMAXPROCS: параллелизм планировщика и проблема контейнеров: https://go.vbloher.org/docs/03-runtime-memory/gomaxprocs/
- Модель памяти Go (Go Memory Model): happens-before и синхронизация: https://go.vbloher.org/docs/03-runtime-memory/memory-model/
- Утечки памяти в Go (несмотря на GC): https://go.vbloher.org/docs/03-runtime-memory/memory-leaks/
- Утечки горутин (goroutine leaks): https://go.vbloher.org/docs/03-runtime-memory/goroutine-leaks/
- pprof: профилирование CPU, памяти и блокировок в Go: https://go.vbloher.org/docs/03-runtime-memory/pprof/
- Execution Tracer и runtime/trace: тайминги вместо агрегатов: https://go.vbloher.org/docs/03-runtime-memory/runtime-tracing/
- Тестирование: https://go.vbloher.org/docs/04-testing/
- Table-driven тесты, subtests и параллельность: https://go.vbloher.org/docs/04-testing/table-driven/
- testify, assert/require и golden files: https://go.vbloher.org/docs/04-testing/assertions-testify/
- Моки, стабы и тестируемость: https://go.vbloher.org/docs/04-testing/mocks/
- Покрытие, -race и флаки-тесты: https://go.vbloher.org/docs/04-testing/coverage-race/
- Бенчмарки в Go: https://go.vbloher.org/docs/04-testing/benchmarks/
- Нативный fuzzing в Go (1.18+): https://go.vbloher.org/docs/04-testing/fuzzing/
- Интеграционные тесты, testcontainers-go, TestMain: https://go.vbloher.org/docs/04-testing/integration-testcontainers/
- Backend: https://go.vbloher.org/docs/05-backend/
- Структура Go-проекта: https://go.vbloher.org/docs/05-backend/project-layout/
- net/http: Server, Handler, ServeMux, таймауты, Client и контекст: https://go.vbloher.org/docs/05-backend/net-http/
- Middleware-паттерн в Go: https://go.vbloher.org/docs/05-backend/middleware/
- REST: принципы, версионирование, идемпотентность, статусы, пагинация, ошибки: https://go.vbloher.org/docs/05-backend/rest/
- OpenAPI/Swagger, code generation, contract-first vs code-first, валидация: https://go.vbloher.org/docs/05-backend/openapi/
- gRPC: типы RPC, интерсепторы, контекст, метаданные, error model: https://go.vbloher.org/docs/05-backend/grpc/
- Protocol Buffers: схемы, wire format, эволюция и совместимость: https://go.vbloher.org/docs/05-backend/protobuf/
- Аутентификация и авторизация: AuthN/AuthZ, сессии vs токены, RBAC/ABAC, API keys, mTLS, секреты: https://go.vbloher.org/docs/05-backend/auth-authz/
- JWT (JSON Web Token): https://go.vbloher.org/docs/05-backend/jwt/
- OAuth2: роли, grant types, OIDC, токены и типовые ошибки: https://go.vbloher.org/docs/05-backend/oauth2/
- Graceful Shutdown HTTP/gRPC сервера в Go: https://go.vbloher.org/docs/05-backend/graceful-shutdown/
- Чистая архитектура и внедрение зависимостей в Go: https://go.vbloher.org/docs/05-backend/clean-architecture/
- Сети и протоколы: https://go.vbloher.org/docs/06-networking/
- TCP/IP: модель, транспорт и что важно бэкендеру: https://go.vbloher.org/docs/06-networking/tcp-ip/
- UDP и надёжность поверх UDP: https://go.vbloher.org/docs/06-networking/udp/
- DNS: записи, резолвинг, кэширование, DNS в Go: https://go.vbloher.org/docs/06-networking/dns/
- Версии HTTP: 1.1, 2, 3: https://go.vbloher.org/docs/06-networking/http-versions/
- TLS: handshake, сертификаты, mTLS, производительность: https://go.vbloher.org/docs/06-networking/tls/
- WebSocket: upgrade, фреймы, масштабирование: https://go.vbloher.org/docs/06-networking/websocket/
- Пулы соединений: http.Transport, БД, утечки: https://go.vbloher.org/docs/06-networking/connection-pooling/
- Базы данных: https://go.vbloher.org/docs/07-databases/
- Архитектура PostgreSQL: https://go.vbloher.org/docs/07-databases/postgresql-architecture/
- Транзакции в PostgreSQL и Go (database/sql, pgx): https://go.vbloher.org/docs/07-databases/transactions/
- Уровни изоляции транзакций в PostgreSQL: https://go.vbloher.org/docs/07-databases/isolation-levels/
- MVCC в PostgreSQL: версии строк, видимость, VACUUM и bloat: https://go.vbloher.org/docs/07-databases/mvcc/
- Индексы в PostgreSQL: https://go.vbloher.org/docs/07-databases/indexes/
- Планирование и оптимизация запросов в PostgreSQL: https://go.vbloher.org/docs/07-databases/query-planning/
- Взаимоблокировки (Deadlocks) в PostgreSQL: https://go.vbloher.org/docs/07-databases/deadlocks/
- Пул соединений к PostgreSQL в Go: database/sql, pgx, pgxpool, PgBouncer: https://go.vbloher.org/docs/07-databases/connection-pooling-pgx/
- Партиционирование таблиц в PostgreSQL: https://go.vbloher.org/docs/07-databases/partitioning/
- Репликация в PostgreSQL: https://go.vbloher.org/docs/07-databases/replication/
- Шардирование (горизонтальное масштабирование): https://go.vbloher.org/docs/07-databases/sharding/
- Обзор NoSQL и Redis: https://go.vbloher.org/docs/07-databases/nosql-redis/
- Распределённые системы: https://go.vbloher.org/docs/08-distributed-systems/
- CAP теорема: https://go.vbloher.org/docs/08-distributed-systems/cap-theorem/
- Модели согласованности: https://go.vbloher.org/docs/08-distributed-systems/consistency/
- Eventual Consistency: https://go.vbloher.org/docs/08-distributed-systems/eventual-consistency/
- Идемпотентность в распределённых системах: https://go.vbloher.org/docs/08-distributed-systems/idempotency/
- Ретраи: backoff, jitter, budgets и идемпотентность: https://go.vbloher.org/docs/08-distributed-systems/retries/
- Circuit Breaker: https://go.vbloher.org/docs/08-distributed-systems/circuit-breaker/
- Гарантии доставки сообщений: at-most-once / at-least-once / exactly-once: https://go.vbloher.org/docs/08-distributed-systems/delivery-guarantees/
- Transactional Outbox: https://go.vbloher.org/docs/08-distributed-systems/outbox/
- Saga Pattern: https://go.vbloher.org/docs/08-distributed-systems/saga/
- Apache Kafka: https://go.vbloher.org/docs/08-distributed-systems/kafka/
- RabbitMQ: AMQP 0-9-1, маршрутизация, надёжность доставки и сравнение с Kafka: https://go.vbloher.org/docs/08-distributed-systems/rabbitmq/
- Консенсус и Raft: репликация состояния в присутствии отказов: https://go.vbloher.org/docs/08-distributed-systems/consensus-raft/
- Observability: https://go.vbloher.org/docs/09-observability/
- Метрики: RED, USE, Golden Signals: https://go.vbloher.org/docs/09-observability/metrics/
- Структурированное логирование (slog): https://go.vbloher.org/docs/09-observability/structured-logging/
- Distributed Tracing: https://go.vbloher.org/docs/09-observability/tracing/
- OpenTelemetry: https://go.vbloher.org/docs/09-observability/opentelemetry/
- Prometheus: https://go.vbloher.org/docs/09-observability/prometheus/
- Grafana: https://go.vbloher.org/docs/09-observability/grafana/
- SLI / SLO / SLA: https://go.vbloher.org/docs/09-observability/slo-sli/
- System Design: https://go.vbloher.org/docs/10-system-design/
- Фреймворк System Design интервью: https://go.vbloher.org/docs/10-system-design/framework/
- URL Shortener: https://go.vbloher.org/docs/10-system-design/url-shortener/
- Rate Limiter: https://go.vbloher.org/docs/10-system-design/rate-limiter/
- Chat System: https://go.vbloher.org/docs/10-system-design/chat/
- Notification Service: https://go.vbloher.org/docs/10-system-design/notification-service/
- Order Service: https://go.vbloher.org/docs/10-system-design/order-service/
- Payment Service: https://go.vbloher.org/docs/10-system-design/payment-service/
- Analytics Pipeline: https://go.vbloher.org/docs/10-system-design/analytics-pipeline/
- DevOps: https://go.vbloher.org/docs/11-devops/
- Docker для Go-разработчика: https://go.vbloher.org/docs/11-devops/docker/
- Kubernetes для Go-разработчика: https://go.vbloher.org/docs/11-devops/kubernetes/
- CI/CD: пайплайны, стадии, стратегии деплоя: https://go.vbloher.org/docs/11-devops/cicd/
- GitHub Actions и GitLab CI: https://go.vbloher.org/docs/11-devops/github-gitlab-ci/
- Terraform / Infrastructure as Code: https://go.vbloher.org/docs/11-devops/terraform/
- Облака (AWS / GCP) для бэкендера: https://go.vbloher.org/docs/11-devops/cloud-aws-gcp/
- Алгоритмы: https://go.vbloher.org/docs/12-algorithms/
- Асимптотическая сложность (Big-O): https://go.vbloher.org/docs/12-algorithms/complexity/
- Структуры данных в Go: https://go.vbloher.org/docs/12-algorithms/data-structures/
- Типовые алгоритмические задачи и паттерны: https://go.vbloher.org/docs/12-algorithms/common-problems/
- Специфика live-coding на Go: https://go.vbloher.org/docs/12-algorithms/go-specifics/
- Behavioral: https://go.vbloher.org/docs/13-behavioral/
- Как проходит senior-интервью: этапы, оценка, оффер: https://go.vbloher.org/docs/13-behavioral/interview-flow/
- Типовые поведенческие вопросы для Senior: https://go.vbloher.org/docs/13-behavioral/senior-questions/
- Конфликты, разногласия и работа со стейкхолдерами: https://go.vbloher.org/docs/13-behavioral/conflicts/
- Лидерство и менторство: https://go.vbloher.org/docs/13-behavioral/leadership-mentoring/


# sync.Map и sync.Pool
> Модуль: Concurrency · Уровень: Senior

## TL;DR
`sync.Map` — специализированная конкурентная мапа для **двух конкретных сценариев**: ключ пишется один раз и потом много читается, либо разные горутины работают с непересекающимися наборами ключей. В остальных случаях обычная `map` под `RWMutex` (или шардированная мапа) быстрее и типобезопаснее. `sync.Pool` — пул временных объектов для снижения давления на GC; содержимое пула **очищается сборщиком мусора** (с Go 1.13 через victim cache объект переживает один цикл), поэтому это буфер переиспользования, а не кэш и не пул соединений. Оба типа нельзя копировать после первого использования; оба не дают строгих гарантий наличия данных, и оба стоит применять только после того, как профиль показал проблему.

## Простыми словами

`sync.Map` — конкурентная мапа для двух узких сценариев, `sync.Pool` — ящик для переиспользования временных объектов. Оба часто берут не по назначению.

**`sync.Map`** — это мапа, в которую можно писать из нескольких горутин без мьютекса. Звучит как «просто лучшая мапа», но это не так: она заметно медленнее обычной на смешанной нагрузке и хранит `any` вместо конкретных типов, то есть теряет проверку компилятора. Она выигрывает ровно в двух ситуациях, под которые её и делали: когда ключ записали один раз и дальше только читают, и когда горутины работают каждая со своими ключами. Всё остальное — обычная `map` плюс `sync.RWMutex`.

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

**Если ты с другого языка.** `sync.Map` — примерно `ConcurrentHashMap`, но с гораздо более узкой областью применения, и в Go нет культуры «всегда бери конкурентную коллекцию». `sync.Pool` ближе всего к пулам объектов из мира высоконагруженной Java, только с автоматической очисткой при сборке мусора.

**Словарь этой статьи:**

- **contention** — конкуренция горутин за один мьютекс;
- **шардирование мапы** — разбиение на N мап со своими мьютексами по хешу ключа;
- **victim cache** — «предбанник» пула, благодаря которому объект переживает один цикл сборки мусора;
- **`Put`/`Get`** — вернуть объект в пул и взять из пула.

## Теория

### sync.Map: зачем и когда

Обычная `map` не потокобезопасна: конкурентная запись роняет процесс с `fatal error: concurrent map writes`, причём это не паника и `recover` не спасает. Стандартное решение — мьютекс:

```go
type Cache struct {
    mu sync.RWMutex
    m  map[string]*Item
}

func (c *Cache) Get(k string) (*Item, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock()
    v, ok := c.m[k]
    return v, ok
}
```

Это работает и в большинстве случаев быстрее `sync.Map`. Проблема появляется на многоядерной машине при высокой частоте обращений: даже `RLock` — это атомарная операция над общим счётчиком, и кэш-линия с ним начинает «летать» между ядрами.

Документация `sync.Map` прямо называет два сценария, где она выигрывает:

1. **Запись один раз, чтения много.** Ключ добавляется и больше не меняется — например реестр обработчиков, кэш скомпилированных шаблонов, метаданные типов.
2. **Непересекающиеся наборы ключей.** Каждая горутина читает и пишет свои ключи, пересечений почти нет.

В обоих случаях чтение идёт по атомарно читаемой копии без блокировок вообще.

```go
var registry sync.Map

registry.Store("json", jsonCodec)          // записать
v, ok := registry.Load("json")             // прочитать
v, loaded := registry.LoadOrStore("x", c)  // прочитать или записать атомарно
registry.Delete("json")
registry.Range(func(k, v any) bool {       // обход; false прерывает
    return true
})
```

Ключевой метод — **`LoadOrStore`**: он решает классическую задачу «создать значение, если его ещё нет» без гонки, когда две горутины одновременно обнаружили отсутствие ключа.

Внутреннее устройство (полезно понимать, а не заучивать): исторически внутри лежали две мапы — атомарно читаемая `read` и защищённая мьютексом `dirty`. Чтение существующего ключа шло по `read` без блокировок, промахи вели в `dirty` и учитывались счётчиком; при накоплении промахов `dirty` становилась новой `read`. В Go 1.24 реализацию переписали на `HashTrieMap`, что заметно улучшило поведение при частых записях, но рекомендации по применению не изменились.

### Что обычно лучше: шардированная мапа

Если нагрузка не подходит под два сценария выше, а мьютекс стал узким местом, стандартный ответ — шардирование:

```go
const shards = 32

type ShardedMap struct {
    parts [shards]struct {
        mu sync.RWMutex
        m  map[string]*Item
        _  [40]byte // паддинг против false sharing
    }
}

func (s *ShardedMap) shard(k string) int {
    return int(fnv32(k)) % shards
}
```

Конкуренция падает примерно в число шардов, типизация сохраняется, поведение предсказуемо. Именно так устроены популярные библиотеки конкурентных кэшей.

### sync.Pool: устройство и границы применимости

```go
var bufPool = sync.Pool{
    New: func() any {                 // вызывается, когда пул пуст
        return new(bytes.Buffer)
    },
}

func handle(w io.Writer, data any) error {
    buf := bufPool.Get().(*bytes.Buffer)
    defer func() {
        buf.Reset()          // обязательно очистить перед возвратом
        bufPool.Put(buf)
    }()

    if err := json.NewEncoder(buf).Encode(data); err != nil {
        return err
    }
    _, err := w.Write(buf.Bytes())
    return err
}
```

Что происходит внутри: у каждого `P` (логического процессора) есть своя приватная ячейка и локальная очередь, поэтому в типичном случае `Get`/`Put` обходятся без блокировок и без конкуренции между ядрами.

Главное свойство, определяющее область применения: **пул очищается при сборке мусора**. С Go 1.13 очистка двухступенчатая — содержимое сначала переезжает в victim cache и удаляется только на следующем цикле, что сгладило провалы производительности сразу после сборки. Но принцип остался: положенный объект не гарантированно доживёт до следующего `Get`.

Отсюда прямые следствия:

- **пул соединений на `sync.Pool` строить нельзя** — соединения будут исчезать, а их надо ещё и закрывать;
- **кэш на `sync.Pool` строить нельзя** — данные пропадут в произвольный момент;
- подходит он ровно для одного: **короткоживущие однотипные буферы в горячем пути**.

### Ловушка с большими буферами

```go
// ПЛОХО: пул постепенно накапливает гигантские буферы
buf := bufPool.Get().(*bytes.Buffer)
buf.Write(hugePayload)   // буфер вырос до 100 МБ
buf.Reset()              // Reset НЕ уменьшает ёмкость
bufPool.Put(buf)         // в пул вернулся объект на 100 МБ
```

`Reset` обнуляет длину, но не ёмкость. Один аномально большой запрос навсегда раздувает буфер, и пул начинает удерживать память, которую больше никто не использует. Стандартное лечение — не возвращать переростков:

```go
const maxKeep = 64 << 10 // 64 КБ

if buf.Cap() <= maxKeep {
    buf.Reset()
    bufPool.Put(buf)
}
```

Ровно эту проблему в своё время чинили в самом `net/http`, и на собеседовании её любят.

### Вторая ловушка: ссылка на возвращённый объект

```go
buf := bufPool.Get().(*bytes.Buffer)
defer bufPool.Put(buf)
...
return buf.Bytes()   // БАГА: слайс смотрит в память, которую переиспользуют
```

После `Put` объект принадлежит пулу, и его содержимое может измениться в любой момент из другой горутины. Возвращать наружу нужно копию.

### Когда пул вообще оправдан

Не всегда. `sync.Pool` сам по себе имеет стоимость, и на редких вызовах он проигрывает обычной аллокации: молодой мусор в Go и так убирается недорого.

Разумный порядок действий: сначала бенчмарк с `-benchmem`, потом попытка избавиться от аллокации вовсе (предразмер слайса, `strings.Builder`, работа на месте), и только если аллокации крупные, частые и однотипные — пул. Проверять результат обязательно тем же бенчмарком.

## Подводные камни / gotchas

- **`sync.Map` — не «быстрая мапа».** На смешанной нагрузке она проигрывает `map` + `RWMutex`. Применяй только под два описанных сценария.
- **`sync.Map` не типизирована.** `any` внутри означает приведение типов при каждом чтении и потерю проверок компилятора.
- **`Range` не даёт снимок.** Он видит состояние на момент обхода и может как увидеть, так и не увидеть параллельные изменения.
- **Пул чистится сборщиком мусора.** Никаких гарантий сохранности: не кэш, не пул соединений, не хранилище состояния.
- **`Reset` не уменьшает ёмкость.** Без ограничения размера пул раздувается от единичных больших запросов.
- **Ссылка на объект после `Put`** — гонка данных с непредсказуемым результатом.
- **Забыть очистить объект перед `Put`** — утечка данных между запросами; в худшем случае чужие данные попадут в чужой ответ.
- **Копирование.** Ни `sync.Map`, ни `sync.Pool` нельзя копировать после использования; передавай указателем. `go vet` это ловит.

## Вопросы на собеседовании

**В:** Когда стоит брать `sync.Map` вместо мапы с мьютексом?
**О:** В двух случаях: ключ записывается один раз и дальше в основном читается, либо горутины работают с непересекающимися наборами ключей. В остальных сценариях `map` под `RWMutex` быстрее и удобнее за счёт типизации.

**В:** Что произойдёт при конкурентной записи в обычную мапу?
**О:** Рантайм обнаружит это и завершит процесс с `fatal error: concurrent map writes`. Это не паника, `recover` не помогает — сознательное решение авторов, чтобы гонка не превращалась в тихое повреждение данных.

**В:** Зачем нужен `LoadOrStore`?
**О:** Чтобы атомарно получить существующее значение или записать своё. Без него две горутины могут одновременно обнаружить отсутствие ключа и создать два разных значения.

**В:** Что происходит с содержимым `sync.Pool` при сборке мусора?
**О:** Оно очищается. С Go 1.13 объекты сначала переезжают в victim cache и удаляются на следующем цикле, поэтому один цикл они переживают. Гарантий сохранности нет, и на этом нельзя строить кэш.

**В:** Почему на `sync.Pool` нельзя сделать пул соединений?
**О:** Потому что соединения будут молча исчезать при сборке мусора, а закрывать их окажется некому. Пулу соединений нужны учёт, проверка живости и ограничение количества — ничего этого `sync.Pool` не даёт.

**В:** Какая типичная утечка памяти связана с `sync.Pool`?
**О:** Возврат в пул буфера, разросшегося на аномально большом запросе: `Reset` не уменьшает ёмкость, и пул навсегда удерживает лишнюю память. Лечится проверкой `Cap()` перед `Put`.

**В:** Как измерить пользу от пула?
**О:** Бенчмарком с `-benchmem` до и после, глядя на `allocs/op` и `B/op`, и профилем кучи. На редких вызовах пул часто проигрывает обычной аллокации.

## На что копают на senior+

- Умение объяснить, **почему** у `sync.Map` такая узкая ниша, и предложить шардирование как основную альтернативу.
- Понимание связи `sync.Pool` со сборщиком мусора, включая роль victim cache и причину его появления.
- Осознание, что оба примитива — оптимизация, а не выбор по умолчанию: сначала измерение, потом применение.
- Знание типовых аварий: раздувание пула, ссылка на возвращённый объект, утечка данных между запросами.
- Follow-up: «Почему конкурентная запись в мапу — `fatal error`, а не паника?», «Как устроен `sync.Pool` относительно `P` и почему `Get`/`Put` почти бесплатны?», «Что изменилось в `sync.Map` в Go 1.24?».