Шаблоны конкурентных конвейеров — бесплатный тест онлайн

Вопрос 1 из 30

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

// Фрагмент для трассировки.
package main
func worker(in <-chan int,out chan<- int){for x:=range in{out<-x*x}}
func main(){}

Код печатает `busy`, потому что никто не готов принять значение из небуферизованного канала. Цикл `range ch` получит все ранее отправленные значения и завершится после закрытия и опустошения канала. `go work()` планирует отдельную горутину; `main` не обязан ждать её завершения. Каждая горутина получает собственное значение `v`, поэтому не читает одну меняющуюся переменную цикла. Каждое значение получает один из работников, а порядок результатов не обязан совпадать с входом.

Вопрос 2 из 30

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
func worker(in <-chan int,out chan<- int){for x:=range in{out<-x*x}}
func main(){}

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

Вопрос 3 из 30

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

// Определите правило Go, которое объясняет результат.
package main
func worker(in <-chan int,out chan<- int){for x:=range in{out<-x*x}}
func main(){}

Fan-out распределяет независимые элементы между несколькими работниками, читающими общий входной канал. Пакет `sync/atomic` обеспечивает атомарность отдельных операций и заданный порядок памяти, но не объединяет несколько полей в общий инвариант. Блокировка должна покрывать весь инвариант и использовать единый порядок захвата нескольких мьютексов. `RWMutex` допускает несколько читателей или одного писателя; читать защищаемые данные без `RLock` всё равно нельзя. Вызов функции отмены закрывает канал `Done` контекста и распространяется на его потомков.

Вопрос 4 из 30

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

Отрицательный счётчик вызывает панику; повторное использование возможно только после завершившегося `Wait` и нового независимого набора. Изменение `GOMAXPROCS` может менять частоту проявления, но отсутствие сбоя при одном значении ничего не доказывает. Увеличение работников не помогает последовательной части и может перегрузить внешнюю систему. Двойная проверка без атомиков и барьеров может читать частично опубликованное состояние. Даже при `GOMAXPROCS(1)` горутины могут чередоваться, поэтому это не превращает программу в последовательную.

Вопрос 5 из 30

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

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

Вопрос 6 из 30

В рабочем примере по теме «Объединение потоков fan-in» важно отделить гарантию от догадки. Что гарантированно произойдёт в показанной последовательности операций?

// Фрагмент для трассировки.
package main
import "sync"
func merge(cs ...<-chan int)<-chan int{out:=make(chan int);var wg sync.WaitGroup;wg.Add(len(cs));for _,c:=range cs{go func(c <-chan int){defer wg.Done();for v:=range c{out<-v}}(c)};go func(){wg.Wait();close(out)}();return out}
func main(){}

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

Вопрос 7 из 30

Фрагмент относится к теме «Объединение потоков fan-in». Какой вариант исправления соответствует обычной практике Go?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "sync"
func merge(cs ...<-chan int)<-chan int{out:=make(chan int);var wg sync.WaitGroup;wg.Add(len(cs));for _,c:=range cs{go func(c <-chan int){defer wg.Done();for v:=range c{out<-v}}(c)};go func(){wg.Wait();close(out)}();return out}
func main(){}

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

Вопрос 8 из 30

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

// Определите правило Go, которое объясняет результат.
package main
import "sync"
func merge(cs ...<-chan int)<-chan int{out:=make(chan int);var wg sync.WaitGroup;wg.Add(len(cs));for _,c:=range cs{go func(c <-chan int){defer wg.Done();for v:=range c{out<-v}}(c)};go func(){wg.Wait();close(out)}();return out}
func main(){}

Блокировка должна покрывать весь инвариант и использовать единый порядок захвата нескольких мьютексов. Контекст запроса отменяется при разрыве клиента, отмене HTTP/2 или завершении обработчика; дочерняя работа должна его уважать. Fan-in объединяет несколько входов в один выход и закрывает его только после завершения всех копирующих горутин. Вызов функции отмены закрывает канал `Done` контекста и распространяется на его потомков. `RWMutex` допускает несколько читателей или одного писателя; читать защищаемые данные без `RLock` всё равно нельзя.

Вопрос 9 из 30

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

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

Вопрос 10 из 30

Команда проверяет решение по теме «Объединение потоков fan-in». Как решение скажется на тестировании и дальнейших изменениях?

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

Вопрос 11 из 30

Фрагмент относится к теме «Обратное давление». Какое наблюдение о работе кода будет верным?

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

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

Вопрос 12 из 30

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

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

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

Вопрос 13 из 30

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

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

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

