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/ > Модуль: Runtime и память · Уровень: Senior+ ## TL;DR В Go компилятор сам решает, где разместить значение — на стеке горутины или в куче, — опираясь на escape analysis. Стек дешёв: аллокация это сдвиг указателя `SP`, а освобождение — возврат при выходе из функции, без участия GC. Куча дороже: запрос у аллокатора (mcache/mcentral/mheap), последующая работа GC и давление на пропускную способность. Стеки горутин начинаются с 8 КБ (исторически было 2 КБ для системных потоков-`g0` и для горутин в разных версиях), растут не сегментами, а целостным копированием (contiguous stacks) через `morestack`/`copystack`. ## Теория ### Две области памяти и почему они разные | Свойство | Стек | Куча | |---|---|---| | Кто владеет | Каждая горутина имеет свой стек | Общая на весь процесс | | Аллокация | `SP -= size` (один инструкция) | mcache → mcentral → mheap, возможен `mmap` | | Освобождение | Автоматически при `RET` | Через GC (mark & sweep, concurrent) | | Стоимость GC | Нулевая (GC только сканирует, но не освобождает поэлементно) | Полная: сканирование, маркировка, sweep | | Локальность | Отличная (горячий стек в кэше) | Хуже, фрагментация | | Конкурентность | Нет синхронизации (стек приватен) | mcache per-P снимает блокировку на быстром пути | Ключевой принцип Go: **семантика владения определяется компилятором, а не программистом**. Вы пишете `x := &T{}` — и где окажется `T`, решит escape analysis, а не ключевое слово `new`/`&`. Это отличает Go от C/C++, где `malloc`/stack-объявление жёстко задают регион. ### Структура стека горутины Каждая горутина (`g`) имеет поле `stack` с границами `lo`/`hi` и «барьер» `stackguard0`: ```go // runtime/runtime2.go (упрощённо) type stack struct { lo uintptr // нижняя граница (стек растёт вниз, к lo) hi uintptr // верхняя граница } type g struct { stack stack // [lo, hi) stackguard0 uintptr // проверяется в прологе функции; обычно lo + _StackGuard stackguard1 uintptr // то же для g0/системного стека // ... } ``` Стек растёт **вниз** (от `hi` к `lo`). `stackguard0` — это «красная зона»: если `SP` опускается ниже неё, нужно увеличить стек. ### Stack guard и пролог функции (morestack check) Компилятор вставляет в **пролог почти каждой функции** проверку: хватит ли стека под фрейм. Это и есть «morestack check». ```go func work() { var buf [4096]byte // большой фрейм _ = buf } ``` Дизассемблер покажет нечто такое (amd64): ```bash go build -gcflags="-S" ./... 2>&1 | head -60 ``` ```asm TEXT main.work(SB) MOVQ (TLS), CX ; получить *g из TLS LEAQ -4072(SP), AX ; AX = SP - размер_фрейма CMPQ AX, 16(CX) ; сравнить с g.stackguard0 JLS morestack_call ; если AX <= stackguard0 → нужно больше стека ; ... тело функции ... RET morestack_call: CALL runtime.morestack_noctxt(SB) JMP main.work(SB) ; повторить пролог после роста ``` **Оптимизация: NOSPLIT.** Маленькие листовые функции, чей фрейм гарантированно влезает в «запас» (`_StackSmall`, ~128 байт), помечаются `nosplit` и **не получают пролог-проверку**. Это убирает накладные расходы на горячем пути. Слишком глубокая цепочка `nosplit`-функций может переполнить запас — компилятор тогда выдаёт ошибку `nosplit stack overflow`. ### Рост стека: contiguous stacks и copystack Когда проверка срабатывает, `runtime.morestack` запускает рост стека. Современный Go (с 1.3) использует **непрерывные (contiguous) стеки**: выделяется новый блок **вдвое больше**, и весь старый стек **копируется** в него. ```go // концептуально, runtime/stack.go: copystack func copystack(gp *g, newsize uintptr) { old := gp.stack new := stackalloc(uint32(newsize)) // новый блок, обычно 2x // 1. скопировать байты [old.lo, SP] → новый стек memmove(...) // 2. КОРРЕКТИРОВКА УКАЗАТЕЛЕЙ: все указатели, ведущие // внутрь старого стека, сдвигаются на (new.lo - old.lo) adjustpointers(...) // фреймы, sudog, defer, panic — всё патчится gp.stack = new stackfree(old) } ``` Самый тонкий момент — **adjustpointers**: после переезда стека все указатели на стек становятся невалидными, поэтому runtime обходит фреймы (по stack maps, которые генерирует компилятор), defer-цепочки, panic-записи, sudog в каналах — и переписывает каждый указатель. Именно из-за необходимости точно знать, что является указателем, Go требует **точного (precise) GC** и stack maps. Уменьшение тоже бывает: при GC, если стек используется меньше чем на 1/4, его могут «сжать» (shrinkstack) до половины. ### Сегментные стеки — историческая справка До Go 1.3 использовались **segmented stacks** («split stacks»): при нехватке выделялся новый сегмент, связанный с предыдущим. Проблема — **«hot split»**: если функция в цикле то выделяет, то освобождает сегмент на границе, каждый вызов платит за `mmap`/`munmap` и переключение. Это давало катастрофическую деградацию на ровном месте. | | Segmented (≤1.2) | Contiguous (≥1.3) | |---|---|---| | Структура | Список сегментов | Один непрерывный блок | | Рост | Новый сегмент | Удвоение + копирование | | Патология | Hot split | Разовая дорогая копия с amortized O(1) | | Указатели на стек | Валидны после роста | Требуют корректировки | Переход на непрерывные стеки потребовал точных stack maps, но избавил от hot split: удвоение даёт амортизированную стоимость O(1) на байт. ### Начальные размеры стека ```go // runtime/stack.go const ( _StackMin = 2048 // минимальный системный, исторический ориентир ) ``` - Горутина стартует с **8 КБ** полезного стека (`_FixedStack` = 2 КБ + системные нужды; фактический стартовый размер несколько раз менялся между версиями — в коде это `StackMin`/`_FixedStack`, итог ~8 КБ доступных пользователю в современных версиях). - `g0` (системный стек планировщика) и стеки сигналов больше и фиксированы. - Максимальный размер стека ограничен `maxstacksize` (1 ГБ на 64-бит по умолчанию); превышение → `fatal error: stack overflow` (например, бесконечная рекурсия). ```go // бесконечная рекурсия → стек растёт удвоением до лимита → fatal func boom(n int) int { return boom(n + 1) } ``` ### Стоимость аллокации: стек vs куча ```go // Версия A: ничего не убегает — buf на стеке func sumStack() int { var buf [64]int // аллокация = коррекция SP, бесплатно for i := range buf { buf[i] = i } s := 0 for _, v := range buf { s += v } return s } // Версия B: убегает в кучу func sumHeap() *[64]int { buf := new([64]int) // escape → mallocgc → GC будет это собирать return buf } ``` Бенчмарк наглядно показывает разницу через `allocs/op`: ```bash go test -bench=. -benchmem ``` ``` BenchmarkSumStack-8 200000000 5.1 ns/op 0 B/op 0 allocs/op BenchmarkSumHeap-8 30000000 42 ns/op 512 B/op 1 allocs/op ``` Куча дороже по трём осям: (1) сам путь аллокатора, (2) давление на GC (больше работы по сканированию/маркировке, чаще циклы), (3) косвенно — хуже локальность кэша. ### Spilling (выгрузка регистров в стек) С Go 1.17 действует **register-based ABI** (ABIInternal): аргументы и возвраты передаются через регистры, а не через стек. Но регистров конечное число, и компилятор вынужден временно сохранять значения в стек — это **spilling**. ```go func f(a, b, c, d, e, f, g, h, i, j int) int { // первые ~9 целых уходят в регистры (amd64), // дальше и при нехватке — spill в стек-слоты фрейма return a + b + c + d + e + f + g + h + i + j } ``` Spill-слоты — это часть фрейма функции на стеке; они нужны при нехватке регистров, перед вызовами (caller-saved регистры) и для значений, чей адрес берётся. Spilling **не** означает escape в кучу — это по-прежнему стек, просто register pressure. ## Подводные камни / gotchas - **«Я взял &, значит куча» — миф.** `&x` может остаться на стеке, если адрес не покидает функцию. И наоборот, значение без `&` может убежать (через интерфейс). - **Большие фреймы тихо едут в кучу.** Объекты больше порога (исторически ~64 КБ / `maxstackobject`) escape-analysis принудительно отправляет в кучу, даже если логически они локальны. Большой `[N]byte` на стеке — частая причина внезапных аллокаций. - **Глубокая рекурсия = много copystack.** Если рекурсия растёт линейно, стек удваивается логарифмическое число раз, но каждое удвоение копирует всё — для очень глубоких стеков это заметно. Хвостовой рекурсии в Go нет. - **Указатель на локальную переменную безопасен** (в отличие от C): если он убегает, компилятор переместит переменную в кучу. Dangling pointer на стек невозможен в безопасном Go. - **`//go:nosplit` руками — опасно.** Без пролога функция не может вырасти; цепочка nosplit может переполнить запас стека и привести к порче памяти. Использовать только в runtime/низкоуровневом коде. - **Миллион горутин ≠ дёшево по памяти.** 1M горутин по 8 КБ = 8 ГБ только под стеки, даже если они спят. Стеки сжимаются, но не до нуля. ## Вопросы на собеседовании **В:** Кто и когда решает, попадёт ли переменная на стек или в кучу? **О:** Компилятор на этапе компиляции, через escape analysis. Решение статическое и консервативное: если компилятор не может доказать, что значение не переживёт функцию, оно отправляется в кучу. Ключевые слова `new`/`&` на это решение напрямую не влияют — важно, «убегает» ли значение (возврат указателя, попадание в интерфейс/канал/замыкание, слишком большой размер). **В:** Как растёт стек горутины и чем это отличается от Go до 1.3? **О:** Сейчас — contiguous stacks: при нехватке выделяется новый блок вдвое больше, старый целиком копируется (`copystack`), и все указатели на стек корректируются по stack maps. До 1.3 были segmented stacks: добавлялся новый сегмент. Проблема старого подхода — «hot split»: цикл на границе сегмента вызывал постоянные alloc/free сегмента и резкую деградацию. Непрерывные стеки дают амортизированную O(1) стоимость. **В:** Что такое morestack check и где он находится? **О:** Это проверка в прологе функции: сравнивается `SP - размер_фрейма` с `g.stackguard0`. Если стека не хватает, вызывается `runtime.morestack`, который растит стек и повторяет пролог. Листовые маленькие функции помечаются nosplit и не несут этой проверки. **В:** Почему рост стека требует корректировки указателей, а malloc в куче — нет? **О:** Потому что стек физически переезжает на новый адрес. Все указатели, ведущие внутрь старого стека (из фреймов, defer, panic, sudog), становятся невалидными и должны быть сдвинуты на разницу адресов. Куча не двигается (Go не использует moving/compacting GC для обычных объектов), поэтому указатели стабильны. **В:** Чем именно аллокация на стеке дешевле кучи? **О:** Стек: одна арифметическая операция над `SP`, освобождение бесплатно при `RET`, нет работы для GC, отличная локальность кэша, нет синхронизации (стек приватен горутине). Куча: путь через mcache/mcentral/mheap (возможен `mmap`), последующая работа GC по сканированию/маркировке/sweep, давление на пропускную способность, фрагментация. **В:** Что произойдёт при бесконечной рекурсии? **О:** Стек будет расти удвоением, пока не упрётся в `maxstacksize` (по умолчанию 1 ГБ на 64-бит), после чего runtime аварийно завершит процесс с `fatal error: stack overflow`. Это не паника и не восстанавливается через `recover`. **В:** Что такое spilling и связан ли он с escape в кучу? **О:** Spilling — это временное сохранение значений из регистров в стек-слоты фрейма, когда регистров не хватает (register pressure), перед вызовами или когда берётся адрес значения. Это происходит на стеке и не связано с кучей. С Go 1.17 ABI регистровый, поэтому spilling стал более заметной темой при чтении ассемблера. **В:** Можно ли в безопасном Go получить dangling pointer на освобождённый стек? **О:** Нет. Если адрес локальной переменной убегает за пределы функции, escape analysis переместит саму переменную в кучу, и указатель останется валидным. Поэтому возвращать `&local` из функции в Go безопасно — в отличие от C. ## На что копают на senior+ - Понимание **stack maps** и связи с precise GC: почему точная информация о том, где на стеке лежат указатели, обязательна для contiguous stacks и для маркировки. - Детали `copystack`/`adjustframe`: что именно корректируется (фреймы по PC→stackmap, defer-записи, sudog в каналах, выполняющийся panic). - `shrinkstack` и его взаимодействие с GC: когда и почему стек уменьшается, почему это делается в safe point. - ABI 0 vs ABIInternal (регистровый ABI с 1.17), wrapper-функции на границе, влияние на spilling и на чтение `-S` вывода. - Влияние числа горутин на RSS: математика «N × stacksize», почему профиль `goroutine` и `pprof` важны для диагностики «утечки горутин» как памяти. - Тонкости nosplit: `//go:nosplit`, `_StackSmall`/`_StackBig`, как runtime гарантирует запас для системных вызовов и обработчиков сигналов (stack guard как «red zone»).