Mutex, WaitGroup и sync — бесплатный тест онлайн

Вопрос 1 из 25

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

// Фрагмент для трассировки.
package main
import "sync"
type Store struct{ mu sync.Mutex; m map[string]int }
func (s *Store) Put(k string,v int){ s.mu.Lock(); defer s.mu.Unlock(); s.m[k]=v }
func main(){}

Отчёт указывает запись и чтение одной переменной из разных горутин без синхронизации. Два `n++` могут потерять обновление и образуют гонку, потому что операция состоит из чтения, вычисления и записи. `atomic.Int64.Add(1)` не теряет конкурентные увеличения одного счётчика. Запись `x=7` происходит до отправки, а получение из канала происходит до чтения `x`, поэтому читается 7. Обе операции с картой выполняются под одним мьютексом, поэтому конкурентная запись не приводит к гонке.

Вопрос 2 из 25

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "sync"
type Store struct{ mu sync.Mutex; m map[string]int }
func (s *Store) Put(k string,v int){ s.mu.Lock(); defer s.mu.Unlock(); s.m[k]=v }
func main(){}

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

Вопрос 3 из 25

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

// Определите правило Go, которое объясняет результат.
package main
import "sync"
type Store struct{ mu sync.Mutex; m map[string]int }
func (s *Store) Put(k string,v int){ s.mu.Lock(); defer s.mu.Unlock(); s.m[k]=v }
func main(){}

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

Вопрос 4 из 25

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

`len(ch)` — моментальный снимок очереди и не годится для принятия конкурентно безопасного решения о следующей операции. Пустой `select{}` блокируется навсегда, пока процесс не завершится извне. Защита каждого поля отдельным мьютексом не сохраняет сумму, если операция должна менять поля атомарно вместе. `defer mu.Unlock()` безопасен для ранних возвратов, но нельзя разблокировать мьютекс, который текущий путь не блокировал. Направленный канал нельзя произвольно преобразовать обратно в двунаправленный, если информация была потеряна.

Вопрос 5 из 25

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

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

Вопрос 6 из 25

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

// Фрагмент для трассировки.
package main
import "sync"
type Cache struct{ mu sync.RWMutex; m map[string]int }
func (c *Cache) Get(k string) int { c.mu.RLock(); defer c.mu.RUnlock(); return c.m[k] }
func main(){}

Барьер заставляет обе горутины начать критический участок одновременно и делает ошибку воспроизводимее. Горутина зависнет на отправке в небуферизованный канал, потому что никто не выполняет чтение. Два вызова `Get` могут выполняться одновременно, пока нет писателя. Когда оба буферизированных канала готовы, может выполниться любая из двух ветвей. Два `n++` могут потерять обновление и образуют гонку, потому что операция состоит из чтения, вычисления и записи.

Вопрос 7 из 25

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "sync"
type Cache struct{ mu sync.RWMutex; m map[string]int }
func (c *Cache) Get(k string) int { c.mu.RLock(); defer c.mu.RUnlock(); return c.m[k] }
func main(){}

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

Вопрос 8 из 25

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

// Определите правило Go, которое объясняет результат.
package main
import "sync"
type Cache struct{ mu sync.RWMutex; m map[string]int }
func (c *Cache) Get(k string) int { c.mu.RLock(); defer c.mu.RUnlock(); return c.m[k] }
func main(){}

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

Вопрос 9 из 25

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

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

Вопрос 10 из 25

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

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

Вопрос 11 из 25

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

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

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

Вопрос 12 из 25

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

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

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

Вопрос 13 из 25

На ревью разбирают тему «Ожидание группы WaitGroup». Что именно гарантирует Go в этой ситуации?

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

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

Вопрос 14 из 25

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

