Горутины — бесплатный тест онлайн

Вопрос 1 из 25

Фрагмент относится к теме «Запуск». Что именно произойдёт при выполнении показанного фрагмента?

// Фрагмент для трассировки.
package main
func work(int){}
func main(){ n:=1; go work(n); n=2 }

Каждая горутина получает собственное значение `v`, поэтому не читает одну меняющуюся переменную цикла. После `cancel()` обе горутины, выбирающие `<-ctx.Done()`, получают сигнал завершения. Каждое значение получает один из работников, а порядок результатов не обязан совпадать с входом. Отдельная горутина ждёт `WaitGroup` и закрывает общий выход, когда все входы исчерпаны. `go work()` планирует отдельную горутину; `main` не обязан ждать её завершения.

Вопрос 2 из 25

На ревью разбирают тему «Запуск». Как исправить основной риск без ненужной перестройки решения?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
func work(int){}
func main(){ n:=1; go work(n); n=2 }

Для инициализации, способной вернуть ошибку, хранить результат рядом и продумать, нужен ли повтор после сбоя. Передавать результаты через канал, синхронизацию или общий объект с защитой, а ошибки делать частью явного протокола. Передавать контекст вниз и не запускать после ответа работу, которая должна пережить запрос, без отдельного владельца. Выбирать срок на границе запроса и передавать его вниз, а не создавать независимые длинные таймауты в каждом слое. Использовать типизированные атомики для независимых счётчиков и флагов; сложное состояние защищать мьютексом или передавать сообщениями.

Вопрос 3 из 25

В разделе «Запуск» показан конкретный случай. Какой принцип позволяет вывести ответ без запуска программы?

// Определите правило Go, которое объясняет результат.
package main
func work(int){}
func main(){ n:=1; go work(n); n=2 }

Вероятность проявления конкурентного дефекта повышают повтор, параллельная нагрузка и управляемые точки синхронизации, а не случайные большие `Sleep`. Оператор `go` запускает вызов функции конкурентно и не возвращает её результаты вызывающему выражению. Детектор гонок инструментирует доступы к памяти и сообщает конфликтующие стеки, если гонка проявилась во время запуска. Состояние гонки возникает, когда конкурентные доступы к одной памяти включают запись и не упорядочены синхронизацией. Вызов функции отмены закрывает канал `Done` контекста и распространяется на его потомков.

Вопрос 4 из 25

Команда проверяет решение по теме «Запуск». Какой контрпример разрушит слишком широкое толкование правила?

Закрытие выхода одной копирующей горутиной приведёт к панике у остальных отправителей. Аргументы вызова горутины вычисляются до запуска самой функции. Копирование `Once` после использования нарушает контракт; повторный `Do` не повторит функцию после паники. Разные элементы одного среза можно менять конкурентно при отсутствии изменения заголовка и других общих инвариантов, но это надо доказать. `len(ch)` — моментальный снимок очереди и не годится для принятия конкурентно безопасного решения о следующей операции.

Вопрос 5 из 25

Перед публикацией кода по теме «Запуск» нужно уточнить контракт. Что важно учесть помимо формальной корректности?

Отмена быстро освобождает ресурсы, но частично обработанные элементы требуют отдельного решения о повторе. Общий дедлайн ограничивает суммарное время, но слишком жёсткий бюджет без метрик превращает нормальные всплески в ошибки. Мьютекс прост для сложного инварианта, но длительная работа под блокировкой увеличивает задержки всех участников. Приём из нескольких источников гибок, но явный учёт жизненного цикла каждого входа важнее компактности цикла. Горутина дёшева, но каждая запущенная работа всё равно требует владельца, пути завершения и учёта ошибки.

Вопрос 6 из 25

На ревью разбирают тему «Планирование». Какое описание результата совпадает с правилами Go?

// Фрагмент для трассировки.
package main
import "fmt"
func main(){ go fmt.Print("A"); go fmt.Print("B"); select{} }

