Вопросы на собеседовании: Go-разработчик

Bounded worker pool запускает фиксированное число воркеров, которые получают задачи из общего канала.

• Фиксированное число воркеров ограничивает параллелизм и потребление ресурсов независимо от количества задач.
• Производитель отправляет задачи и закрывает канал задач после последней из них, чтобы воркеры, читающие его через range, могли завершиться.
• Каждый воркер вызывает Done у WaitGroup при выходе, а координатор ожидает завершения всех воркеров.
• Если воркеры выдают результаты, координатор закрывает канал результатов только после того, как все воркеры закончили отправку.

Fan-out распределяет работу из одного входного потока между несколькими конкурентными потребителями.

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

Fan-in объединяет значения из нескольких входных каналов в один выходной канал.

• Распространенная реализация запускает по одной пересылающей горутине для каждого входного канала.
• Каждая пересылающая горутина читает свой вход через range и отправляет все значения в общий выход.
• WaitGroup отслеживает пересылающие горутины, чтобы согласовать их независимое завершение.
• Один координатор закрывает выход после завершения всех пересылающих горутин; ни одна отдельная горутина его не закрывает.

Pipeline соединяет конкурентные этапы, каждый из которых получает значения, преобразует их и передает результаты дальше.

• Этапы предоставляют каналы с совместимыми типами элементов и направлениями, поэтому один этап может передавать данные следующему.
• С небуферизованными каналами медленный последующий этап сразу блокирует отправки предыдущего.
• Конечный буфер компенсирует ограниченное расхождение скоростей, но предыдущий этап все равно блокируется после заполнения буфера.
• Эта блокировка распространяется к источнику и создает backpressure без неограниченной очереди.

Каждый этап pipeline должен учитывать общий сигнал отмены во время потенциально блокирующих операций.

• Нижестоящий потребитель отменяет context или закрывает общий канал done, если прекращает работу до полного чтения pipeline.
• Каждый этап через select ожидает либо отмену, либо завершение блокирующей операции с каналом, особенно отправки следующему этапу.
• При отмене этапы завершаются, закрывают принадлежащие им выходные каналы и освобождают другие ресурсы.
• Простого выхода из финального цикла чтения недостаточно, потому что вышестоящие горутины могут навсегда заблокироваться на отправке.

Владение каналом означает соглашение, по которому один компонент управляет отправкой и жизненным циклом канала.

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

Направленные типы каналов ограничивают операции, которые код может выполнять с каналом.

• chan<- T разрешает отправку и закрытие, но запрещает чтение на этапе компиляции.
• <-chan T разрешает чтение, но запрещает отправку и закрытие на этапе компиляции.
• Двунаправленный chan T можно присвоить или передать как любой направленный тип, но неявно расширить ограниченное представление обратно нельзя.
• Эти типы в сигнатурах функций документируют намерение о владении и обеспечивают границы API.

Nil-канал никогда не готов к передаче данных ни в одном направлении.

• Прямая отправка в nil-канал или чтение из него блокируется навсегда.
• В select ветка с nil-каналом отключена и не может быть выбрана.
• Присваивание nil переменной канала позволяет динамически отключить ее ветку без изменения структуры select.
• Select, у которого отключены все коммуникационные ветки, блокируется навсегда, если в нем нет default.

Select выбирает одну операцию, которая может выполниться в момент вычисления оператора.

• Если готова ровно одна ветка, выбирается она.
• Если готовы несколько веток, одна выбирается равновероятно псевдослучайным образом без приоритета по порядку в исходном коде.
• Ветка default выполняется только тогда, когда ни одна коммуникационная ветка не готова немедленно, поэтому select становится неблокирующим.
• Повторение select с default в плотном цикле может создать активное ожидание и расходовать процессорное время.

Емкость канала определяет, насколько тесно синхронизируются отправители и получатели.

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

sync.Mutex предоставляет исключительный доступ к критической секции.

• Его нулевое значение является разблокированным мьютексом, Lock ждёт доступности мьютекса, а Unlock может вызвать другая горутина.
• Успешный Unlock синхронизируется с последующим успешным Lock, поэтому записи в критической секции видимы после этого Lock.
• Мьютекс не является реентерабельным: повторный Lock в той же горутине без промежуточного Unlock приводит к взаимной блокировке.
• Mutex нельзя копировать после первого использования, поскольку у копии отдельное состояние блокировки, которое больше не координирует весь доступ к защищённым данным.

sync.RWMutex допускает либо несколько читателей, либо одного эксклюзивного писателя.