Вопрос 14 из 30

Команда проверяет решение по теме «Обратное давление». Где заканчивается гарантия показанного приёма?

`len(ch)` — моментальный снимок очереди и не годится для принятия конкурентно безопасного решения о следующей операции. Строковые ключи разных пакетов могут совпасть; большое значение удерживается до завершения всей цепочки контекста. Неограниченная очередь переносит перегрузку в память и увеличивает задержку старых элементов. Разные элементы одного среза можно менять конкурентно при отсутствии изменения заголовка и других общих инвариантов, но это надо доказать. Истечение дедлайна не останавливает код силой: операция должна наблюдать `Done` или использовать API с поддержкой контекста.

Вопрос 15 из 30

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

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

Вопрос 16 из 30

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

// Фрагмент для трассировки.
package main
import "context"
func stage(ctx context.Context,in <-chan int)<-chan int{out:=make(chan int);go func(){defer close(out);for v:=range in{select{case out<-v*2:case <-ctx.Done():return}}}();return out}
func main(){}

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

Вопрос 17 из 30

В разделе «Отмена» показан конкретный случай. Какое изменение лучше всего укрепит контракт этого фрагмента?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "context"
func stage(ctx context.Context,in <-chan int)<-chan int{out:=make(chan int);go func(){defer close(out);for v:=range in{select{case out<-v*2:case <-ctx.Done():return}}}();return out}
func main(){}

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

Вопрос 18 из 30

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

// Определите правило Go, которое объясняет результат.
package main
import "context"
func stage(ctx context.Context,in <-chan int)<-chan int{out:=make(chan int);go func(){defer close(out);for v:=range in{select{case out<-v*2:case <-ctx.Done():return}}}();return out}
func main(){}

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

Вопрос 19 из 30

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

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

Вопрос 20 из 30

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

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

Вопрос 21 из 30

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

// Фрагмент для трассировки.
package sample
// Тест: получить первый результат, вызвать cancel, дождаться закрытия out с таймаутом.
func main(){}

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

Вопрос 22 из 30

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package sample
// Тест: получить первый результат, вызвать cancel, дождаться закрытия out с таймаутом.
func main(){}

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

Вопрос 23 из 30

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

// Определите правило Go, которое объясняет результат.
package sample
// Тест: получить первый результат, вызвать cancel, дождаться закрытия out с таймаутом.
func main(){}

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

Вопрос 24 из 30

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

Разница в несколько процентов может быть шумом частоты процессора, фоновой нагрузки или компоновки памяти. Сравнение общего `runtime.NumGoroutine` без допуска нестабильно из-за фоновых горутин среды. Высокое покрытие может состоять из тестов без содержательных утверждений. Слишком короткий таймаут делает тест нестабильным на медленной машине, а отсутствие таймаута способно повесить весь набор. Проверка `len(ch)==0` перед чтением не защищает от изменения состояния другой горутиной.

Вопрос 25 из 30

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

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

Вопрос 26 из 30

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

// Фрагмент для трассировки.
package main
const workers=16
const queue=64
func main(){ _=make(chan int,queue); _=workers }

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

Вопрос 27 из 30

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
const workers=16
const queue=64
func main(){ _=make(chan int,queue); _=workers }

Настроить таймауты чтения заголовков, лимит тела, максимальную конкуренцию и защиту общего состояния. Считать запросы, категории ошибок, гистограмму задержки, очередь и ресурсы зависимостей; связывать с трассировкой через exemplar. Назначать уникальные порты через прослушивание `:0`, не менять глобальное окружение параллельно и закрывать серверы через Cleanup. Настраивать лимиты по профилю зависимости, иметь глобальный бюджет и корректно останавливать при выпуске. Иметь общий корневой контекст, идемпотентное закрытие, ограниченный льготный срок и принудительный финальный путь.

Вопрос 28 из 30

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

// Определите правило Go, которое объясняет результат.
package main
const workers=16
const queue=64
func main(){ _=make(chan int,queue); _=workers }

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

Вопрос 29 из 30

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

Среднее значение может скрыть ухудшение p99 и ошибки небольшой, но важной группы запросов. Мьютекс, удерживаемый вокруг `next`, последовательно обработает весь сервер и может привести к взаимной блокировке. Идентификатор пользователя, полный URL или текст ошибки в метке создаёт неограниченное число временных рядов. Два последовательных этапа с собственными большими буферами могут скрыть минуты накопленной задержки. Если сначала закрыть базу, активные HTTP-запросы могут завершиться ошибкой вместо штатного окончания.

Вопрос 30 из 30

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

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