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

Вопрос 1 из 25

На ревью разбирают тему «Выбор операций select». Что гарантированно произойдёт в показанной последовательности операций?

// Фрагмент для трассировки.
package main
func main(){ a:=make(chan int,1); b:=make(chan int,1); a<-1; b<-2; select{case <-a: case <-b:} }

Когда оба буферизированных канала готовы, может выполниться любая из двух ветвей. Запрос к базе с `r.Context()` может прекратиться, если клиент перестал ждать ответ. Отдельная горутина ждёт `WaitGroup` и закрывает общий выход, когда все входы исчерпаны. Горутина зависнет на отправке в небуферизованный канал, потому что никто не выполняет чтение. Два вызова `Get` могут выполняться одновременно, пока нет писателя.

Вопрос 2 из 25

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

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

Сформулировать инвариант, выбрать владельца состояния и закрепить порядок мьютексов по идентификатору. Выражать требуемый порядок каналом, мьютексом, `WaitGroup` или другим явным отношением синхронизации. Выбирать размер буфера по измеренному всплеску и скорости потребителя, а не использовать большое число как лечение зависания. Если контекста нет, использовать `context.Background()` или `TODO()`, а не `nil`. Не использовать порядок `case` как приоритет; строить приоритет явной двухступенчатой логикой, если он действительно нужен.

Вопрос 3 из 25

Команда проверяет решение по теме «Выбор операций select». Какой принцип языка объясняет результат полностью?

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

Fan-in объединяет несколько входов в один выход и закрывает его только после завершения всех копирующих горутин. Блокировка должна покрывать весь инвариант и использовать единый порядок захвата нескольких мьютексов. `select` выбирает одну готовую операцию; если готово несколько, выбор псевдослучаен и порядок ветвей приоритета не задаёт. Пакет `sync/atomic` обеспечивает атомарность отдельных операций и заданный порядок памяти, но не объединяет несколько полей в общий инвариант. Порядок выполнения готовых горутин не определён; корректность нельзя строить на `Sleep` или предполагаемой очередности.

Вопрос 4 из 25

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

Повторное использование контекста после завершения допустимо только для чтения состояния; все производные операции уже будут отменены. Отрицательный счётчик вызывает панику; повторное использование возможно только после завершившегося `Wait` и нового независимого набора. Пустой `select{}` блокируется навсегда, пока процесс не завершится извне. Строковые ключи разных пакетов могут совпасть; большое значение удерживается до завершения всей цепочки контекста. `defer mu.Unlock()` безопасен для ранних возвратов, но нельзя разблокировать мьютекс, который текущий путь не блокировал.

Вопрос 5 из 25

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

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

Вопрос 6 из 25

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

// Фрагмент для трассировки.
package main
import "fmt"
func main(){ ch:=make(chan int); select{case ch<-1: fmt.Println("sent"); default: fmt.Println("busy")} }

Цикл `range ch` получит все ранее отправленные значения и завершится после закрытия и опустошения канала. Запись `x=7` происходит до отправки, а получение из канала происходит до чтения `x`, поэтому читается 7. Код печатает `busy`, потому что никто не готов принять значение из небуферизованного канала. Два `n++` могут потерять обновление и образуют гонку, потому что операция состоит из чтения, вычисления и записи. Каждая горутина получает собственное значение `v`, поэтому не читает одну меняющуюся переменную цикла.

Вопрос 7 из 25

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "fmt"
func main(){ ch:=make(chan int); select{case ch<-1: fmt.Println("sent"); default: fmt.Println("busy")} }

Если контекста нет, использовать `context.Background()` или `TODO()`, а не `nil`. Использовать типизированные атомики для независимых счётчиков и флагов; сложное состояние защищать мьютексом или передавать сообщениями. Выбирать размер буфера по измеренному всплеску и скорости потребителя, а не использовать большое число как лечение зависания. Использовать `default` для намеренного отказа или сбора метрики, а не в горячем цикле без паузы. Использовать `RWMutex` после измерения и только когда чтения заметно преобладают и достаточно длительны.

Вопрос 8 из 25

Перед публикацией кода по теме «Неблокирующая ветвь default» нужно уточнить контракт. Какое правило Go непосредственно объясняет поведение фрагмента?

// Определите правило Go, которое объясняет результат.
package main
import "fmt"
func main(){ ch:=make(chan int); select{case ch<-1: fmt.Println("sent"); default: fmt.Println("busy")} }

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

Вопрос 9 из 25

В рабочем примере по теме «Неблокирующая ветвь default» важно отделить гарантию от догадки. Где заканчивается гарантия показанного приёма?

Повторное использование контекста после завершения допустимо только для чтения состояния; все производные операции уже будут отменены. Изменение `GOMAXPROCS` может менять частоту проявления, но отсутствие сбоя при одном значении ничего не доказывает. Вызов `Add` одновременно с `Wait` без заранее определённого протокола может привести к гонке логики и неправильному завершению. Цикл с `select` и `default` может занять ядро процессора, постоянно опрашивая состояние. Защита каждого поля отдельным мьютексом не сохраняет сумму, если операция должна менять поля атомарно вместе.

Вопрос 10 из 25

Фрагмент относится к теме «Неблокирующая ветвь default». Когда этот приём помогает, а когда начинает мешать?

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

Вопрос 11 из 25

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