• RLock может сосуществовать с другими блокировками чтения, а Lock ждёт всех читателей и исключает как читателей, так и писателей.
• Когда писатель уже ожидает, новые вызовы RLock блокируются, чтобы непрерывный поток читателей не вызвал голодание писателя.
• Переход от RLock к Lock и от Lock к RLock не поддерживается, и RWMutex нельзя использовать для рекурсивной блокировки чтения.
• Дополнительный учёт оправдан в основном при преобладании чтения и достаточно длинных критических секциях; иначе Mutex может быть проще и быстрее.

sync.WaitGroup ожидает завершения отслеживаемого набора задач.

• Вызывайте Add перед запуском каждой задачи, а в самой задаче вызывайте Done ровно один раз, обычно через defer.
• Wait блокируется, пока счётчик не станет равен нулю, а Add вызывает панику, если обновление делает счётчик отрицательным.
• Положительный Add при нулевом счётчике должен произойти до Wait; конкурентный вызов Add и Wait небезопасен, поскольку Wait может вернуться слишком рано.
• WaitGroup можно использовать повторно только после возврата предыдущего Wait, причём все Add нового цикла должны происходить после этого.

Эти средства выполняют ленивую инициализацию не более одного раза и безопасно публикуют её завершённый результат.

• Once.Do вызывает функцию при первом обращении, блокирует конкурентных вызывающих до её завершения и больше её не вызывает.
• Если функция Once.Do паникует, этот вызов всё равно считается завершённым, поэтому последующие Do возвращаются без повторного запуска.
• OnceValue кэширует одно возвращаемое значение, а OnceValues два, и каждая обёртка при каждом вызове возвращает тот же кэшированный результат.
• Если инициализатор OnceValue или OnceValues паникует, каждый вызов обёртки паникует с тем же значением паники, а не молча возвращается.

Атомарные операции делают одну поддерживаемую операцию с памятью неделимой без объявления критической секции.

• Загрузки, сохранения, обмены, сложения и успешные операции compare-and-swap атомарны только для адресуемого значения и конкретной операции.
• Последовательность чтения, изменения и записи из отдельных атомарных вызовов не является одной атомарной транзакцией, если она не реализована как корректный цикл CAS.
• В Go атомарные операции ведут себя так, словно все они выполняются в едином последовательно согласованном порядке, что обеспечивает синхронизацию между горутинами.
• Используйте мьютекс, если инвариант охватывает несколько полей или шагов, а атомики для простых счётчиков, флагов или тщательно спроектированного неблокирующего состояния.

Производные контексты образуют дерево от переданного родительского контекста.

• Background и TODO являются ненулевыми корневыми контекстами, а WithCancel, WithDeadline и WithTimeout создают дочерние.
• Отмена родителя отменяет всех производных от него потомков.
• Отмена дочернего контекста не отменяет его родителя, соседние контексты или другие ветви дерева.
• Context безопасен для конкурентного использования и обычно явно передаётся первым параметром через границы вызовов.

Отмена контекста кооперативна: код должен сам наблюдать сигнал и прекращать свою работу.

• Done возвращает канал только для чтения, который закрывается при отмене контекста или истечении срока, и может быть nil у контекстов без возможности отмены.
• До закрытия Done метод Err возвращает nil, а после него возвращает context.Canceled или context.DeadlineExceeded.
• Блокирующийся код обычно выбирает через select между обычной операцией с каналом и ctx.Done(), чтобы не ждать бесконечно.
• После сигнала Done код должен быстро вернуться и освободить свои ресурсы, а не ожидать, что контекст сам завершит горутину.

WithDeadline и WithTimeout создают производный контекст, который будет отменён не позже заданного времени.

• WithDeadline использует абсолютное время, а WithTimeout вычисляет срок относительно текущего времени.
• Эффективный срок не может быть позже более раннего срока родителя.
• Возвращённую функцию cancel обычно следует сразу отложить через defer, даже если ожидается автоматическое истечение срока.
• Ранний вызов cancel освобождает таймер и связь производного контекста с родителем и не удерживает ресурсы до истечения срока.

Значения контекста предназначены для данных запроса, которые должны пересекать границы API и процессов.

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

WithCancelCause позволяет передать при отмене предметную ошибку в дополнение к стандартному состоянию контекста.

• Он возвращает CancelCauseFunc, которая записывает переданную ненулевую ошибку, если контекст ещё не отменён; передача nil записывает context.Canceled.
• Если первой срабатывает CancelCauseFunc, Cause возвращает записанную ошибку, а Err возвращает context.Canceled; более ранняя отмена родителя сохраняет его Err и причину.
• Причина распространяется на потомков, если потомок раньше не установил собственную причину отмены.
• До отмены Cause возвращает nil, а после отмены без явной причины возвращает ту же стандартную ошибку, что и Err.