context и отмена — бесплатный тест онлайн

Вопрос 1 из 25

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

// Фрагмент для трассировки.
package main
import("context";"time")
func main(){ p,cancel:=context.WithTimeout(context.Background(),10*time.Millisecond); defer cancel(); c,stop:=context.WithTimeout(p,time.Second); defer stop(); <-c.Done() }

Запись `x=7` происходит до отправки, а получение из канала происходит до чтения `x`, поэтому читается 7. Барьер заставляет обе горутины начать критический участок одновременно и делает ошибку воспроизводимее. Таймер разблокирует ветвь примерно после заданного срока, после чего его канал не выдаёт периодические события. После заполнения небольшого буфера производитель ждёт освобождения места вместо бесконечного накопления. Дочерний таймаут в секунду фактически ограничен родительскими 10 миллисекундами.

Вопрос 2 из 25

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import("context";"time")
func main(){ p,cancel:=context.WithTimeout(context.Background(),10*time.Millisecond); defer cancel(); c,stop:=context.WithTimeout(p,time.Second); defer stop(); <-c.Done() }

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

Вопрос 3 из 25

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

// Определите правило Go, которое объясняет результат.
package main
import("context";"time")
func main(){ p,cancel:=context.WithTimeout(context.Background(),10*time.Millisecond); defer cancel(); c,stop:=context.WithTimeout(p,time.Second); defer stop(); <-c.Done() }

Контекст с дедлайном отменяется не позднее указанного времени; дочерний контекст не может пережить более ранний дедлайн родителя. `sync.Once` гарантирует, что переданная функция выполнится не более одного раза; паника всё равно считается выполнением. Правильное исправление устраняет общий доступ или синхронизирует его; копирование переменной цикла может убрать захват одного изменяемого значения. Каждый этап должен прекращать чтение и отправку при отмене, иначе ранний выход потребителя оставляет заблокированные горутины. Блокирующая отправка естественно передаёт давление назад, когда потребитель медленнее производителя.

Вопрос 4 из 25

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

Истечение дедлайна не останавливает код силой: операция должна наблюдать `Done` или использовать API с поддержкой контекста. Копирование `Once` после использования нарушает контракт; повторный `Do` не повторит функцию после паники. Отрицательный счётчик вызывает панику; повторное использование возможно только после завершившегося `Wait` и нового независимого набора. Значения контекста не заменяют проверенную аутентификационную модель и обязательные параметры. Повторное закрытие и отправка после закрытия вызывают панику; получатель не должен закрывать канал только ради остановки отправителя.

Вопрос 5 из 25

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

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

Вопрос 6 из 25

На ревью разбирают тему «Отмена». Как точнее всего описать выполнение фрагмента?

// Фрагмент для трассировки.
package main
import "context"
func main(){ ctx,cancel:=context.WithCancel(context.Background()); done:=make(chan struct{}); go func(){ <-ctx.Done(); close(done) }(); cancel(); <-done }

Работник выбирает между отправкой результата и `ctx.Done`, поэтому не зависает после ухода потребителя. После `cancel()` обе горутины, выбирающие `<-ctx.Done()`, получают сигнал завершения. Цикл `range ch` получит все ранее отправленные значения и завершится после закрытия и опустошения канала. После получения из `a` код присваивает `a=nil`, и дальнейшие итерации выбирают только канал `b`. `go work()` планирует отдельную горутину; `main` не обязан ждать её завершения.

Вопрос 7 из 25

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "context"
func main(){ ctx,cancel:=context.WithCancel(context.Background()); done:=make(chan struct{}); go func(){ <-ctx.Done(); close(done) }(); cancel(); <-done }

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

Вопрос 8 из 25

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

// Определите правило Go, которое объясняет результат.
package main
import "context"
func main(){ ctx,cancel:=context.WithCancel(context.Background()); done:=make(chan struct{}); go func(){ <-ctx.Done(); close(done) }(); cancel(); <-done }

Закрытие сообщает, что новых значений больше не будет; обычно канал закрывает отправитель, который знает о завершении всех отправок. Fan-in объединяет несколько входов в один выход и закрывает его только после завершения всех копирующих горутин. Вызов функции отмены закрывает канал `Done` контекста и распространяется на его потомков. Оператор `go` запускает вызов функции конкурентно и не возвращает её результаты вызывающему выражению. Счётчик `WaitGroup` должен отражать число незавершённых задач; `Done` эквивалентен `Add(-1)`.

Вопрос 9 из 25

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

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

Вопрос 10 из 25

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

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

Вопрос 11 из 25

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

