Каналы — бесплатный тест онлайн

Вопрос 1 из 25

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

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

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

Вопрос 2 из 25

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

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

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

Вопрос 3 из 25

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

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

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

Вопрос 4 из 25

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

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

Вопрос 5 из 25

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

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

Вопрос 6 из 25

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

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

Чтение `m["x"]` из `nil`-карты даёт `0`, но попытка `m["x"] = 1` завершится паникой. Два последовательных объекта могут быть декодированы двумя вызовами `Decode` без предварительного чтения всего входа. Чтение `<-ch` получит `7` только после готовой отправки, а небуферизованный канал создаёт точку встречи. Попытка сериализовать поле-функцию завершается `json: unsupported type`, а не молча пропускает его. `io.TeeReader` отдаёт данные вызывающему коду и одновременно записывает прочитанные байты в другой `Writer`.

Вопрос 7 из 25

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

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

Проверять ошибку записи и использовать `io.Copy` для полного переноса потока с корректной обработкой коротких записей. Не оставлять канал `nil` случайно; намеренно использовать `nil` только для отключения ветви `select`. Создавать карту через `make` или литерал до первой записи; чтение из `nil` допустимо, если такой контракт осознан. Всегда обрабатывать данные до ошибки и использовать `io.ReadAll`, `io.Copy` или буфер там, где они точнее выражают задачу. Использовать `DisallowUnknownFields` на строгой внешней границе и ограничивать размер входного потока.

Вопрос 8 из 25

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

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

`json.Marshal` возвращает байты и ошибку; неподдерживаемые значения вроде функций и каналов приводят к ошибке. Отправка и чтение синхронизируются согласно состоянию канала; операция с `nil`-каналом блокируется навсегда. Добавление необязательного поля обычно совместимо со старым JSON, а переименование или изменение смысла существующего поля требует миграции. `Write(p)` сообщает число принятых байтов; `n < len(p)` без ошибки нарушает обычный контракт и трактуется как `io.ErrShortWrite` помощниками. Чтение отсутствующего ключа возвращает нулевое значение элемента; запись в `nil`-карту вызывает панику.

Вопрос 9 из 25

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

Даже при ошибке возвращённые `n` байтов могут быть полезны для диагностики, но недостаточны для полного сообщения. Ошибка промежуточного писателя в `TeeReader` становится ошибкой чтения и останавливает поток. `NaN` и бесконечности `float64` не являются допустимыми числами JSON и вызывают ошибку кодирования. Отправка в закрытый канал вызывает панику, а чтение из закрытого и опустошённого канала возвращает ноль и `ok=false`. `Read` может вернуть меньше `len(p)` без ошибки, поэтому одно чтение не обязано заполнить буфер.

Вопрос 10 из 25

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

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

Вопрос 11 из 25

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

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

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

Вопрос 12 из 25

Фрагмент относится к теме «Закрытие». Какая правка устраняет причину, а не маскирует её проявление?

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

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

Вопрос 13 из 25

На ревью разбирают тему «Закрытие». Что именно гарантирует Go в этой ситуации?

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

Хорошая ошибка сообщает, какая операция и над каким объектом не удалась, но не дублирует слово `error` на каждом уровне. Закрытие сообщает, что новых значений больше не будет; обычно канал закрывает отправитель, который знает о завершении всех отправок. Контекст запроса отменяется при разрыве клиента, отмене HTTP/2 или завершении обработчика; дочерняя работа должна его уважать. Каждый этап должен прекращать чтение и отправку при отмене, иначе ранний выход потребителя оставляет заблокированные горутины. Горутина, навсегда заблокированная на отправке, чтении или ожидании, остаётся жить и удерживать связанные данные.

Вопрос 14 из 25

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

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

Вопрос 15 из 25

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

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

Вопрос 16 из 25

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

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

Запись `x=7` происходит до отправки, а получение из канала происходит до чтения `x`, поэтому читается 7. Функция `produce` может отправлять, но компилятор запретит ей читать из параметра `chan<- int`. Запрос к базе с `r.Context()` может прекратиться, если клиент перестал ждать ответ. Сигнатура `Load(ctx context.Context, id int)` позволяет вызывающему коду управлять временем жизни операции. Код может напечатать `A B` или `B A`; язык не обещает, какая горутина первой получит процессор.

Вопрос 17 из 25

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

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

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

Вопрос 18 из 25

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

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

`sync.Once` гарантирует, что переданная функция выполнится не более одного раза; паника всё равно считается выполнением. Блокирующая отправка естественно передаёт давление назад, когда потребитель медленнее производителя. Тип `<-chan T` разрешает только чтение, а `chan<- T` — только отправку; двунаправленный канал можно передать в более узкий параметр. Каждый этап должен прекращать чтение и отправку при отмене, иначе ранний выход потребителя оставляет заблокированные горутины. Fan-in объединяет несколько входов в один выход и закрывает его только после завершения всех копирующих горутин.

Вопрос 19 из 25

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

Закрытие входного канала из потребителя может паниковать в активном производителе. Истечение дедлайна не останавливает код силой: операция должна наблюдать `Done` или использовать API с поддержкой контекста. Направленный канал нельзя произвольно преобразовать обратно в двунаправленный, если информация была потеряна. Закрытый канал всегда готов к чтению; если не отключить его после `ok=false`, `select` может крутиться на нулевых значениях. Добавление `Sleep` меняет расписание, но не создаёт happens-before и не исправляет гонку.

Вопрос 20 из 25

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

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

Вопрос 21 из 25

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

// Фрагмент для трассировки.
package sample
import "testing"
func TestClosed(t *testing.T){ ch:=make(chan int); close(ch); v,ok:=<-ch; if v!=0||ok{t.Fatal(v,ok)} }

Тест использует канал результата и таймаут, поэтому различает успешное завершение и зависание. Тест с тысячей конкурентных увеличений ожидает точное итоговое значение под мьютексом. Таблица проверяет `int64` и собственный `Age`, поэтому ловит ошибочное сужение ограничения. Внешний тест не может обратиться к неэкспортированным полям и тем самым проверяет настоящий контракт пользователя. Тест проверяет и значение, и `ok`, поэтому не путает нулевой элемент с закрытым каналом.

Вопрос 22 из 25

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package sample
import "testing"
func TestClosed(t *testing.T){ ch:=make(chan int); close(ch); v,ok:=<-ch; if v!=0||ok{t.Fatal(v,ok)} }

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

Вопрос 23 из 25

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

// Определите правило Go, которое объясняет результат.
package sample
import "testing"
func TestClosed(t *testing.T){ ch:=make(chan int); close(ch); v,ok:=<-ch; if v!=0||ok{t.Fatal(v,ok)} }

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

Вопрос 24 из 25

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

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

Вопрос 25 из 25

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

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