Код может напечатать `A B` или `B A`; язык не обещает, какая горутина первой получит процессор. Код печатает `busy`, потому что никто не готов принять значение из небуферизованного канала. После `cancel()` обе горутины, выбирающие `<-ctx.Done()`, получают сигнал завершения. Отдельная горутина ждёт `WaitGroup` и закрывает общий выход, когда все входы исчерпаны. Каждая горутина получает собственное значение `v`, поэтому не читает одну меняющуюся переменную цикла.

Вопрос 7 из 25

В разделе «Планирование» показан конкретный случай. Какая правка устраняет причину, а не маскирует её проявление?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "fmt"
func main(){ go fmt.Print("A"); go fmt.Print("B"); select{} }

Создавать объект локально, завершать инициализацию и только затем публиковать через канал, мьютекс, `Once` или атомарный указатель. Использовать типизированные атомики для независимых счётчиков и флагов; сложное состояние защищать мьютексом или передавать сообщениями. Использовать каналы, мьютексы, атомики или другие документированные примитивы вместо надежды на планирование. Выражать требуемый порядок каналом, мьютексом, `WaitGroup` или другим явным отношением синхронизации. Сформулировать инвариант, выбрать владельца состояния и закрепить порядок мьютексов по идентификатору.

Вопрос 8 из 25

Команда проверяет решение по теме «Планирование». Что именно гарантирует Go в этой ситуации?

// Определите правило Go, которое объясняет результат.
package main
import "fmt"
func main(){ go fmt.Print("A"); go fmt.Print("B"); select{} }

Вероятность проявления конкурентного дефекта повышают повтор, параллельная нагрузка и управляемые точки синхронизации, а не случайные большие `Sleep`. `select` выбирает одну готовую операцию; если готово несколько, выбор псевдослучаен и порядок ветвей приоритета не задаёт. `sync.Once` гарантирует, что переданная функция выполнится не более одного раза; паника всё равно считается выполнением. Порядок выполнения готовых горутин не определён; корректность нельзя строить на `Sleep` или предполагаемой очередности. Корректная синхронизация создаёт отношение happens-before, после которого записи одной горутины видимы другой согласно модели памяти.

Вопрос 9 из 25

Перед публикацией кода по теме «Планирование» нужно уточнить контракт. Что нельзя автоматически переносить на похожий код?

Увеличение работников не помогает последовательной части и может перегрузить внешнюю систему. Последовательность из двух атомарных чтений может увидеть сочетание значений, которое никогда не существовало как единый снимок. Даже при `GOMAXPROCS(1)` горутины могут чередоваться, поэтому это не превращает программу в последовательную. Нельзя безопасно повысить `RLock` до `Lock` без освобождения: такая схема может взаимно заблокироваться. Закрытие выхода одной копирующей горутиной приведёт к панике у остальных отправителей.

Вопрос 10 из 25

В рабочем примере по теме «Планирование» важно отделить гарантию от догадки. Как оценить этот подход для производственного кода?

`select` естественно объединяет события, но сложная приоритизация и изменение состояния каналов требуют особенно ясного протокола. Связь с клиентом освобождает ресурсы раньше, но фоновые задания требуют отдельной очереди и гарантий доставки. Совместная отмена упрощает остановку дерева работ, но операции должны регулярно проверять сигнал и корректно освобождать ресурсы. Узкий тип улучшает API без стоимости выполнения, но сам не решает владение закрытием. Свободное планирование повышает загрузку ресурсов, но делает скрытые зависимости по времени особенно опасными.

Вопрос 11 из 25

В разделе «Утечки горутин» показан конкретный случай. Какой итог можно предсказать без пробного запуска?

// Фрагмент для трассировки.
package main
func main(){ ch:=make(chan int); go func(){ ch<-1 }(); _=ch }