// Фрагмент для трассировки.
package main
import "context"
type key int
const traceKey key = 0
func main(){ ctx:=context.WithValue(context.Background(),traceKey,"abc"); _=ctx.Value(traceKey) }

Горутина зависнет на отправке в небуферизованный канал, потому что никто не выполняет чтение. Цикл `range ch` получит все ранее отправленные значения и завершится после закрытия и опустошения канала. Когда оба буферизированных канала готовы, может выполниться любая из двух ветвей. Идентификатор трассировки можно извлечь по закрытому типизированному ключу без конфликта с ключами других пакетов. Код печатает `busy`, потому что никто не готов принять значение из небуферизованного канала.

Вопрос 12 из 25

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "context"
type key int
const traceKey key = 0
func main(){ ctx:=context.WithValue(context.Background(),traceKey,"abc"); _=ctx.Value(traceKey) }

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

Вопрос 13 из 25

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

// Определите правило Go, которое объясняет результат.
package main
import "context"
type key int
const traceKey key = 0
func main(){ ctx:=context.WithValue(context.Background(),traceKey,"abc"); _=ctx.Value(traceKey) }

Контекст запроса отменяется при разрыве клиента, отмене HTTP/2 или завершении обработчика; дочерняя работа должна его уважать. `sync.Mutex` защищает инвариант общего состояния; копировать мьютекс после начала использования нельзя. Значения контекста предназначены для данных, относящихся к запросу, а не для обязательных параметров функции или изменяемого состояния. Состояние гонки возникает, когда конкурентные доступы к одной памяти включают запись и не упорядочены синхронизацией. Правильное исправление устраняет общий доступ или синхронизирует его; копирование переменной цикла может убрать захват одного изменяемого значения.

Вопрос 14 из 25

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

Строковые ключи разных пакетов могут совпасть; большое значение удерживается до завершения всей цепочки контекста. `time.After` в часто повторяемом цикле создаёт новые таймеры и может удерживать ресурсы до их срабатывания. Вызов `Add` одновременно с `Wait` без заранее определённого протокола может привести к гонке логики и неправильному завершению. Закрытый канал всегда готов к чтению; если не отключить его после `ok=false`, `select` может крутиться на нулевых значениях. Не включать в ошибку секреты, токены, полные строки подключения и лишние персональные данные.

Вопрос 15 из 25

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

Устранение гонки обеспечивает корректность памяти, но ещё не доказывает корректность более высокого бизнес-инварианта. Подробность помогает расследованию, но безопасный контекст должен быть отделён от чувствительных значений. Детерминированный тест полезнее случайной нагрузки, а стресс остаётся дополнением для неизвестных чередований. Свободное планирование повышает загрузку ресурсов, но делает скрытые зависимости по времени особенно опасными. Контекст удобно переносит метаданные через слои, но скрытые бизнес-параметры ухудшают сигнатуры и тестируемость.

Вопрос 16 из 25

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

// Фрагмент для трассировки.
package main
import "context"
func Load(ctx context.Context,id int) error { return ctx.Err() }
func main(){ _=Load(context.Background(),1) }

Запрос к базе с `r.Context()` может прекратиться, если клиент перестал ждать ответ. Обе операции с картой выполняются под одним мьютексом, поэтому конкурентная запись не приводит к гонке. Два `n++` могут потерять обновление и образуют гонку, потому что операция состоит из чтения, вычисления и записи. Функция `produce` может отправлять, но компилятор запретит ей читать из параметра `chan<- int`. Сигнатура `Load(ctx context.Context, id int)` позволяет вызывающему коду управлять временем жизни операции.

Вопрос 17 из 25

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "context"
func Load(ctx context.Context,id int) error { return ctx.Err() }
func main(){ _=Load(context.Background(),1) }

Использовать `default` для намеренного отказа или сбора метрики, а не в горячем цикле без паузы. Добавлять путь отмены через `context` или отдельный канал и гарантировать потребителя каждого результата. Не использовать порядок `case` как приоритет; строить приоритет явной двухступенчатой логикой, если он действительно нужен. Если контекста нет, использовать `context.Background()` или `TODO()`, а не `nil`. Передавать один контекст по конвейеру и закрывать только собственные выходы.

Вопрос 18 из 25

В рабочем примере по теме «Передача контекста» важно отделить гарантию от догадки. Что именно гарантирует Go в этой ситуации?

// Определите правило Go, которое объясняет результат.
package main
import "context"
func Load(ctx context.Context,id int) error { return ctx.Err() }
func main(){ _=Load(context.Background(),1) }

