Senior Go Interview Prep

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


> Модуль: Concurrency · Уровень: Senior

## TL;DR
`sync.Mutex` — взаимное исключение для защиты разделяемого состояния; устроен на основе атомарного слова состояния + семафора рантайма для парковки горутин. С Go 1.9 у мьютекса есть **starvation mode**, защищающий «обиженные» горутины от голодания. `RWMutex` разрешает много читателей или одного писателя, но из-за дороговизны и риска голодания писателей полезен только при сильном перекосе в сторону чтения и длинных критических секциях. Мьютексы **нельзя копировать** после первого использования.

## Теория

### Устройство Mutex
`sync.Mutex` — это две машинных слова:

```go
type Mutex struct {
    state int32  // битовое поле: locked|woken|starving + счётчик ожидающих
    sema  uint32 // семафор рантайма для парковки/побудки горутин
}
```

Биты `state`:
- `mutexLocked` (1) — захвачен.
- `mutexWoken` (2) — есть разбуженная горутина, новым не нужно будить.
- `mutexStarving` (4) — режим голодания.
- старшие биты — счётчик заблокированных ожидающих (`waiters`).

#### Быстрый путь
```go
func (m *Mutex) Lock() {
    if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
        return // unlocked → locked одним CAS, без обращения к рантайму
    }
    m.lockSlow()
}
```
Неоспариваемый Lock/Unlock — это один атомарный CAS, без syscall и без переключения горутин. Поэтому «дешёвый» мьютекс часто быстрее канала.

#### Медленный путь и спин
В `lockSlow` горутина сначала **спинит** (`runtime_canSpin`: не более 4 итераций, есть свободные P, мультиядерность) с инструкцией PAUSE. Спин окупается, когда владелец вот-вот отпустит мьютекс — экономим парковку/побудку. Если спин не помог, горутина увеличивает счётчик ожидающих и паркуется на семафоре (`runtime_SemacquireMutex`), уходя из планировщика.

### Normal mode vs Starvation mode
Это ключевая деталь Go 1.9+.

**Normal (барный) режим:** очередь ожидающих — FIFO, но разбуженная горутина **не владеет мьютексом автоматически**, она конкурирует с новыми горутинами, которые уже выполняются на CPU и спинят. У «свежих» горутин преимущество (они на ядре), поэтому разбуженная часто проигрывает и снова паркуется. Это даёт высокую пропускную способность, но рискует **голоданием**.

**Starvation (честный) режим:** если горутина ждёт дольше **1 мс**, мьютекс переключается в starving. Тогда Unlock **передаёт владение напрямую первой в очереди** (handoff), новые горутины даже не спинят, а сразу встают в хвост очереди. Режим выключается, когда горутина, получившая мьютекс, видит, что она последняя в очереди или ждала <1 мс.

| | Normal | Starvation |
|---|---|---|
| Дисциплина | LIFO-подобная (barging) | строгий FIFO (handoff) |
| Пропускная способность | высокая | ниже |
| Латентность хвоста | плохая | ограничена |
| Триггер | по умолчанию | ожидание > 1 мс |

Это компромисс throughput vs tail latency: барьинг даёт скорость, но без честного режима один поток мог бы вечно опережать.

### RWMutex
```go
type RWMutex struct {
    w           Mutex  // мьютекс для писателей между собой
    writerSem   uint32 // семафор: писатель ждёт ухода читателей
    readerSem   uint32 // семафор: читатели ждут ухода писателя
    readerCount atomic.Int32 // число активных читателей (или смещённое при писателе)
    readerWait  atomic.Int32 // сколько читателей нужно дождаться писателю
}
```

- `RLock`: атомарно `readerCount++`. Если значение стало отрицательным — значит писатель ждёт/работает (он вычел `rwmutexMaxReaders`), читатель паркуется на `readerSem`.
- `Lock`: захватывает `w` (блокирует других писателей), вычитает `rwmutexMaxReaders` из `readerCount` (сигнал «писатель пришёл»), затем ждёт `readerWait` уходящих читателей.
- **Важная гарантия:** когда писатель ждёт, новые `RLock` блокируются. Это предотвращает голодание писателя бесконечным потоком читателей, но именно поэтому RWMutex не масштабируется идеально.

### Когда RWMutex вреден
RWMutex кажется бесплатной оптимизацией, но это не так:
- `RLock`/`RUnlock` дороже `Lock`/`Unlock` обычного мьютекса (больше атомарных операций и ветвлений).
- `readerCount` — общая атомарная переменная, по которой бьют все читатели → **cache-line contention** и трафик когерентности кэшей между ядрами. При коротких критических секциях RWMutex может быть **медленнее** обычного Mutex.
- Выгода появляется только когда: читателей сильно больше писателей **и** критическая секция достаточно длинная, чтобы параллельное чтение перекрыло накладные расходы.
- При высоком write-rate писатели могут голодать (хотя блокировка новых читателей это смягчает).

