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 строится на трёх сущностях: G (горутина), M (поток ОС), P (логический процессор/контекст планирования). P держит локальную очередь runnable-горутин, число P = `GOMAXPROCS`. Используются work stealing, кооперативная и (с 1.14) асинхронная вытесняющая преемпция, handoff P при блокирующих syscall и интегрированный netpoller для сетевого I/O.

## Теория

### G, M, P
- **G (`runtime.g`)** — горутина: стек, контекст (`gobuf`), статус.
- **M (`runtime.m`)** — машина = поток ОС. Реально исполняет код. Чтобы исполнять Go-код, M должен владеть P.
- **P (`runtime.p`)** — процессор/контекст: локальный runqueue (256 слотов, кольцевой буфер + `runnext`), кэши аллокатора (`mcache`), таймеры. Число P = `GOMAXPROCS`. P — это «право исполнять Go-код».

Инвариант: **выполнять Go-код может только связка M+P**. Свободные P лежат в `sched.pidle`; свободные M — в `sched.midle`.

```
        ┌─ P0 [runq: G,G,G][runnext]──── M0 (поток ОС) ── исполняет G
GOMAX=  ├─ P1 [runq: G,G   ][runnext]──── M1
   4    ├─ P2 ... 
        └─ P3 ...
   global runq: [G,G,...]   netpoller: epoll/kqueue
```

### Очереди
- **runnext** — слот «следующая» на P, оптимизация локальности (только что разбуженная горутина исполнится почти сразу).
- **локальный runq P** — без блокировок для своего M (LIFO/FIFO нюансы).
- **глобальный runq** — под общим локом `sched.lock`; используется при переполнении локального и периодически проверяется (каждый 61-й тик планирования, чтобы избежать голодания глобальной очереди).

### Work stealing
Когда у M+P пустеет локальная очередь, `findrunnable` ищет работу в таком порядке (упрощённо):
1. локальный runq (и `runnext`);
2. глобальный runq;
3. netpoller (готовые I/O горутины);
4. **steal** — крадёт половину горутин у случайного другого P (рандомизированный обход, чтобы избегать конвоев);
5. если ничего нет — M паркуется (`stopm`).

```go
// runtime.schedule (упрощённо):
//   gp := runqget(p)            // локально
//   if gp == nil { gp, _ = findrunnable() } // глобал, netpoll, steal
//   execute(gp)
```

### Преемпция (preemption)
- **Кооперативная**: точки в прологе функций. `sysmon` или GC выставляет `g.stackguard0 = stackPreempt`; при следующем вызове функции горутина уступает. Проблема: тесный цикл без вызовов функций (`for {}`) не преемптился — до 1.14 мог зависать GC/STW.
- **Асинхронная (Go 1.14+)**: `sysmon` замечает, что горутина бежит дольше ~10 мс, и через `preemptM` посылает потоку **сигнал** (`SIGURG` на Unix). Обработчик сигнала останавливает горутину в безопасной точке (нужны асинхронные safe points и точные регистр-/стек-мапы). Это позволило вытеснять даже `for {}`.

### sysmon
Фоновый поток-монитор без P, работает в цикле с растущим backoff. Делает: запуск отложенной преемпции, форсирование GC, возврат памяти ОС, **retake** P у горутин в долгих syscall, опрос netpoller если его давно не опрашивали.

### Syscalls и handoff P
При входе в блокирующий syscall (`entersyscall`):
1. M отвязывается от P логически (P переходит в `_Psyscall`), но физически M ещё держит P.
2. Если syscall быстрый — после возврата (`exitsyscall`) M пытается снова взять тот же P.
3. Если syscall долгий — `sysmon` через **handoff** отбирает P (`handoffp`) и отдаёт другому M (или будит/создаёт новый), чтобы P не простаивал. Когда M вернётся из syscall без P, его горутина уходит в глобальную очередь, а M паркуется.

Это ключ: блокирующий syscall занимает поток ОС, но **не блокирует P** — параллелизм Go-кода сохраняется. Поэтому сетевой I/O делают неблокирующим (netpoller), а блокирующие вызовы (например, файловый I/O, cgo) могут плодить потоки.

### Netpoller
Сетевые сокеты переводятся в неблокирующий режим и регистрируются в платформенном механизме: **epoll** (Linux), **kqueue** (BSD/macOS), **IOCP** (Windows). Когда горутина делает `conn.Read` и данных нет, она паркуется (`_Gwaiting`), а **поток освобождается** для другой работы. При готовности сокета netpoller (`netpoll`) возвращает список готовых горутин, которые становятся runnable. Так тысячи соединений обслуживаются немногими потоками без thread-per-connection.