Ссылка на полностью подготовленный объект должна передаваться через синхронизирующее событие; простая запись глобального указателя недостаточна. `sync.Once` гарантирует, что переданная функция выполнится не более одного раза; паника всё равно считается выполнением. Контекст обычно передают первым параметром `ctx context.Context`; его не хранят в структуре без особой причины и не передают `nil`. Контекст запроса отменяется при разрыве клиента, отмене HTTP/2 или завершении обработчика; дочерняя работа должна его уважать. Тип `<-chan T` разрешает только чтение, а `chan<- T` — только отправку; двунаправленный канал можно передать в более узкий параметр.

Вопрос 19 из 25

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

`len(ch)` — моментальный снимок очереди и не годится для принятия конкурентно безопасного решения о следующей операции. Повторное использование контекста после завершения допустимо только для чтения состояния; все производные операции уже будут отменены. Закрытие входного канала из потребителя может паниковать в активном производителе. Цикл с `select` и `default` может занять ядро процессора, постоянно опрашивая состояние. Двойная проверка без атомиков и барьеров может читать частично опубликованное состояние.

Вопрос 20 из 25

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

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

Вопрос 21 из 25

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

// Фрагмент для трассировки.
package sample
import("context";"testing";"time")
func TestDeadline(t *testing.T){ ctx,cancel:=context.WithTimeout(context.Background(),time.Millisecond); defer cancel(); <-ctx.Done(); if ctx.Err()!=context.DeadlineExceeded{t.Fatal(ctx.Err())} }

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

Вопрос 22 из 25

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package sample
import("context";"testing";"time")
func TestDeadline(t *testing.T){ ctx,cancel:=context.WithTimeout(context.Background(),time.Millisecond); defer cancel(); <-ctx.Done(); if ctx.Err()!=context.DeadlineExceeded{t.Fatal(ctx.Err())} }

Хранить примеры компилируемыми, тестировать нулевое значение и конкурентный контракт, если они обещаны. Запускать `-shuffle`, `-count`, `-race`, хранить медленные интеграционные тесты отдельно и анализировать пропуски покрытия по риску. Использовать короткий контролируемый таймаут, синхронизацию запуска и отдельную проверку причины завершения. Запускать серии на стабильной машине, фиксировать входы и отдельно следить за p50/p95/p99, CPU, GC и очередями. Использовать барьеры вместо сна, запускать `-race` и отслеживать число горутин до и после серии операций.

Вопрос 23 из 25

Фрагмент относится к теме «Тестирование и наблюдаемость». Какое утверждение остаётся верным на всех поддерживаемых платформах?

// Определите правило Go, которое объясняет результат.
package sample
import("context";"testing";"time")
func TestDeadline(t *testing.T){ ctx,cancel:=context.WithTimeout(context.Background(),time.Millisecond); defer cancel(); <-ctx.Done(); if ctx.Err()!=context.DeadlineExceeded{t.Fatal(ctx.Err())} }

Конвейер тестируют на пустом входе, ранней отмене, медленном потребителе и закрытии всех выходов; отдельно считают активные работники. Отмену тестируют ожиданием `Done` и проверкой `context.Cause` или `Err`, а в метриках различают таймаут и ручную отмену. Клиент тестируют через `httptest.Server` и подменный `RoundTripper`, проверяя статусы, тело, отмену и число попыток. Таймаут в тесте должен ограничивать зависание, а не заменять причинную синхронизацию и не доказывать порядок планирования. Слой данных тестируют на ошибках начала, запроса, сканирования и коммита; отдельно нужен интеграционный тест реальной базы.

Вопрос 24 из 25

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

Тест, который просто завершается после `recover`, может ложно пройти, если забыта проверка факта паники. Проверка только текста ошибки может сломаться; причины следует распознавать через значения пакета `context` и `errors.Is`. Проверка `len(ch)==0` перед чтением не защищает от изменения состояния другой горутиной. Тест только конечного тела не обнаружит двойной вызов `next` или потерю `Flusher`. Тест только успешного 200 не проверяет закрытие тела, медленные заголовки, разрыв соединения и повтор.

Вопрос 25 из 25

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

Модульный тест быстр, а отдельный `httptest.Server` нужен для маршрутизации, транспорта и завершения соединений. Глубокая readiness точнее отражает способность обслуживать, но слишком дорогая проверка сама может перегрузить зависимости. Макет быстро проверяет ветвление ошибок, а контейнерная база нужна для транзакционной семантики и миграций. Разделение причин полезно для эксплуатации, но чрезмерная детализация меток способна раздуть кардинальность метрик. Наблюдаемость очереди помогает увидеть давление, но вмешательство в протокол ради метрики способно создать новые гонки.