Альтернативы для read-heavy: `atomic.Value`/`atomic.Pointer` для copy-on-write, sharding (разбить состояние на N мьютексов по хэшу ключа), `sync.Map` для специфичных профилей доступа.

## Подводные камни / gotchas
- **Копирование мьютекса.** Передача структуры с Mutex по значению копирует его состояние — две копии «защищают» разные слова, инвариант ломается. `go vet`/`copylocks` ловит это. Всегда передавайте указатель.
- **Незащищённый Unlock.** `Unlock` незахваченного мьютекса → паника `sync: unlock of unlocked mutex`. Это фатально, не recover-абельно по контракту.
- **Unlock из другой горутины.** Mutex не привязан к горутине — отпустить может любая, но это почти всегда ошибка дизайна. Для рекурсии мьютекс не подходит (не reentrant) → самодедлок.
- **`defer mu.Unlock()` и горячий путь.** defer стоит дёшево с Go 1.14 (open-coded defers), но в очень горячем коде иногда отпускают вручную раньше, чтобы сузить критическую секцию.
- **`RLock` рекурсивно** опасен: если между двумя RLock одной горутины вклинится Lock писателя, второй RLock заблокируется → дедлок. RWMutex не reentrant даже для читателей.
- **Слишком широкая критическая секция** (например, I/O под мьютексом) убивает параллелизм. Держите блокировку минимально.
- **Забыли defer при раннем return** → утечка блокировки навсегда.

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

**В:** Что происходит при неоспариваемом Lock?
**О:** Один атомарный CAS `0 → mutexLocked` в быстром пути. Никаких обращений к рантайму, syscall или парковки. Поэтому такой мьютекс крайне дёшев.

**В:** Что такое starvation mode и зачем он нужен?
**О:** С Go 1.9 если горутина ждёт мьютекс дольше 1 мс, он переключается в честный FIFO-режим: Unlock передаёт владение напрямую первому в очереди, новые горутины не спинят и не «перехватывают» мьютекс. Это ограничивает tail latency и предотвращает голодание, жертвуя пропускной способностью normal-режима (где разрешён barging).

**В:** Почему в normal mode разбуженная горутина может снова заснуть?
**О:** В normal режиме нет прямой передачи владения. Разбуженная горутина конкурирует с уже работающими на CPU горутинами, которые спинят. Свежая часто захватывает мьютекс первой, и разбуженная снова паркуется. Это барьинг — он повышает throughput.

**В:** Когда RWMutex медленнее обычного Mutex?
**О:** При коротких критических секциях и/или высокой частоте операций: RLock делает больше атомарных операций по общей `readerCount`, создавая cache-line contention между ядрами. Накладные расходы перекрывают выгоду от параллельного чтения.

**В:** Голодают ли писатели в RWMutex?
**О:** Реализация Go это смягчает: как только писатель вызвал Lock и начал ждать, новые RLock блокируются (новые читатели не пускаются вперёд писателя). Старые читатели дорабатывают, писатель получает мьютекс. Полного голодания нет, но при шторме читателей задержка писателя всё равно есть.

**В:** Можно ли копировать Mutex?
**О:** Нет. После первого использования копирование разносит состояние по двум словам, ломая взаимное исключение. `go vet` (copylocks) детектит копирование структур с мьютексами. Передавайте по указателю.

**В:** Reentrant ли мьютекс в Go?
**О:** Нет. Повторный Lock из той же горутины — самодедлок. В Go это сознательное решение: реентрантность маскирует плохой дизайн владения данными. Нужна рекурсия — переструктурируйте код или вынесите критическую секцию.

**В:** Чем заменить RWMutex для read-heavy нагрузки?
**О:** `atomic.Pointer`/`atomic.Value` с copy-on-write (читатели вообще без блокировки), шардирование мьютексов по ключу, `sync.Map` для подходящих профилей. Выбор зависит от соотношения read/write и размера данных.

**В:** Что делает спин в lockSlow?
**О:** Перед парковкой горутина крутится несколько итераций с PAUSE, если есть свободные P и мультиядерность. Расчёт: владелец вот-вот отпустит, и спин дешевле, чем парковка+побудка через семафор и переключение контекста.

## На что копают на senior+
- Точная семантика битов `state` и переходов normal↔starving, порог 1 мс и условия выхода из starving.
- Барьинг vs handoff как компромисс throughput/tail-latency; почему дефолт — normal.
- Cache coherency и false sharing: почему общая атомарная переменная RWMutex плохо масштабируется; padding до cache line.
- Семафоры рантайма (`semacquire`/`semrelease`), `runtime_SemacquireMutex` и интеграция с планировщиком (горутина уходит из runq).
- Альтернативы: atomic snapshot, sharded locks, lock-free структуры и их memory model гарантии.
- Профилирование contention: `runtime/pprof` mutex/block профили, `GODEBUG`, `-mutexprofilefraction`.