Вызов `Add` одновременно с `Wait` без заранее определённого протокола может привести к гонке логики и неправильному завершению. Увеличение работников не помогает последовательной части и может перегрузить внешнюю систему. Отрицательный счётчик вызывает панику; повторное использование возможно только после завершившегося `Wait` и нового независимого набора. Истечение дедлайна не останавливает код силой: операция должна наблюдать `Done` или использовать API с поддержкой контекста. Пустой `select{}` блокируется навсегда, пока процесс не завершится извне.

Вопрос 15 из 25

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

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

Вопрос 16 из 25

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

// Фрагмент для трассировки.
package main
import "sync"
var once sync.Once
func initValue(){}
func main(){ once.Do(initValue); once.Do(initValue) }

Каждое значение получает один из работников, а порядок результатов не обязан совпадать с входом. Из десяти конкурентных вызовов `once.Do(init)` тело `init` будет запущено максимум один раз. Отчёт указывает запись и чтение одной переменной из разных горутин без синхронизации. `atomic.Int64.Add(1)` не теряет конкурентные увеличения одного счётчика. `Wait` вернётся только после двух вызовов `Done`, поэтому `main` дождётся обеих функций.

Вопрос 17 из 25

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "sync"
var once sync.Once
func initValue(){}
func main(){ once.Do(initValue); once.Do(initValue) }

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

Вопрос 18 из 25

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

// Определите правило Go, которое объясняет результат.
package main
import "sync"
var once sync.Once
func initValue(){}
func main(){ once.Do(initValue); once.Do(initValue) }

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

Вопрос 19 из 25

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

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

Вопрос 20 из 25

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

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

Вопрос 21 из 25

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

// Фрагмент для трассировки.
package sample
import("sync";"testing")
func TestCount(t *testing.T){ var mu sync.Mutex; n:=0; var wg sync.WaitGroup; wg.Add(100); for i:=0;i<100;i++{go func(){defer wg.Done();mu.Lock();n++;mu.Unlock()}()};wg.Wait();if n!=100{t.Fatal(n)} }

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

Вопрос 22 из 25

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package sample
import("sync";"testing")
func TestCount(t *testing.T){ var mu sync.Mutex; n:=0; var wg sync.WaitGroup; wg.Add(100); for i:=0;i<100;i++{go func(){defer wg.Done();mu.Lock();n++;mu.Unlock()}()};wg.Wait();if n!=100{t.Fatal(n)} }

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

Вопрос 23 из 25

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

// Определите правило Go, которое объясняет результат.
package sample
import("sync";"testing")
func TestCount(t *testing.T){ var mu sync.Mutex; n:=0; var wg sync.WaitGroup; wg.Add(100); for i:=0;i<100;i++{go func(){defer wg.Done();mu.Lock();n++;mu.Unlock()}()};wg.Wait();if n!=100{t.Fatal(n)} }

Публичный пакет проверяют как внутренними тестами, так и внешним пакетом `_test`, примерами и тестами совместимости ошибок. Сериализацию проверяют золотыми примерами, круговым преобразованием и испорченным входом; файловые операции — временным каталогом теста. Панику проверяют в той же горутине через отложенный `recover`, а в рабочем сервисе фиксируют значение и стек. Синхронизацию проверяют под `-race`, повторными прогонами и инвариантами результата, а не только отсутствием паники. Таймаут в тесте должен ограничивать зависание, а не заменять причинную синхронизацию и не доказывать порядок планирования.

Вопрос 24 из 25

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

Можно убрать отчёт гонки одной блокировкой, но сохранить логическую потерю обновления в другом месте. Тест может пройти много раз при наличии гонки; отсутствие отчёта в одном запуске не является доказательством. Тест только успешного 200 не проверяет закрытие тела, медленные заголовки, разрыв соединения и повтор. Слишком короткий таймаут делает тест нестабильным на медленной машине, а отсутствие таймаута способно повесить весь набор. Тест, который просто завершается после `recover`, может ложно пройти, если забыта проверка факта паники.

Вопрос 25 из 25

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

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