Работник выбирает между отправкой результата и `ctx.Done`, поэтому не зависает после ухода потребителя. Две отправки в канал ёмкостью 2 завершаются сразу, а третья без чтения заблокируется. Каждая горутина получает собственное значение `v`, поэтому не читает одну меняющуюся переменную цикла. Запись `x=7` происходит до отправки, а получение из канала происходит до чтения `x`, поэтому читается 7. Горутина зависнет на отправке в небуферизованный канал, потому что никто не выполняет чтение.

Вопрос 12 из 25

Команда проверяет решение по теме «Утечки горутин». Как изменить решение, не ломая его исходную задачу?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
func main(){ ch:=make(chan int); go func(){ ch<-1 }(); _=ch }

Назначить единственного владельца закрытия и учитывать отмену при каждой отправке. Закрывать канал ровно в одном месте после окончания всех отправителей, часто после отдельного `WaitGroup`. Добавлять путь отмены через `context` или отдельный канал и гарантировать потребителя каждого результата. Для инициализации, способной вернуть ошибку, хранить результат рядом и продумать, нужен ли повтор после сбоя. Выбирать размер буфера по измеренному всплеску и скорости потребителя, а не использовать большое число как лечение зависания.

Вопрос 13 из 25

Перед публикацией кода по теме «Утечки горутин» нужно уточнить контракт. Какое утверждение остаётся верным на всех поддерживаемых платформах?

// Определите правило Go, которое объясняет результат.
package main
func main(){ ch:=make(chan int); go func(){ ch<-1 }(); _=ch }

Блокирующая отправка естественно передаёт давление назад, когда потребитель медленнее производителя. Тип `<-chan T` разрешает только чтение, а `chan<- T` — только отправку; двунаправленный канал можно передать в более узкий параметр. Буферизированный канал принимает до `cap` значений без одновременного получателя; после заполнения отправка блокируется. Горутина, навсегда заблокированная на отправке, чтении или ожидании, остаётся жить и удерживать связанные данные. Закрытие сообщает, что новых значений больше не будет; обычно канал закрывает отправитель, который знает о завершении всех отправок.

Вопрос 14 из 25

В рабочем примере по теме «Утечки горутин» важно отделить гарантию от догадки. Какое условие нельзя считать выполненным по умолчанию?

`time.After` в часто повторяемом цикле создаёт новые таймеры и может удерживать ресурсы до их срабатывания. Закрытый канал всегда готов к чтению; если не отключить его после `ok=false`, `select` может крутиться на нулевых значениях. Копирование `Once` после использования нарушает контракт; повторный `Do` не повторит функцию после паники. Изменение `GOMAXPROCS` может менять частоту проявления, но отсутствие сбоя при одном значении ничего не доказывает. Утечка может не проявиться в коротком тесте, но накопиться под повторяющейся нагрузкой.

Вопрос 15 из 25

Фрагмент относится к теме «Утечки горутин». Какой вариант честно называет и преимущество, и издержку?

Общий дедлайн ограничивает суммарное время, но слишком жёсткий бюджет без метрик превращает нормальные всплески в ошибки. Мьютекс прост для сложного инварианта, но длительная работа под блокировкой увеличивает задержки всех участников. Атомик уменьшает блокировки для простой величины, но алгоритм становится труднее доказать и сопровождать. Блокировка сохраняет данные, но может связать отказ потребителя со всем входным трафиком. Буфер иногда сглаживает всплеск, но не заменяет протокол завершения и лишь откладывает блокировку.

Вопрос 16 из 25

Команда проверяет решение по теме «Завершение». Как точнее всего описать выполнение фрагмента?

// Фрагмент для трассировки.
package main
import "sync"
func main(){ var wg sync.WaitGroup; wg.Add(2); for i:=0;i<2;i++{ go func(){ defer wg.Done() }() }; wg.Wait() }