// Фрагмент для трассировки.
package main
import "time"
func main(){ timer:=time.NewTimer(time.Millisecond); defer timer.Stop(); <-timer.C }

Таймер разблокирует ветвь примерно после заданного срока, после чего его канал не выдаёт периодические события. Две отправки в канал ёмкостью 2 завершаются сразу, а третья без чтения заблокируется. После заполнения небольшого буфера производитель ждёт освобождения места вместо бесконечного накопления. Цикл `range ch` получит все ранее отправленные значения и завершится после закрытия и опустошения канала. После трёх `Done` вызов `Wait` разблокируется ровно один раз для этого поколения задач.

Вопрос 12 из 25

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "time"
func main(){ timer:=time.NewTimer(time.Millisecond); defer timer.Stop(); <-timer.C }

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

Вопрос 13 из 25

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

// Определите правило Go, которое объясняет результат.
package main
import "time"
func main(){ timer:=time.NewTimer(time.Millisecond); defer timer.Stop(); <-timer.C }

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

Вопрос 14 из 25

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

`time.After` в часто повторяемом цикле создаёт новые таймеры и может удерживать ресурсы до их срабатывания. Утечка может не проявиться в коротком тесте, но накопиться под повторяющейся нагрузкой. Строковые ключи разных пакетов могут совпасть; большое значение удерживается до завершения всей цепочки контекста. Добавление `Sleep` меняет расписание, но не создаёт happens-before и не исправляет гонку. Копирование `Once` после использования нарушает контракт; повторный `Do` не повторит функцию после паники.

Вопрос 15 из 25

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

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

Вопрос 16 из 25

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

// Фрагмент для трассировки.
package main
func main(){ a:=make(chan int); b:=make(chan int); close(a); close(b); for a!=nil||b!=nil{ select{case _,ok:=<-a: if !ok{a=nil}; case _,ok:=<-b: if !ok{b=nil}} } }

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

Вопрос 17 из 25

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
func main(){ a:=make(chan int); b:=make(chan int); close(a); close(b); for a!=nil||b!=nil{ select{case _,ok:=<-a: if !ok{a=nil}; case _,ok:=<-b: if !ok{b=nil}} } }

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

Вопрос 18 из 25

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

// Определите правило Go, которое объясняет результат.
package main
func main(){ a:=make(chan int); b:=make(chan int); close(a); close(b); for a!=nil||b!=nil{ select{case _,ok:=<-a: if !ok{a=nil}; case _,ok:=<-b: if !ok{b=nil}} } }

Вызов функции отмены закрывает канал `Done` контекста и распространяется на его потомков. Хорошая ошибка сообщает, какая операция и над каким объектом не удалась, но не дублирует слово `error` на каждом уровне. Присваивание каналу значения `nil` отключает соответствующую ветвь `select`, потому что операция никогда не готова. Закрытие сообщает, что новых значений больше не будет; обычно канал закрывает отправитель, который знает о завершении всех отправок. Буферизированный канал принимает до `cap` значений без одновременного получателя; после заполнения отправка блокируется.

Вопрос 19 из 25

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

Строковые ключи разных пакетов могут совпасть; большое значение удерживается до завершения всей цепочки контекста. Закрытие входного канала из потребителя может паниковать в активном производителе. Утечка может не проявиться в коротком тесте, но накопиться под повторяющейся нагрузкой. Закрытый канал всегда готов к чтению; если не отключить его после `ok=false`, `select` может крутиться на нулевых значениях. Последовательность из двух атомарных чтений может увидеть сочетание значений, которое никогда не существовало как единый снимок.

Вопрос 20 из 25

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

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

Вопрос 21 из 25

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

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

Тест ждёт событие по каналу и сообщает отдельную ошибку только если дедлайн действительно истёк. `go test -race ./...` инструментирует программу и сообщает конфликтующие стеки доступа. Тест ожидает `Rollback`, если второй запрос транзакции завершился ошибкой. Тест использует канал результата и таймаут, поэтому различает успешное завершение и зависание. Тест ошибки проверяет `errors.Is`, а не точное длинное сообщение с контекстом.

Вопрос 22 из 25

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

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

Добавить регрессионный сценарий с барьером, метрику несогласованности и ссылку на отчёт гонки в расследовании. Записывать метод, хост, статус, длительность и категорию ошибки, не превращая URL с идентификаторами в метки высокой кардинальности. Использовать `iotest` и собственные маленькие заглушки, измерять число байтов и длительность без записи содержимого секретных потоков. Запускать `-race` в CI и на интеграционных сценариях, увеличивать охват конкурентных ветвей и сохранять отчёты. Инъецировать часы или длительности в код с большим числом временных сценариев, чтобы тесты не зависели от реального ожидания.

Вопрос 23 из 25

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

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

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

Вопрос 24 из 25

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

Невозможно в одном выполняемом тесте доказать, что запрещённый тип не компилируется; для этого нужны отдельные примеры сборки или анализ API. Большой запас уменьшает нестабильность, но маскирует медленную работу; слишком малый порог ломается под нагрузкой среды. Тест только с `bytes.Buffer` слишком дружелюбен и может не выявить ошибочную обработку частичного чтения. Тест только успешного 200 не проверяет закрытие тела, медленные заголовки, разрыв соединения и повтор. Разница в несколько процентов может быть шумом частоты процессора, фоновой нагрузки или компоновки памяти.

Вопрос 25 из 25

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

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