### GOMAXPROCS
Число P = максимум одновременно исполняемых Go-горутин. По умолчанию = числу логических CPU.
- Влияет на параллелизм, не на конкурентность.
- В контейнерах долго была проблема: рантайм видел все CPU хоста, а cgroup-квота ограничивала → throttling. Использовали `automaxprocs`. **С Go 1.25 рантайм учитывает cgroup CPU-лимиты** при выборе значения по умолчанию.
- Менять рантайм: `runtime.GOMAXPROCS(n)`.

```go
import "runtime"
old := runtime.GOMAXPROCS(0) // 0 = только прочитать текущее
_ = old
```

## Подводные камни / gotchas
- **`for {}` без точек преемпции** до 1.14 вешал GC; сейчас спасает async preemption, но всё равно сжигает ядро.
- **cgo и блокирующие syscalls** плодят потоки ОС (по одному на залипший вызов). Число M ограничено `sched.maxmcount` (по умолч. 10000) — упор в него = крах.
- **GOMAXPROCS в контейнере** до 1.25 без `automaxprocs` → CPU throttling и рост латентности.
- **`runtime.LockOSThread`** привязывает горутину к конкретному M (нужно для UI-тредов, OpenGL, некоторых syscalls) — этот M нельзя переиспользовать.
- **Ложное ожидание FIFO**: порядок исполнения горутин не гарантирован; `runnext` и стилинг ломают наивные предположения о порядке.
- **Глобальная очередь** проверяется не каждый раз — при экстремальной нагрузке возможна неравномерность, но 61-й тик это сглаживает.

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

**В:** Зачем нужна сущность P, ведь есть G и M?
**О:** P отделяет «право исполнять Go-код» и контекст планирования (локальный runqueue, mcache) от потока ОС. Это даёт лок-фри доступ к локальной очереди, ограничивает параллелизм (= GOMAXPROCS) и позволяет передавать контекст между потоками при блокировках (handoff), не теряя накопленные кэши.

**В:** Как работает work stealing?
**О:** Когда P опустошил локальную очередь, его M в `findrunnable` проверяет глобальную очередь, netpoller, а затем крадёт половину горутин у случайно выбранного другого P. Рандомизация обхода предотвращает конвои и контеншн.

**В:** Чем кооперативная преемпция отличается от асинхронной?
**О:** Кооперативная срабатывает в прологе функций по флагу `stackPreempt` — не работает в тесных циклах без вызовов. Асинхронная (1.14+) использует сигнал SIGURG: sysmon видит долго бегущую горутину и прерывает её в асинхронной safe point, что позволило вытеснять даже `for {}`.

**В:** Что происходит с P при блокирующем системном вызове?
**О:** Горутина и M уходят в syscall, P помечается `_Psyscall`. Если вызов долгий, sysmon делает handoff: отбирает P и отдаёт другому/новому M, чтобы P не простаивал. По возврату M пытается взять P обратно; если не вышло — горутина в глобальную очередь, M паркуется.

**В:** Как Go обслуживает много сетевых соединений малым числом потоков?
**О:** Через netpoller на epoll/kqueue/IOCP. Сокеты неблокирующие; при отсутствии данных горутина паркуется, поток свободен. netpoller возвращает готовые горутины в runnable при событиях готовности. Нет thread-per-connection.

**В:** Что делает sysmon?
**О:** Фоновый поток без P: форсирует преемпцию и GC, делает retake P из долгих syscall, опрашивает netpoller при простое, возвращает память ОС. Работает с экспоненциальным backoff.

**В:** Как GOMAXPROCS соотносится с числом ядер и контейнерами?
**О:** Это число P = максимум параллельно исполняемых горутин, по умолчанию = логическим CPU. В контейнере до Go 1.25 рантайм игнорировал cgroup-квоту, что вызывало throttling; решали через automaxprocs, а с 1.25 рантайм читает cgroup-лимиты сам.

**В:** Что такое `runnext` и зачем он?
**О:** Слот приоритетного запуска на P для только что разбуженной горутины. Улучшает локальность кэша и латентность типичного паттерна «разбудил — почти сразу исполнил» (например, после отправки в канал).

## На что копают на senior+
- Точный порядок `findrunnable` и почему netpoll опрашивается и там, и в sysmon.
- Async safe points: какие инструкции safe, роль точных регистр-мап.
- Handoff vs retake: кто инициирует (`entersyscall`/`sysmon`), `_Psyscall` vs `_Pidle`.
- Влияние LockOSThread, cgo на пул M и `maxmcount`.
- Spinning M: как рантайм балансирует между засыпанием M и быстрым подхватом новой работы (`startm`, `wakep`).
- Изменения дефолта GOMAXPROCS в 1.25 (cgroup-aware) и последствия для latency-критичных сервисов.