После получения из `a` код присваивает `a=nil`, и дальнейшие итерации выбирают только канал `b`. Работник выбирает между отправкой результата и `ctx.Done`, поэтому не зависает после ухода потребителя. Обе операции с картой выполняются под одним мьютексом, поэтому конкурентная запись не приводит к гонке. Из десяти конкурентных вызовов `once.Do(init)` тело `init` будет запущено максимум один раз. `Wait` вернётся только после двух вызовов `Done`, поэтому `main` дождётся обеих функций.

Вопрос 17 из 25

Перед публикацией кода по теме «Завершение» нужно уточнить контракт. Какая доработка делает поведение явным для вызывающего кода?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "sync"
func main(){ var wg sync.WaitGroup; wg.Add(2); for i:=0;i<2;i++{ go func(){ defer wg.Done() }() }; wg.Wait() }

Передавать контекст вниз и не запускать после ответа работу, которая должна пережить запрос, без отдельного владельца. Использовать `default` для намеренного отказа или сбора метрики, а не в горячем цикле без паузы. Вызывать `Add` до запуска горутины, а `Done` ставить через `defer` в самом начале задачи. Всегда вызывать возвращённую `cancel`, даже если операция завершилась раньше, чтобы освободить связанные ресурсы. Предпочитать передачу аргумента в замыкание и владение данными одной горутиной, где это упрощает протокол.

Вопрос 18 из 25

В рабочем примере по теме «Завершение» важно отделить гарантию от догадки. Какое правило достаточно применить для проверки ответа?

// Определите правило Go, которое объясняет результат.
package main
import "sync"
func main(){ var wg sync.WaitGroup; wg.Add(2); for i:=0;i<2;i++{ go func(){ defer wg.Done() }() }; wg.Wait() }

Владелец запускаемых горутин должен знать, когда они закончены; `sync.WaitGroup` подходит для ожидания известного набора задач. `time.NewTimer` создаёт одно событие, а `time.NewTicker` — повторяющиеся; ресурсы долгоживущих таймеров следует останавливать, когда они больше не нужны. `sync.Mutex` защищает инвариант общего состояния; копировать мьютекс после начала использования нельзя. Счётчик `WaitGroup` должен отражать число незавершённых задач; `Done` эквивалентен `Add(-1)`. Каждый этап должен прекращать чтение и отправку при отмене, иначе ранний выход потребителя оставляет заблокированные горутины.

Вопрос 19 из 25

Фрагмент относится к теме «Завершение». Какой граничный случай нужно проверить отдельно?

Строковые ключи разных пакетов могут совпасть; большое значение удерживается до завершения всей цепочки контекста. Одного реального времени «запись случилась раньше» недостаточно без синхронизирующего события. Закрытие выхода одной копирующей горутиной приведёт к панике у остальных отправителей. Вызов `Add` одновременно с `Wait` без заранее определённого протокола может привести к гонке логики и неправильному завершению. Повторное использование контекста после завершения допустимо только для чтения состояния; все производные операции уже будут отменены.

Вопрос 20 из 25

На ревью разбирают тему «Завершение». Какой инженерный компромисс здесь действительно существует?

Закрытие удобно как широковещательный сигнал завершения, но не несёт причину ошибки без отдельного значения или контекста. Ожидание всех задач даёт чистое завершение, но долгоживущие работники дополнительно нуждаются в отмене. Больше работников повышает пропускную способность до насыщения, но увеличивает память и число активных запросов. Отмена быстро освобождает ресурсы, но частично обработанные элементы требуют отдельного решения о повторе. `time.After` очень читаем для разового ожидания, а управляемый `Timer` лучше при отмене и повторном использовании.

Вопрос 21 из 25

Перед публикацией кода по теме «Тестирование и наблюдаемость» нужно уточнить контракт в тесте «Горутины». Что именно произойдёт при выполнении показанного фрагмента?

// Фрагмент для трассировки.
package sample
import("testing";"time")
func TestWork(t *testing.T){ done:=make(chan struct{}); go func(){ close(done) }(); select{case <-done: case <-time.After(time.Second): t.Fatal("timeout")} }

