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
Горутина — это легковесный поток исполнения, управляемый рантаймом Go, а не ОС. Стартовый стек ~2 КБ, растёт/сжимается копированием. Создаётся через `go f()`, планируется на потоки ОС моделью GMP. Завершается при возврате из функции; неперехваченная паника в горутине роняет весь процесс.

## Теория

### Что такое горутина под капотом
Горутина представлена структурой `runtime.g` (файл `src/runtime/runtime2.go`). Это не поток ОС: множество горутин мультиплексируется на ограниченное число потоков ОС (`M`) через логические процессоры (`P`). Ключевые поля `g`:

- `stack` — границы стека (`lo`, `hi`).
- `stackguard0` — порог для проверки переполнения стека (morestack), также используется для preemption (выставляется в `stackPreempt`).
- `sched` (`gobuf`) — сохранённый контекст (SP, PC, BP) для возобновления.
- `atomicstatus` — состояние горутины.
- `goid`, `m`, `waitreason`.

### Стоимость
| Параметр | Горутина | Поток ОС |
|---|---|---|
| Стартовый стек | ~2 КБ | 1–8 МБ (зарезервировано) |
| Создание | сотни наносекунд, без syscall | syscall, микросекунды |
| Переключение | в user-space, ~десятки нс | через ядро, дороже |
| Кол-во | сотни тысяч / миллионы | тысячи (упирается в память) |

Создание `go f()` компилируется в вызов `runtime.newproc`, который аллоцирует/переиспользует `g` (свободные `g` лежат в `p.gFree` и глобальном `sched.gFree`), кладёт её в runqueue текущего `P`.

### Рост стека (segmented → contiguous)
До Go 1.3 были сегментированные стеки (hot split проблема). Сейчас — **непрерывный стек с копированием**:

1. В пролог каждой функции компилятор вставляет проверку `SP < stackguard0`.
2. Если места не хватает, вызывается `runtime.morestack`.
3. Рантайм аллоцирует новый стек вдвое больше, **копирует** содержимое, корректирует указатели (для этого нужны точные стек-мапы — поэтому в Go нет «голых» указателей внутрь стека без ведома GC).
4. Старый стек освобождается; при сжатии (`shrinkstack`, во время GC) — наоборот.

```go
// Глубокая рекурсия заставит стек расти многократным копированием
func deep(n int) {
    if n == 0 { return }
    var buf [1024]byte // давит на стек
    _ = buf
    deep(n - 1)
}
```

### Состояния (atomicstatus)
- `_Gidle` — только создана.
- `_Grunnable` — в очереди, готова к запуску.
- `_Grunning` — исполняется на `M` (привязана к `P`).
- `_Gsyscall` — в системном вызове.
- `_Gwaiting` — заблокирована (канал, mutex, GC, `time.Sleep`).
- `_Gdead` — завершилась/свободна (в пуле для переиспользования).
- `_Gcopystack` — стек копируется (рост/сжатие).

### Жизненный цикл
```
go f()  → newproc → _Grunnable → (scheduler) → _Grunning
   ├─ блокировка (chan/mutex) → _Gwaiting → разблокировка → _Grunnable
   ├─ syscall → _Gsyscall → возврат → _Grunnable
   └─ return из f → goexit → _Gdead → пул gFree
```

При возврате из функции горутины выполняется `runtime.goexit`: запускаются отложенные `defer` (если не запущены), горутина переводится в `_Gdead` и кладётся в пул.

### Паника в горутине
Паника раскручивает стек **только этой** горутины, выполняя её `defer`. Если ни один `defer` не вызвал `recover`, рантайм печатает трейс и **завершает весь процесс** (`fatal error`). `recover` в другой горутине не помогает.

```go
func main() {
    go func() {
        defer func() { recover() }() // ловит ТОЛЬКО панику в этой горутине
        panic("boom")
    }()
    // паника без recover здесь убила бы весь процесс
}
```

## Подводные камни / gotchas
- **Утечка горутины**: заблокированная навсегда горутина (на канале/в `select` без выхода) не собирается GC — её корни (стек) живы. См. отдельный файл про leaks.
- **`recover` работает только в `defer`** той же горутины. Защищайте каждую запускаемую горутину собственным `recover`, если паника в ней не должна ронять процесс.
- **Переменная цикла (до Go 1.22)**: `for i := range ... { go func(){ use(i) }() }` захватывал общую `i`. С Go 1.22 каждая итерация имеет свою переменную — проблема ушла, но на собеседовании про неё спрашивают.
- **`os.Exit` / возврат из `main`** убивает все горутины немедленно, без `defer`.
- **Глубокая рекурсия** → дорогое копирование стека; в горячем коде это заметно.
- Нет API «убить горутину» извне — только кооперативная отмена через `context`/каналы.

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

**В:** Чем горутина отличается от потока ОС?
**О:** Горутина — пользовательская абстракция рантайма Go, мультиплексируемая на потоки ОС моделью GMP. Стартовый стек ~2 КБ против мегабайтов у потока; создание и переключение дешевле, без перехода в ядро в типичном случае; планирование кооперативно-вытесняющее в user-space. Это позволяет держать сотни тысяч горутин.

**В:** Как растёт стек горутины?
**О:** Непрерывный стек, растёт копированием. Пролог функции сравнивает SP со `stackguard0`; при нехватке `morestack` аллоцирует вдвое больший стек, копирует данные и корректирует указатели по точным стек-мапам. Сжатие происходит при GC через `shrinkstack`.

**В:** Что произойдёт при панике в горутине без recover?
**О:** Раскрутится стек этой горутины с выполнением её `defer`; если recover не вызван, рантайм печатает fatal error и завершает весь процесс. Recover в других горутинах не спасает.

**В:** Почему стартовый стек именно маленький, и в чём цена?
**О:** Маленький стек даёт дешёвое создание и высокую плотность горутин. Цена — потенциальные операции роста/копирования при глубоких вызовах; для этого нужны точные стек-мапы и невозможность «спрятать» указатель в стек от рантайма.

**В:** Как горутина переходит в `_Gwaiting` и обратно?
**О:** При блокировке (пустой/полный канал, mutex, sleep) рантайм вызывает `gopark`, переводя `g` в `_Gwaiting` и освобождая `M`/`P`. При наступлении события `goready` возвращает её в runqueue как `_Grunnable`.

**В:** Можно ли извне завершить горутину?
**О:** Нет принудительного механизма. Только кооперативно: горутина сама должна проверять `ctx.Done()` или сигнальный канал и выходить. Поэтому долгоживущие горутины обязаны принимать `context`.

**В:** Что такое `runtime.Gosched()`?
**О:** Добровольная уступка процессора: текущая горутина переводится в runnable и помещается в очередь, давая шанс другим. Редко нужна напрямую; полезна в тесных циклах без точек преемпции (до async preemption была частым воркэраундом).

**В:** Куда деваются завершённые горутины?
**О:** Переходят в `_Gdead` и кладутся в пул `gFree` (на `P` и глобальный) для переиспользования структуры `g` и стека, чтобы не аллоцировать заново.

## На что копают на senior+
- Точные стек-мапы и почему они нужны для перемещения стека и precise GC.
- Взаимодействие роста стека с async preemption (signal-based) и safe points.
- Переиспользование `g` и стеков через `gFree`, влияние на латентность.
- Влияние глубокой рекурсии и больших стек-фреймов на p99 латентность из-за `morestack`.
- Почему `recover` обязан быть в отложенном вызове и как это связано с механизмом раскрутки `_panic`/`_defer`.