Тест отменяет контекст после первого результата и убеждается, что выход закрывается за ограниченное время. Тест проверяет и значение, и `ok`, поэтому не путает нулевой элемент с закрытым каналом. Тест использует канал результата и таймаут, поэтому различает успешное завершение и зависание. Тест считается успешным только если вызов действительно вызвал ожидаемую панику; отсутствие паники — отдельная ошибка теста. После истечения таймаута `ctx.Err()` возвращает `context.DeadlineExceeded`.

Вопрос 22 из 25

В рабочем примере по теме «Тестирование и наблюдаемость» важно отделить гарантию от догадки в тесте «Горутины». Как исправить основной риск без ненужной перестройки решения?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package sample
import("testing";"time")
func TestWork(t *testing.T){ done:=make(chan struct{}); go func(){ close(done) }(); select{case <-done: case <-time.After(time.Second): t.Fatal("timeout")} }

Запускать серии на стабильной машине, фиксировать входы и отдельно следить за p50/p95/p99, CPU, GC и очередями. Собирать статистику `db.Stats()`, время ожидания пула и длительность запросов без записи значений параметров-секретов. Запускать тесты многократно, с `-race`, и собирать профили горутин при подозрении на утечку. Добавлять профили блокировок и мьютексов при задержках, но сначала доказать корректность инварианта. Запускать `-race` в CI и на интеграционных сценариях, увеличивать охват конкурентных ветвей и сохранять отчёты.

Вопрос 23 из 25

Фрагмент относится к теме «Тестирование и наблюдаемость» в тесте «Горутины». Какой принцип позволяет вывести ответ без запуска программы?

// Определите правило Go, которое объясняет результат.
package sample
import("testing";"time")
func TestWork(t *testing.T){ done:=make(chan struct{}); go func(){ close(done) }(); select{case <-done: case <-time.After(time.Second): t.Fatal("timeout")} }

Слой данных тестируют на ошибках начала, запроса, сканирования и коммита; отдельно нужен интеграционный тест реальной базы. Таймаут в тесте должен ограничивать зависание, а не заменять причинную синхронизацию и не доказывать порядок планирования. Протокол канала тестируют на обычном пути, закрытии, отмене и отсутствии потребителя; зависание ограничивают таймаутом теста. Обобщённый алгоритм тестируют представителями разных ветвей ограничения и именованными типами, а не только `int`. Тест конкурентного кода должен ждать конкретное событие и иметь ограниченный срок, а не надеяться на случайную задержку.

Вопрос 24 из 25

На ревью разбирают тему «Тестирование и наблюдаемость» в тесте «Горутины». Какой контрпример разрушит слишком широкое толкование правила?

Тест только с `bytes.Buffer` слишком дружелюбен и может не выявить ошибочную обработку частичного чтения. Чистый отчёт не доказывает отсутствие непокрытой гонки; найденный отчёт нельзя «лечить» случайным `Sleep`. Сравнение общего `runtime.NumGoroutine` без допуска нестабильно из-за фоновых горутин среды. Тест только успешного 200 не проверяет закрытие тела, медленные заголовки, разрыв соединения и повтор. Слишком короткий таймаут делает тест нестабильным на медленной машине, а отсутствие таймаута способно повесить весь набор.

Вопрос 25 из 25

В разделе «Тестирование и наблюдаемость» показан конкретный случай в тесте «Горутины». Что важно учесть помимо формальной корректности?

Дополнительные метрики ожидания помогают найти конкуренцию, но сами измерения не заменяют корректный протокол блокировок. Наблюдаемость очереди помогает увидеть давление, но вмешательство в протокол ради метрики способно создать новые гонки. Логи паники нужны для расследования, но чувствительные данные из аргументов и стека следует фильтровать. Макет быстро проверяет ветвление ошибок, а контейнерная база нужна для транзакционной семантики и миграций. Детерминированная синхронизация лучше сна, но эксплуатационные метрики числа горутин всё равно нужны для накопительных утечек.