13. Memory Model и happens before

«Понятие того, что одно событие произошло раньше другого в распределенной или параллельной системе, является фундаментальным отношением частичного порядка».
— Лесли Лэмпорт

Граф отношения Happens-Before в Go

Модель памяти языка Go (The Go Memory Model) формализует отношение частичного порядка happens-before ($A \prec B$). Если событие $A$ происходит до события $B$, то любые изменения разделяемой памяти, произведенные в $A$, гарантированно видны при выполнении $B$:

flowchart TD
    classDef entry fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef process fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef accent fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    classDef success fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc
    classDef warning fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc

    subgraph Goroutine1["Горутина 1 (Producer)"]
        W1["Запись данных в память: data = 42"]:::process
        Send["ch <- true (отправка в канал)"]:::entry
        Unlock["mu.Unlock() (освобождение мьютекса)"]:::entry
        W1 --> Send
        W1 --> Unlock
    end

    subgraph SyncRel["Отношение Happens-Before (Синхронизация)"]
        Send -.->|"Синхронизирующее ребро"| Recv["<-ch (получение из канала)"]:::accent
        Unlock -.->|"Синхронизирующее ребро"| Lock["mu.Lock() (захват мьютекса)"]:::accent
    end

    subgraph Goroutine2["Горутина 2 (Consumer)"]
        Recv --> R1["Чтение: print(data) -> гарантированно 42"]:::success
        Lock --> R2["Чтение: print(data) -> гарантированно 42"]:::success
    end
  

Аппаратные барьеры памяти: компилятор и процессор

Без явной синхронизации оптимизирующий компилятор и ядра процессора (Out-of-Order Execution, Store Buffers) могут произвольно переупорядочивать операции записи и чтения:

flowchart LR
    classDef entry fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef process fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef accent fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    classDef warning fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc

    subgraph Logical["Исходный порядок в Go-коде"]
        S1["1. x = 1 (подготовка данных)"]:::process --> S2["2. ready = true (публикация)"]:::process
    end

    subgraph Physical["Реальное исполнение CPU / кэш"]
        S2P["ready = true (попадает в Store Buffer)"]:::warning
        S1P["x = 1 (задерживается в конвейере L1)"]:::warning
        Barrier["MFENCE / DMB (Барьер памяти Go-рантайма)"]:::accent
        Barrier --> Flush["Сброс буфера: x=1 строго до ready=true"]:::entry
    end
  

Навигатор по вопросам главы

1. Что такое модель памяти (memory model)?
2. Что такое happens-before?
3. Что гарантирует happens-before?
4. Что такое видимость (visibility)?
5. Что такое переупорядочивание (reordering)?
6. Как mutex влияет на модель памяти?
7. Как канал влияет на модель памяти?
8. Как atomic влияет на модель памяти?
9. Как создание горутины влияет на модель памяти?
10. Как завершение горутины влияет на модель памяти?
11. Как sync.WaitGroup влияет на модель памяти?
12. Как sync.Once влияет на модель памяти?
13. Как sync.Cond влияет на модель памяти?
14. Как sync.Map влияет на модель памяти?
15. Как sync.Pool влияет на модель памяти?
16. Какие операции являются синхронизирующими (synchronizing)?
17. Может ли компилятор переупорядочить операции до и после Mutex.Unlock?
18. Что такое "DRF-SC" (Data-Race-Free Sequential Consistency)?
19. Как happens-before гарантирует причинно-следственную связь?
20. Что такое "sequentially consistent" и "relaxed" атомарные операции?
21. Как модель памяти Go соотносится с моделями памяти C++11 и Java?
22. Как работает atomic.CompareAndSwap и какую гарантию видимости он дает?
23. Что такое "происходит до" (happens before) при отправке в буферизированный канал?
24. Как происходит "синхронизация" через sync.Mutex?
25. Как работает happens-before для atomic.Store и atomic.Load?
26. Как модель памяти Go работает на уровне процессора (x86 vs ARM)?
27. Что такое "store buffer" и как он влияет на видимость данных?
28. Как canal обеспечивает happens-before между отправкой и получением?
29. Как select с дефолтным значением влияет на happens-before?
30. Как runtime.Gosched влияет на видимость памяти?
31. Почему "двойная проверка" (double-checked locking) не работает без atomic?
32. Как sync.Once гарантирует, что функция выполнится только один раз?
33. Как sync.Cond обеспечивает happens-before?
34. Что такое "синхронизация через создание горутины" (go statement)?
35. Как happens-before предотвращает гонки данных?
36. Как race detector использует happens-before для поиска гонок?
37. Как правильно опубликовать сложный объект для использования другими горутинами?
38. Что такое "синхронизированная публикация" (safe publication)?
39. Как происходит happens-before при использовании sync.Pool.Put и Get?
40. Что такое "consume vs acquire semantics" в контексте атомарных операций Go?
41. Как sync/atomic операции обеспечивают барьеры памяти?
42. Почему atomic.Load и atomic.Store не гарантируют полную упорядоченность без happens-before?
43. Как работает "memory ordering" на уровне процессора и как Go скрывает это от разработчика?
44. Как модель памяти Go работает для "finalizers"?
45. Как sync.Map обеспечивает безопасную публикацию данных?
46. Что такое «правило единого писателя» в контексте модели памяти Go?
47. Как модель памяти влияет на дизайн lock-free структур данных?

Что такое модель памяти (memory model)?

Краткий ответ

Модель памяти языка программирования — это формальная спецификация того, какие значения могут увидеть читатели памяти при конкурентном доступе. Она определяет правила, гарантирующие, что операции записи в память становятся видимыми другим потокам, и задаёт отношение «происходит до» (happens-before). Без модели памяти невозможно рассуждать о корректности многопоточных программ.

Развёрнутый ответ

Модель памяти отвечает на вопрос: если одна горутина записывает значение в переменную, а другая читает эту переменную, какое значение может быть прочитано? Без синхронизации чтение может увидеть старое значение, частично записанное значение или вообще недетерминированный мусор. Модель памяти Go (The Go Memory Model) определяет условия, при которых чтение гарантированно наблюдает запись, произошедшую в другой горутине. Это достигается через синхронизирующие операции: блокировки мьютексов, операции с каналами, атомарные операции, создание/завершение горутин и вызовы sync примитивов.

Модель памяти опирается на happens-before — частичный порядок событий в программе. Если запись W происходит до чтения R (W happens-before R), то R гарантированно видит W. Если же две операции конкурентны (нет порядка), результат не определён — это гонка данных. Модель Go, подобно C++ и Java, гарантирует DRF-SC (Data-Race-Free Sequential Consistency): программы без гонок ведут себя так, как если бы выполнение было последовательно согласованным.

var a string
var done bool

// Горутина 1
func setup() {
    a = "hello"
    done = true
}

// Горутина 2
func read() {
    for !done {
    }
    println(a) // может напечатать пустую строку без синхронизации
}

Без happens-before гарантии нет: компилятор/процессор могут переупорядочить a = "hello" и done = true, и горутина 2 может увидеть done == true до того, как a присвоено значение.

Под капотом (internals)

На уровне компилятора Go модель памяти реализуется вставкой барьеров памяти (fences) в критические участки. Компилятор представлен в cmd/compile, рантайм — в src/runtime. Для синхронизирующих операций используются архитектурно-зависимые барьеры (например, runtime∕internal∕atomic.Store с явным барьером). Планировщик горутин (runtime∕proc.go) неявно вносит барьеры при переключении контекста, но не гарантирует их для обычных операций. GC использует барьеры записи (write barriers) для отслеживания указателей, но они ортогональны модели памяти. escape analysis не влияет напрямую на модель, а лишь определяет размещение в стеке/куче.

Типичные ошибки кандидатов

• Предположение о последовательной согласованности по умолчанию: многие считают, что программа на Go выполняется в порядке исходного текста. В реальности без явной синхронизации компилятор и процессор могут переупорядочивать операции. Исправление: всегда использовать синхронизацию (каналы, мьютексы, atomic) при совместном доступе к памяти.
• Использование *bool как флага завершения: изменение *bool одной горутиной и чтение другой не гарантирует видимость связанных данных без atomic или sync.Mutex. Исправление: применять atomic.StoreBool/atomic.LoadBool или канал с закрытием.
• Игнорирование частичной записи: думают, что запись int64 на 32-битной архитектуре всегда атомарна. Go не гарантирует атомарность для обычных операций; следует использовать atomic.Int64.
• Неверное понимание sync.WaitGroup.Wait: предполагают, что после Wait() все горутины уже завершились и их побочные эффекты видны, но забывают, что Wait сам по себе не создаёт happens-before для записей, выполненных внутри горутин — нужна синхронизация через sync.WaitGroup.Add/Done.

Возможные дополнительные вопросы интервьюера

• Чем модель памяти Go отличается от модели памяти C++? — Go имеет более простую модель, основанную на DRF-SC и синхронизирующих операциях, без явных memory_order; все атомарные операции в Go — последовательно согласованные.
• Гарантирует ли Go, что запись int атомарна? — Нет, спецификация не гарантирует атомарность обычных операций; выравнивание и размер слова не делают запись атомарной. Используйте atomic.
• Можно ли вывести модель памяти из документации рантайма? — Официальный документ "The Go Memory Model" на golang.org является каноническим и должен строго соблюдаться.

Что такое happens-before?

Краткий ответ

Happens-before — это отношение частичного порядка, введённое моделью памяти Go, которое определяет гарантированный порядок выполнения событий в разных горутинах. Если событие A happens-before событие B, все изменения памяти от A (и всего, что A предшествует) видны в B. Это фундаментальное понятие, позволяющее строить корректные многопоточные программы.

Развёрнутый ответ

Happens-before формализует интуитивное «произошло до». Оно транзитивно: если A happens-before B и B happens-before C, то A happens-before C. В Go отношение порождается определёнными синхронизирующими операциями:

• Разблокировка мьютекса происходит до последующей блокировки того же мьютекса.
• Отправка в канал происходит до соответствующего получения.
• Завершение горутины происходит до чтения нулевого значения из канала.
• sync.WaitGroup.Wait происходит до возврата из Wait.
• Атомарная запись происходит до последующего атомарного чтения того же значения.

Без синхронизации не существует happens-before между горутинами, а значит, наблюдаемое поведение может быть любым переупорядоченным вариантом.

«Происходит до» в Go не имеет прямой связи с wall-clock временем; оно лишь о гарантированной видимости памяти.

Под капотом (internals)

В рантайме реализация отношения опирается на барьеры памяти. Например, sync.Mutex.Unlock выполняет архитектурный store-release барьер, а Lock — load-acquire барьер. Это гарантирует, что все операции записи, выполненные до Unlock, становятся видимыми после Lock. Компилятор учитывает эти барьеры при планировании инструкций и никогда не переносит операцию через барьер. В runtime/internal/atomic определена функция Store с барьером runtime.writeBarrier (в некоторых контекстах), а для ARM64 генерируются инструкции STLR/LDAR.

Типичные ошибки кандидатов

• Вера в «происходит до» по времени начала: если горутина A стартовала раньше горутины B, это не даёт гарантий, что записи A видны B. Исправление: только синхронизирующие события создают порядок.
• Путаница между «synchronized before» и «happens before»: думают, что если A синхронизирована с B, то всё, что было в A, видно в B, но забывают о транзитивности через другие события. Исправление: цепочка happens-before может быть длинной; нужно явно выстраивать её через подходящие примитивы.
• Использование time.Sleep для синхронизации: надежда, что задержка гарантирует видимость, ошибочна — рантайм не обещает никаких happens-before для Sleep. Исправление: применить любой механизм синхронизации.

Возможные дополнительные вопросы интервьюера

• Как happens-before соотносится с memory ordering процессора? — Happens-before — абстракция языка, которая транслируется в барьеры памяти, соответствующие выбранной модели (например, acquire/release).
• Может ли компилятор нарушить happens-before? — Нет, спецификация обязывает компилятор соблюдать гарантии, запрещая переупорядочивание через синхронизирующие барьеры.
• Что значит «происходит до» для небуферизированного канала? — Отправка происходит до получения, и наоборот: приём происходит до завершения отправки, создавая полную синхронизацию.

Что гарантирует happens-before?

Краткий ответ

Happens-before гарантирует, что все записи в память, выполненные до события A (включая те, что видимы через цепочку «происходит до»), будут наблюдаемы при событии B, если A происходит до B. Это гарантия видимости и согласованности памяти между горутинами в отсутствие гонок данных.

Развёрнутый ответ

Если есть отношение A happens-before B, то:

1. Записи, выполненные до A в её горутине, видны в B (и в любых событиях после B в её горутине).
2. Порядок, определённый отношением, транзитивен и не может быть нарушен ни оптимизатором, ни процессором.
3. Если имеется несколько записей, и одна из них happens-before чтения, то чтение видит именно эту запись.
4. Если ни одна запись не happens-before чтения, компилятор и процессор могут показать любое значение (в том числе «неконсистентное» из-за разрыва слова).

Это позволяет строить корректные конкурентные структуры без блокировок, используя atomic-операции.

Пример: после mu.Unlock() запись x = 1 видна следующему mu.Lock(), потому что Unlock happens-before последующий Lock.

Под капотом (internals)

Рантайм реализует гарантии через:

• Упорядочивание записей в пределах одной горутины: компилятор не переупорядочивает операции с барьерами.
• Барьер StoreRel при release-семантике (например, Unlock), который сбрасывает store buffer и делает записи глобально видимыми.
• Барьер LoadAcq при acquire-семантике (Lock), который не позволяет последующим чтениям/записям переехать раньше инструкции блокировки.
• Транзитивность достигается за счёт срабатывания цепочек этих барьеров.

На архитектурах со слабой моделью (ARM) используются явные DMB-инструкции.

Типичные ошибки кандидатов

• Предположение, что happens-before означает глобальный порядок: отношение относится только к конкретным событиям, а не ко всем операциям всех горутин. Нельзя сравнивать два несвязанных события.
• Думают, что атомарная операция дает универсальную видимость: без парной синхронизации чтение-запись может не иметь happens-before. Нужно явно согласовать порядок.
• Забывают про компиляторную оптимизацию: значение может кэшироваться в регистре горутины бесконечно, даже если есть логическая запись. Только явные атомарные/синхронизирующие обращения заставят перечитать память.

Возможные дополнительные вопросы интервьюера

• Может ли happens-before нарушиться из-за гонки? — Да, присутствие гонки данных отменяет все гарантии модели памяти; программа может вести себя непредсказуемо.
• Гарантирует ли happens-before, что одна горутина «видит» операции другой в реальном времени? — Нет, это лишь о видимости после синхронизации, не о физическом времени.
• Как убедиться, что запись в мапу видна другой горутине? — Используйте sync.Mutex, охватывающий и запись, и чтение мапы, либо sync.Map.

Что такое видимость (visibility)?

Краткий ответ

Видимость определяет, когда запись, выполненная одной горутиной, становится доступной для чтения другой горутине. В контексте модели памяти Go видимость гарантируется только при наличии отношения happens-before между записью и чтением. Без синхронизации компилятор, процессор и кэши могут скрывать запись сколь угодно долго.

Развёрнутый ответ

Проблема видимости возникает из-за многоуровневой иерархии памяти: регистры, L1/L2/L3-кэши, store buffer, основная память. Запись одной горутины может застрять в локальном кэше или store buffer процессора и быть невидимой для другого ядра. Модель памяти Go гарантирует, что если запись happens-before чтение, то к моменту чтения все предшествующие записи «вливаются» в общую память и становятся видимыми. В противном случае «увидеть» можно старое значение, частичную запись или «невозможное» с точки зрения последовательного выполнения значение.

Для обеспечения видимости используются синхронизирующие операции, которые неявно вставляют барьеры памяти, принудительно инвалидируя кэши и сбрасывая store buffers.

Пример: горутина обновляет структуру и затем закрывает канал. Закрытие канала создает happens-before с чтением из канала другой горутиной, что гарантирует видимость всей структуры.

Под капотом (internals)

Машинные инструкции acquire/release (например, LOCK-префикс на x86, DMB/STLR на ARM) обладают семантикой, которая:

• Acquire (чтение) делает видимыми все записи, которые происходили до соответствующего release в другом ядре.
• Release (запись) гарантирует, что все предыдущие записи станут видимыми до того, как release-запись будет видна другим ядрам.
  Go компилятор вставляет эти инструкции при реализации атомарных операций, Mutex и каналов. Рантайм не полагается на volatile-переменные, а использует явные операции.

Типичные ошибки кандидатов

• Проверка флага без atomic: for !flag {} может никогда не завершиться из-за регистровой оптимизации. Нужно atomic.Load или синхронизация.
• Публикация сложного объекта через обычную переменную: global = &MyStruct{...}; другая горутина может увидеть указатель, но не проинициализированные поля. Исправление: публиковать через atomic.StorePointer с последующим atomic.LoadPointer.
• Использование sync.Map как простого хранилища, игнорируя видимость: операции Load/Store внутри sync.Map создают happens-before, но только для данных, которые хранятся в самом Map; внешние ссылки требуют собственной синхронизации.

Возможные дополнительные вопросы интервьюера

• Можно ли гарантировать видимость без явных барьеров на x86? — Архитектура x86 обладает сильной моделью памяти, но компилятор всё равно может переупорядочить инструкции. Полагаться на свойства железа — ошибка.
• Почему fmt.Println иногда «исцеляет» гонку? — Вызов ввода/вывода часто неявно использует блокировки внутри os.File, что может создать непреднамеренную синхронизацию. Это ненадёжный эффект.
• Как atomic.Store гарантирует видимость записанного значения? — Он содержит release-семантику, которая сбрасывает store buffer и делает запись глобально видимой при последующем acquire-чтении.

Что такое переупорядочивание (reordering)?

Краткий ответ

Переупорядочивание — это изменение порядка инструкций компилятором или процессором относительно исходного текста программы. Модель памяти Go запрещает переупорядочивание через границы happens-before, но в пределах одной горутины без синхронизации разрешает перестановки, которые могут привести к неожиданному поведению при конкурентном доступе.

Развёрнутый ответ

Переупорядочивание бывает двух видов:

1. Компиляторное: оптимизации могут выносить обращения к памяти, сохранять значения в регистры, менять порядок независимых операций. Пример: запись a = 1; b = 2 может стать b = 2; a = 1, если компилятор решит, что это более эффективно.
2. Процессорное: на аппаратном уровне процессоры могут исполнять инструкции не по порядку (out-of-order execution), и также имеет место переупорядочивание видимости записей из-за store buffer. Например, на запись в переменную flag = 1 последовавшую за data = 42, другой процессор может увидеть flag = 1, но data всё ещё старым.

Модель памяти Go гарантирует, что в точках синхронизации (например, mutex.Lock()) все операции до синхронизации в одной горутине становятся видимыми в другой горутине после синхронизации, запрещая переупорядочивание через эту границу. Но внутри несинхронизированных областей переупорядочивание допустимо.

Под капотом (internals)

Go компилятор в cmd/compile/internal/ssa генерирует промежуточное представление и может переупорядочивать независимые инструкции по правилам, не нарушающим модель памяти. Он вставляет специальные барьерные операции в точках синхронизации. Процессорное переупорядочивание контролируется с помощью memory barriers: LOCK-инструкции на x86 и DMB/DSB на ARM. Например, sync.Mutex.Unlock() на ARM64 превращается в STLR (store-release), который гарантирует, что все предшествующие записи видны до освобождения блокировки.

Типичные ошибки кандидатов

• Ожидание, что запись в срез видна после простого присвоения флага: slice[0] = 42; done = true при чтении if done { println(slice[0]) } может увидеть ноль, если нет барьера. Исправление: использовать атомарный флаг или канал.
• Проверка нескольких переменных без синхронизации как «контрольной суммы»: надежда, что порядок чтения двух переменных будет соответствовать порядку записи. На ARM это не так.
• Игнорирование компиляторного переупорядочивания при бенчмарках: можно получить "слишком хорошие" результаты, потому что компилятор выкинул повторное чтение из памяти.

Возможные дополнительные вопросы интервьюера

• Может ли go build -race влиять на переупорядочивание? — Race detector инструментирует доступы, но не изменяет семантику модели памяти, только сигнализирует о гонках.
• Гарантирует ли запись в канал полный memory fence? — Отправка в небуферизированный канал гарантирует, что все операции до неё видны после получения, то есть эквивалентна полному барьеру.
• Как переупорядочивание связано с феноменом «store buffer forwarding»? — Store buffer может позволить процессору видеть собственную запись до того, как она стала видна другим ядрам; модель памяти разрешает это.

Как mutex влияет на модель памяти?

Краткий ответ

sync.Mutex создаёт отношение happens-before между Unlock() и последующим Lock() того же мьютекса. Все записи, выполненные до Unlock, становятся видимыми после успешного Lock. Это обеспечивает взаимное исключение критической секции и гарантирует согласованное состояние разделяемых данных.

Развёрнутый ответ

Модель памяти Go определяет: разблокировка мьютекса происходит до (happens before) каждой последующей блокировки того же мьютекса. Это означает:

• Поток, захвативший мьютекс, видит все изменения, сделанные предыдущим владельцем.
• Никакие операции внутри критической секции не могут «утечь» наружу ни до, ни после границ Lock/Unlock.

var mu sync.Mutex
var data string

// Горутина 1
mu.Lock()
data = "прочитай меня"
mu.Unlock()

// Горутина 2
mu.Lock()
fmt.Println(data) // гарантированно "прочитай меня"
mu.Unlock()

Без мьютекса гонка данных приводит к неопределённому поведению.

Под капотом (internals)

sync.Mutex в Go реализован как структура с полями состояния и семафором (runtime.sema). Lock() вызывает runtime.lockWithRank, который на fast-path использует атомарный CAS на state и, при неудаче, переходит к медленному пути с semacquire. Unlock() вызывает runtime.unlock, который атомарно сбрасывает бит блокировки и пробуждает ожидающие горутины через semrelease. Атомарные операции здесь имеют семантику acquire/release: Unlock выполняет store-release барьер (например, XCHG на x86 или STLR на ARM), Lock — load-acquire (через атомарное чтение). Это гарантирует, что компилятор и процессор не переупорядочат доступ через границы мьютекса.

Типичные ошибки кандидатов

• Использование мьютекса как неявного барьера для всего: иногда думают, что mu.Lock() делает видимыми записи, выполненные в других мьютексах. Это неверно, каждый мьютекс независим.
• Игнорирование копирования мьютекса: sync.Mutex нельзя копировать после использования; копия теряет внутреннее состояние. Исправление: передавать по указателю.
• Захват мьютекса и последующая запись в канал без удержания блокировки: может возникнуть инверсия приоритетов; требуется точное проектирование критических секций.
• Полагаться, что две последовательные блокировки создают общий порядок: без дополнительной синхронизации между потоками глобальный порядок Lock/Unlock не гарантирует видимость между разными парами.

Возможные дополнительные вопросы интервьюера

• Что произойдёт, если горутина разблокирует мьютекс, не захваченный ею? — Паника в sync.Mutex.Unlock.
• Как RWMutex влияет на модель памяти? — RUnlock happens-before последующий Lock, но между читателями нет синхронизации. Писатель должен дождаться всех RLock и гарантировать видимость.
• Можно ли реализовать mutex только на каналах? — Да, но использование sync.Mutex даёт лучшую производительность и является идиоматичным.

Как канал влияет на модель памяти?

Краткий ответ

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

Развёрнутый ответ

Модель памяти Go выделяет канал как синхронизирующий примитив. Конкретные правила:

1. Отправка в небуферизированный канал: отправка happens-before получение. Более того, получение happens-before завершение отправки, создавая полную синхронизацию (рандеву).
2. Отправка в буферизированный канал: отправка happens-before получение именно этого элемента (позиция k). Получение N-го элемента не синхронизировано с отправкой (N+1)-го.
3. Закрытие канала: операция закрытия happens-before получение нулевого значения после закрытия.
4. Чтение из канала: получение N-го элемента happens-before получение (N+1)-го элемента (упорядоченность в FIFO).

Таким образом, каналы предоставляют строгие гарантии и часто используются как средство для safe publication.

var data string
ch := make(chan bool)

// Горутина 1
data = "инициализация"
ch <- true

// Горутина 2
<-ch
fmt.Println(data) // гарантированно "инициализация"

Под капотом (internals)

Буферизированный канал реализован через hchan (runtime/chan.go) с кольцевым буфером, указателями send/recv и мьютексом lock. Операция отправки захватывает мьютекс, копирует данные в буфер и освобождает мьютекс. При получении мьютекс также захватывается. Мьютекс внутри канала как раз и обеспечивает happens-before: send разблокирует мьютекс (happens-before) -> receive его блокирует, срабатывает правило mutex. Для небуферизированного канала обмен происходит напрямую: планировщик передает данные без промежуточного буфера, но также через внутреннюю синхронизацию (семафоры).

Типичные ошибки кандидатов

• Публикация среза через канал и его изменение после отправки: после отправки данных по каналу горутина-получатель имеет право видеть именно те данные, которые были до отправки. Если отправитель меняет тот же срез после send, возникает гонка.
• Использование закрытия канала как сигнала без happens-before для данных: закрытие канала синхронизирует только сам факт закрытия; записи, сделанные после закрытия, не имеют отношения happens-before к получателю. Нужно писать данные до закрытия.
• Путаница с буферизированным каналом: отправка в буферизированный канал ёмкостью N не гарантирует, что получатель увидит последующие отправки в том же канале без дополнительной синхронизации. Каждая пара send/receive синхронизирована независимо.

Возможные дополнительные вопросы интервьюера

• Что произойдёт, если читать из канала после закрытия? — Читатель получит zero value, и ok=false. Модель памяти гарантирует видимость всех send до close.
• Может ли буферизированный канал нарушить причинно-следственную связь? — Нет, FIFO порядок гарантирует, что получатель видит отправленные значения в порядке отправки.
• Как обеспечить broadcast нескольким горутинам через канал? — Закрытие канала видно всем читателям. Альтернатива: sync.Cond.

Как atomic влияет на модель памяти?

Краткий ответ

Пакет sync/atomic предоставляет атомарные операции, которые являются синхронизирующими и создают отношение happens-before: запись (Store, Add, Swap, CAS) происходит до последующего чтения (Load, CompareAndSwap возвращающее значение) той же переменной. Это позволяет безопасно публиковать и синхронизировать данные без полноценных мьютексов.

Развёрнутый ответ

В Go все атомарные операции имеют семантику sequentially consistent (последовательно согласованных) по умолчанию — то есть каждая операция ведёт себя так, будто выполняется в некотором глобальном порядке. Это сильнее, чем acquire/release, и даёт простую модель: атомарная запись в переменную v делает видимыми все предыдущие записи в потоке доступа к v для любого потока, который потом прочтёт v. И наоборот, атомарное чтение v видит все записи, которые предшествуют этому значению в глобальном порядке.

Пример:

var ready atomic.Bool
var message string

// писатель
message = "hello"
ready.Store(true)

// читатель
if ready.Load() {
    fmt.Println(message) // гарантированно "hello"
}

Store(true) happens-before Load() возвращает true. Следовательно, запись message видна.

Под капотом (internals)

Атомарные операции реализованы в src/runtime/internal/atomic и src/sync/atomic. Они используют низкоуровневые инструкции: LOCK XCHG, LOCK CMPXCHG на x86, STLR/LDAR на ARM64. Эти инструкции несут с собой полные барьеры памяти, обеспечивая как атомарность, так и глобальный порядок. Компилятор Go считает такие операции неперемещаемыми барьерами. В sync/atomic для типовых целых чисел используется unsafe.Pointer и специальные функции, генерируемые в SSA. Начиная с Go 1.19, пакет atomic предоставляет типобезопасные атомарные типы (atomic.Int64 и пр.).

Типичные ошибки кандидатов

• Использование atomic.Value для структур с последующим изменением полей: сохранённое значение — копия; изменение оригинала не влияет на сохранённый объект. Нужно сохранять новый объект целиком.
• Смешивание атомарных операций с неатомарными: чтение переменной иногда атомарно, иногда нет — это гонка. Все доступы к одной переменной должны быть атомарными.
• Предположение, что atomic.Store делает все предыдущие записи видимыми для всех потоков: это работает только если читатель выполняет atomic.Load той же переменной. Без парного чтения синхронизации нет.
• Неверный паттерн double-checked locking без должного атомика: см. отдельный вопрос.

Возможные дополнительные вопросы интервьюера

• В чём разница между atomic.Store и обычным присваиванием? — Только atomic.Store гарантирует атомарность, барьер памяти и отношение happens-before; обычное присваивание нет.
• Можно ли использовать atomic.Int32 как счётчик без синхронизации? — Да, инкремент через Add(1) атомарен и создаёт happens-before для последующего чтения этого счётчика, но не синхронизирует другие данные.
• Как атомарно считать/записать указатель на большой объект? — atomic.Pointer[T] позволяет атомарно прочитать/записать указатель; для самого объекта синхронизацию нужно обеспечить отдельно.

Как создание горутины влияет на модель памяти?

Краткий ответ

Запуск новой горутины с помощью go statement создаёт отношение happens-before: все операции, выполненные до go, происходят до начала выполнения горутины. Это гарантирует, что горутина видит все данные, подготовленные перед её запуском.

Развёрнутый ответ

Модель памяти чётко устанавливает: вызов горутины (go f()) happens-before выполнение f. Таким образом, все записи в память, сделанные до go, видимы внутри горутины. Это простой и мощный механизм для передачи начальных данных без дополнительных синхронизаций.

var config *Config
config = parseConfig() // инициализация
go worker(config)      // worker гарантированно увидит config

// внутри worker(config)
func worker(c *Config) {
    // c полностью инициализирована
}

go синхронизирует только старт функции, но не её завершение. Для ожидания завершения нужны другие примитивы.

Под капотом (internals)

go statement транслируется компилятором в вызов runtime.newproc, который аллоцирует стек горутины, создаёт g структуру и помещает её в очередь планировщика. Процесс создания включает запись аргументов (в случае замыканий копируются нужные переменные) в стек новой горутины. Важный момент: аргументы функции вычисляются в текущей горутине до помещения в очередь. Таким образом, запись в стек новой горутины и публикация горутины в runqueue имеют барьер: операция записи в runqueue с release-семантикой гарантирует, что всё, что было записано до неё (в том числе инициализация аргументов), становится видимым при старте горутины. Планировщик при запуске горутины выполняет acquire-барьер, когда извлекает g из очереди.

Типичные ошибки кандидатов

• Изменение данных после запуска горутины в надежде, что горутина их увидит: горутина видит состояние на момент go, последующие изменения могут быть не видны без синхронизации.
• Передача указателя в горутину и последующая модификация по этому указателю: горутина получает копию указателя, но если исходный объект изменяется, это гонка (даже если указатель взят до go, поле может меняться после старта горутины).
• Забывают, что замыкания в цикле захватывают переменную по ссылке: классическая проблема; нужно скопировать переменную перед go.

Возможные дополнительные вопросы интервьюера

• Создаёт ли go func() {...}() happens-before для данных, переданных не через аргументы? — Да, всё, записанное до go, видно внутри горутины, независимо от способа передачи.
• Как планировщик влияет на happens-before? — Он не создаёт дополнительных гарантий, но и не нарушает существующие.
• Может ли запуск горутины быть отложен настолько, что данные изменит другая горутина? — Может, но это не влияет на гарантии: горутина увидит состояние на момент go плюс любые синхронизации, которые произошли позже (но их она увидит только если они happen-before её первую синхронизацию).

Как завершение горутины влияет на модель памяти?

Краткий ответ

Завершение горутины само по себе не создаёт happens-before с другими горутинами. Единственный способ гарантировать видимость её записей после окончания — использовать синхронизирующие примитивы: sync.WaitGroup, каналы, мьютексы и т.д. Без явной синхронизации завершение горутины не передаёт никаких гарантий.

Развёрнутый ответ

В модели памяти Go нет утверждения, что завершение горутины происходит до какого-либо события в другой горутине. Если горутина завершилась, сделав запись x = 1, а основная горутина продолжает выполнение и читает x, без дополнительной синхронизации чтение может увидеть ноль. Нельзя полагаться на тот факт, что «горутина уже закончилась», чтобы считать её записи видимыми.

Пример:

var x int
go func() {
    x = 42
}()
// ... без синхронизации ...
fmt.Println(x) // может напечатать 0

Исключением является идиома с sync.WaitGroup: wg.Done() происходит до возврата wg.Wait(), что и создаёт синхронизацию.

Под капотом (internals)

Рантайм Go при завершении горутины вызывает runtime.goexit -> goexit1 -> mcall(goexit0), где освобождается стек, и g помещается в список свободных горутин или gFree. В этом процессе отсутствуют какие-либо глобальные барьеры, публикующие записи. Единственный возможный неявный «барьер» — когда планировщик позже переключает контекст, но это не даёт гарантий, т.к. планировщик не выполняет полный fence при переключении.

Типичные ошибки кандидатов

• Ожидание, что time.Sleep после go гарантирует видимость: завершение горутины за время сна не делает её записи видимыми. Нужна синхронизация.
• Конструирование пула горутин, где завершение используется как признак завершения задачи: это недопустимо; требуется канал или sync.WaitGroup.
• Использование runtime.Gosched для «передачи» данных: Gosched не создаёт happens-before и не гарантирует видимость.

Возможные дополнительные вопросы интервьюера

• Можно ли детектировать завершение горутины? — Только явно через канал или sync.WaitGroup. Рантайм не предоставляет API для этого.
• Как синхронизировать выход горутины с основной? — Правильно: done <- true перед выходом, или wg.Done().
• Что делает runtime.Goexit и даёт ли он синхронизацию? — Он завершает горутину, но не публикует её записи, поэтому синхронизация всё равно нужна.

Как sync.WaitGroup влияет на модель памяти?

Краткий ответ

sync.WaitGroup предоставляет отношение happens-before: вызовы wg.Done() происходят до возврата из wg.Wait(). Это позволяет безопасно дожидаться завершения набора горутин и делать их записи видимыми после Wait.

Развёрнутый ответ

Модель памяти определяет: вызов Add с положительным дельтой, затем набор вызовов Done (каждый уменьшает счётчик) и, наконец, возврат Wait при достижении нуля. .Done() эквивалентен Add(-1). Все Done в совокупности происходят до возврата Wait. Значит, все записи, сделанные до любого Done, видны после Wait.

var wg sync.WaitGroup
var result string

wg.Add(1)
go func() {
    defer wg.Done()
    result = "готово"
}()
wg.Wait()
fmt.Println(result) // гарантированно "готово"

Важно, что Add должно вызываться до запуска горутины, чтобы избежать гонки между Add и Wait.

Под капотом (internals)

sync.WaitGroup использует внутреннее состояние, состоящее из счётчика и семафора (runtime.sema). При Done счётчик декрементируется атомарно (используя sync/atomic). Когда счётчик достигает нуля, вызывается runtime.semrelease, который пробуждает все ожидающие горутины в Wait. Wait блокируется на runtime.semacquire. Именно атомарный переход к нулю и последующий semrelease обеспечивают release-семантику, а semacquire — acquire-семантику. Таким образом, все записи до Done становятся видимыми после Wait.

Типичные ошибки кандидатов

• Вызов wg.Add внутри горутины после wg.Wait в основной горутине: это приводит к гонке, т.к. Wait может вернуться до того, как Add увеличит счётчик. Add всегда нужно вызывать в стартующей горутине или до go.
• Повторное использование WaitGroup без обнуления: после возврата Wait можно снова вызывать Add, но только когда гарантировано, что предыдущий Wait завершился. Ошибка — добавлять новые задачи во время выполнения Wait.
• Забывают, что Done должен вызываться ровно столько раз, сколько было добавлено: лишние вызовы вызывают панику «negative WaitGroup counter».

Возможные дополнительные вопросы интервьюера

• Можно ли использовать WaitGroup для ограничения параллельности? — Только косвенно, если добавлять перед запуском горутины и Wait в нужный момент; обычно используют семафор.
• Как правильно передать WaitGroup горутине? — Только по указателю, копирование приводит к независимым счётчикам и дедлокам.
• В чём отличие sync.WaitGroup от канала с ожиданием? — WaitGroup специализирован для ожидания завершения группы горутин, тогда как канал более гибок (можно передать значение). WaitGroup проще и быстрее.

Как sync.Once влияет на модель памяти?

Краткий ответ

sync.Once гарантирует, что переданная функция выполняется ровно один раз, и все вызовы Do после завершения этой функции видят её побочные эффекты. Once создаёт отношение happens-before: вызов функции, выполняемой внутри Do, происходит до возврата из любого последующего Do.

Развёрнутый ответ

Модель памяти гласит: когда Do завершается, все вызовы Do после этого момента видят результат выполнения функции, а сама функция (если выполнилась) happens-before эти последующие вызовы. Внутренне sync.Once использует атомарные операции и мьютекс, чтобы гарантировать, что функция запускается только один раз, и её эффекты становятся видимыми после завершения.

var once sync.Once
var config *Config

func getConfig() *Config {
    once.Do(func() {
        config = loadConfig()
    })
    return config
}

Любой вызов getConfig() после первого успешного Do вернёт инициализированный config, и все поля будут видны.

Под капотом (internals)

Структура sync.Once содержит атомарный флаг done и sync.Mutex. Do выполняет быстрое атомарное чтение done. Если 0, входит в медленный путь, захватывает мьютекс и выполняет функцию. После выполнения устанавливает done = 1 с помощью Store (release). Любые последующие атомарные загрузки done (acquire) увидят 1, и выполнится барьер памяти, обеспечивающий видимость записей из функции. Таким образом, Once использует double-checked locking, но правильным образом, с атомарным флагом и мьютексом.

Типичные ошибки кандидатов

• Попытка реализовать свой Once через обычную булеву переменную: это не работает из-за отсутствия happens-before. Исправление: всегда используйте sync.Once.
• Паника внутри функции Once: если функция паникует, Once считает её выполненной (флаг не сбрасывается), и последующие вызовы Do немедленно возвращаются, не перезапуская инициализацию. Это может оставить ресурсы в неопределённом состоянии. Решение: защищать от паник и восстанавливать логику.
• Долгое выполнение функции Once при старте приложения: блокирует всех вызывающих и может привести к длительной задержке. Лучше инициализировать вне Once или использовать chan для асинхронной инициализации.

Возможные дополнительные вопросы интервьюера

• Можно ли использовать sync.Once для инициализации нескольких объектов? — Да, создайте отдельную структуру с полями, инициализируемую функцией.
• Как sync.Once соотносится с init()? — init() выполняется при загрузке пакета гарантированно до main, но не подходит для ленивой инициализации. Once для ленивой идиомы.
• Гарантирует ли Once видимость в случае, если Do вызван параллельно из многих горутин? — Да, к моменту возврата из Do побочные эффекты видны всем.

Как sync.Cond влияет на модель памяти?

Краткий ответ

sync.Cond позволяет горутинам ожидать наступления события. Вызов Wait атомарно разблокирует связанный мьютекс и приостанавливает горутину; после пробуждения и повторного захвата мьютекса он имеет ту же семантику, что и обычный Lock. Signal и Broadcast не создают happens-before сами по себе, но в сочетании с захватом мьютекса обеспечивают корректную синхронизацию: состояние, записанное под мьютексом до Signal, будет видно после Wait и возврата из Wait.

Развёрнутый ответ

Модель памяти Go для sync.Cond опирается на правила мьютекса. Типичный идиоматический шаблон:

var mu sync.Mutex
cond := sync.NewCond(&mu)
var ready bool

// горутина, устанавливающая условие
mu.Lock()
ready = true
mu.Unlock()
cond.Signal() // или Broadcast

// ожидающая горутина
mu.Lock()
for !ready {
    cond.Wait() // атомарно mu.Unlock() + ожидание + mu.Lock()
}
// здесь ready == true, и видна запись ready
mu.Unlock()

Wait внутри: горутина разблокирует мьютекс (release), засыпает на семафоре; когда пробуждается, захватывает мьютекс (acquire). Поскольку сигналящая горутина сделала запись до Unlock, а Unlock happens-before последующий Lock в ожидающей горутине, запись видна. Также Signal пробуждает ожидающего, и тот после пробуждения вновь захватывает мьютекс, завершая цепочку.

Под капотом (internals)

sync.Cond содержит список ожидающих горутин (sudog) и мьютекс. Wait добавляет текущую горутину в список, разблокирует L, вызывает runtime.semacquire. Signal извлекает одну горутину и вызывает runtime.semrelease на её семафоре. После пробуждения горутина в Wait снова блокирует L. Этот Lock обеспечивает acquire-барьер после return из Wait, подхватывая все записи, сделанные сигналящей горутиной перед Unlock и сигналом.

Типичные ошибки кандидатов

• Вызов cond.Wait() без удерживаемого мьютекса: вызывает панику. Мьютекс должен быть захвачен перед Wait.
• Проверка условия без цикла: сигнал мог быть потерян из-за ложного пробуждения (spurious wakeup) или из-за того, что пробудившаяся горутина не является целевой. Всегда проверяйте условие в цикле.
• Использование Signal без захвата мьютекса: хотя формально допустимо, но может привести к пропуску пробуждения, если ожидающая горутина ещё не вошла в ожидание. Обычно Signal вызывается под тем же мьютексом, что и ожидание.

Возможные дополнительные вопросы интервьюера

• Чем sync.Cond отличается от каналов? — Cond позволяет ожидать произвольного условия и пробуждать несколько горутин (Broadcast), каналы — передавать сообщения. Cond более низкоуровневый.
• Когда стоит использовать Cond вместо каналов? — Когда нужно, чтобы несколько горутин просыпались по одному условию, или условие сложное и неудобно выражается через канал.
• Что будет, если Signal вызван до Wait? — Сигнал пропадёт, если нет ожидающих. Чтобы избежать потери, обычно сигнал посылают под мьютексом, гарантируя, что ожидающий уже ждёт или ещё не ждёт, но условие установлено.

Как sync.Map влияет на модель памяти?

Краткий ответ

sync.Map гарантирует безопасную конкурентную работу с хранимыми парами ключ-значение, создавая отношение happens-before между операциями Store и соответствующими Load, а также внутри методов LoadOrStore и Delete. Доступ к каждому ключу синхронизирован через внутренние мьютексы или атомарные операции, благодаря чему Load видит результат последнего Store, происходящего до него в порядке синхронизации.

Развёрнутый ответ

Модель памяти для sync.Map описана в документации: метод Store (или LoadOrStore при добавлении нового значения) происходит до любого Load, который видит это сохранённое значение, для данного ключа. Это обеспечивает видимость побочных эффектов при обновлении. Однако sync.Map не гарантирует общий happens-before между разными ключами без дополнительной синхронизации.

var m sync.Map
m.Store("k", "v")
// ...
val, ok := m.Load("k")
if ok {
    fmt.Println(val) // "v" гарантированно
}

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

Под капотом (internals)

sync.Map реализован как двухуровневое хранилище: read-only map (атомарный доступ) и dirty map, защищённый sync.Mutex. При Store мьютекс захватывается при необходимости продвижения dirty. Операции чтения из read map без блокировки, используя атомарное чтение. Когда нужна запись или продвижение, используется мьютекс, создающий happens-before по правилам sync.Mutex между несколькими потоками. Сами пары ключ-значение хранятся как атомарные указатели на entry, что позволяет атомарно обновлять значение без полной блокировки, но для установления отношения happens-before между Store и Load используются атомарные записи/чтения entry.

Типичные ошибки кандидатов

• Предположение о глобальной синхронизации: sync.Map синхронизирует только операции с конкретным ключом. Если одна горутина сохраняет по ключу A, а другая читает по ключу B, между ними нет happens-before. Исправление: внешняя синхронизация для межключевых зависимостей.
• Хранение в sync.Map мутируемых объектов: sync.Map гарантирует видимость только ссылки на объект, но не полей объекта. Изменение полей после Store может привести к гонке. Нужно либо хранить неизменяемые объекты, либо защищать их отдельно.
• Использование Range с долгими операциями: Range удерживает внутренний мьютекс (в медленном пути), что может блокировать запись. Лучше быстро обработать итерацию или освободить блокировку, копируя карту во временный срез.

Возможные дополнительные вопросы интервьюера

• Когда предпочесть sync.Map обычной мапе с мьютексом? — Когда имеется много операций чтения и относительно мало записей, и ключи стабильны со временем. В сценариях с интенсивной записью обычная map+Mutex может быть эффективнее.
• Как sync.Map избегает гонок при обновлении значения? — Использует атомарный указатель на entry, что позволяет атомарно заменять значение без блокировки; мьютекс используется только для операций с отсутствующим ключом.
• Гарантирует ли sync.Map упорядоченность между последовательными Store и Load в одной горутине? — Да, в пределах одной горутины программный порядок соблюдается, и Load после Store возвращает записанное значение.

Как sync.Pool влияет на модель памяти?

Краткий ответ

sync.Pool предоставляет временное хранилище объектов, но операции Put и Get не создают отношения happens-before. Пул не гарантирует, что после Put данные, записанные в объект, будут видны при последующем Get. Для безопасной передачи данных через пул необходима дополнительная синхронизация.

Развёрнутый ответ

Модель памяти Go явно указывает: Put и Get пула не являются синхронизирующими операциями. Это означает, что если горутина помещает объект в пул, а другая извлекает его, нет гарантии, что изменения, сделанные первой горутиной внутри объекта, будут видны второй. Пул предназначен исключительно для переиспользования памяти, а не для передачи состояния. Любые поля объекта, которые до Put были инициализированы, могут оказаться «грязными» при Get в другом потоке.

var buf bytes.Buffer
buf.Reset()
pool.Put(&buf) // Не создаёт happens-before

// другая горутина:
b := pool.Get().(*bytes.Buffer)
b.WriteString("hello") // потенциальная гонка с предыдущим владельцем

Однако sync.Pool имеет слабую гарантию, что объект, переданный в Put, может быть получен тем же P (процессором планировщика) без синхронизации из-за локального кэша, но это не является гарантией видимости.

Под капотом (internals)

sync.Pool реализован с привязкой к P (контексту планировщика). У каждого P есть локальный пул (private). Get сначала проверяет локальный пул, затем общий. Put также кладёт в локальный пул. При этом не используются атомарные барьеры для синхронизации данных внутри объекта; используется только быстрое атомарное управление указателями на структуры пула. Поскольку структуры кладутся/извлекаются из локального пула без mfence, никакого happens-before нет. GC может периодически очищать содержимое пулов, удаляя объекты без предупреждения.

Типичные ошибки кандидатов

• Публикация данных через sync.Pool: надежда, что Put(x); Get() передаёт состояние x. Неверно; состояние может быть потеряно или невидимо. Нужно использовать каналы или другие примитивы.
• Изменение объекта после Put: после Put объект больше не принадлежит горутине, но если она сохранила ссылку и меняет его — гонка. Всегда «забывайте» объект после Put.
• Предположение, что New-функция вызывается при каждом Get: New вызывается только если пул пуст; в противном случае может быть возвращён ранее использованный объект с произвольным содержимым. Необходимо сбрасывать состояние.

Возможные дополнительные вопросы интервьюера

• Как гарантировать, что объект из пула чистый? — Предоставить метод Reset() и вызывать его сразу после Get, а также перед Put, чтобы не хранить мусор.
• Почему sync.Pool не гарантирует happens-before? — Из-за ориентированности на производительность, пул минимизирует барьеры, полагаясь на локальные кэши процесса планировщика.
• Можно ли использовать sync.Pool для кэширования конфигураций? — Нет, он не предназначен для постоянного хранения; GC может очистить пул в любой момент.

Какие операции являются синхронизирующими (synchronizing)?

Краткий ответ

Синхронизирующими операциями в Go являются те, которые порождают отношение happens-before: sync.Mutex.Lock/Unlock, sync.RWMutex, отправка/получение из канала, атомарные операции sync/atomic, sync.WaitGroup, sync.Once, создание горутины (go), а также sync.Cond.Wait (в связке с мьютексом). Полный перечень описан в спецификации Go Memory Model.

Развёрнутый ответ

Синхронизирующие операции — это кирпичики, из которых строится конкурентный код с гарантированной видимостью. Список:

• Инициализация пакета (init) — все init-функции пакета завершаются до main (happens-before).
• go func() — запуск горутины happens-before её выполнение.
• Закрытие канала — happens-before получение нулевого значения.
• Отправка/получение из канала (небуферизированного и k-я отправка в буфере до k-го получения).
• Любая операция с мьютексом: Unlock happens-before последующий Lock.
• sync.WaitGroup.Done happens-before возврат из Wait.
• sync.Once.Do(func) — выполнение func происходит до возврата из любого последующего Do.
• Атомарная запись и атомарное чтение одного и того же атомарного значения.
• sync.Cond.Wait после возврата (с повторным захватом мьютекса) — видит всё, что сделано сигналящей горутиной до Unlock+Signal.

Несинхронизирующие: обычное присваивание, time.Sleep, runtime.Gosched, sync.Pool.Put/Get, вызов fmt.Println.

Под капотом (internals)

Каждая синхронизирующая операция в рантайме вызывает ту или иную форму барьера памяти. Например, runtime.semrelease (release) и runtime.semacquire (acquire) реализованы через атомарные инструкции с барьерами. Планировщик заботится о том, что при передаче управления от одной горутины к другой происходит необходимый барьер посредством атомарных операций над runqueue.

Типичные ошибки кандидатов

• Считать atomic.CompareAndSwap безусловно синхронизирующим: только успешный CAS (или любой CAS в паре) обеспечивает синхронизацию; неудачный CAS не создаёт happens-before, если только по нему не строится acquire/release.
• Путаница между синхронизирующей операцией и блокировкой: блокировка (спинлок) не даёт синхронизации без атомика.
• Использование sync/atomic для защиты сложного инварианта: атомарные операции синхронизируют только само атомарное значение; сложные инварианты требуют мьютекса или нескольких атомарных с корректными зависимостями.

Возможные дополнительные вопросы интервьюера

• Является ли sync.Map.Load синхронизирующим? — Да, в паре с Store для того же ключа.
• Что будет, если смешать синхронизирующие и несинхронизирующие доступы к одной переменной? — Гонка данных, неопределённое поведение.
• Можно ли считать close(ch) синхронизирующей операцией для данных, записанных после закрытия? — Нет, только отправки до закрытия синхронизированы с получением после.

Может ли компилятор переупорядочить операции до и после Mutex.Unlock?

Краткий ответ

Нет, компилятор не может переместить операцию, находящуюся внутри критической секции, за Unlock, или внешнюю операцию — внутрь. Unlock имеет семантику release-барьера, запрещающую переупорядочивание записей вниз, а Lock — acquire-барьер, запрещающий перемещение чтений вверх.

Развёрнутый ответ

Модель памяти Go гарантирует, что все операции, записанные до Unlock, происходят до операций после Lock в другой горутине. Чтобы обеспечить это, компилятор и процессор не могут переупорядочить записи через Unlock. Аналогично, Lock препятствует тому, чтобы чтения после Lock были выполнены до него. Это достигается вставкой специальных инструкций (memory barriers) при компиляции.

x = 42
mu.Unlock()
// Не может стать: mu.Unlock(); x = 42

Ассемблерный output для ARM64 покажет STLR (store-release) для Unlock, который гарантирует, что все предшествующие записи завершены до видимости разблокировки. Оптимизатор SSA в Go помечает такие операции как имеющие «ordering», запрещая их перемещение.

Под капотом (internals)

В SSA-бэкенде компилятора Go операции OpAtomicStore, используемые для Unlock, имеют флаг HasSideEffects и включены в класс барьеров. При планировании инструкций они действуют как точки «до» и «после» которых операции не пересекаются. На x86 Unlock использует XCHG с полным барьером, который также не допускает переупорядочивания. Компилятор также не может перенести вызов Unlock выше по коду из-за модели памяти.

Типичные ошибки кандидатов

• Думают, что компилятор всё же может переупорядочить для оптимизации: это неверно, так как нарушило бы гарантии модели памяти для корректных программ без гонок. Компилятор Go консервативен и следует спецификации.
• Предполагают, что только мьютекс запрещает переупорядочивание, а атомарные операции могут быть перемещены: атомарные Store и Load также являются барьерами.
• Проверяют только ассемблерный листинг x86, где и так сильный порядок, и делают неверные выводы о других платформах: на ARM без барьера возможны реордеринги.

Возможные дополнительные вопросы интервьюера

• Что насчёт sync.RWMutex.Unlock? — Аналогично, RUnlock не запрещает переупорядочивание с последующими чтениями, но Lock писателя запрещает.
• Можно ли создать ситуацию, где компилятор всё же переупорядочит через Unlock? — Только при наличии гонки данных, но это уже некорректная программа.
• Как убедиться, что реордеринг отсутствует? — Использовать go run -race и инструменты анализа машинного кода.

Что такое "DRF-SC" (Data-Race-Free Sequential Consistency)?

Краткий ответ

DRF-SC (Data-Race-Free Sequential Consistency) — это гарантия, предоставляемая моделью памяти Go: если программа не содержит гонок данных, то её выполнение эквивалентно некоторому чередованию операций всех горутин в последовательном порядке (sequentially consistent). Иными словами, разработчик может думать, что горутины исполняются по очереди, сохраняя порядок операций каждой горутины.

Развёрнутый ответ

DRF-SC — золотой стандарт моделей памяти современных языков (C++11, Java, Go). Свойство означает:

1. Если программа свободна от гонок данных (data race free) — то есть все конкурентные доступы разделены синхронизацией — поведение программы соответствует некоторому чередованию инструкций, при котором каждая горутина выполняет свои операции в исходном порядке (program order), а операции разных горутин чередуются.
2. Это позволяет программисту рассуждать о программе, абстрагируясь от низкоуровневых реордерингов.
3. Если же в программе есть гонка данных, модель памяти не даёт никаких гарантий, и программа может демонстрировать поведение, невозможное ни при каком последовательном чередовании.

Пример корректной программы: две горутины захватывают один и тот же мьютекс перед доступом к общей переменной — программа DRF, следовательно, ведёт себя предсказуемо, как если бы операции выполнялись в некотором порядке.

Под капотом (internals)

Для обеспечения DRF-SC компилятор и процессор должны гарантировать, что в отсутствие гонок реордеринги не приводят к наблюдению не-seq-согласованного поведения. Это делается вставкой барьеров в синхронизирующих точках. Рантайм полагается на свойства процессора: на x86 базовая модель памяти достаточно сильная, чтобы многие программы работали без явных барьеров (но компилятор всё равно может переупорядочить). На ARM активно используются acquire/release инструкции. DRF-SC подразумевает, что оптимизации разрешены, пока они не меняют наблюдаемое поведение seq-cons в программах без гонок.

Типичные ошибки кандидатов

• Утверждение, что Go гарантирует sequential consistency всегда: нет, только для программ без гонок. Гонка разрушает последовательную согласованность.
• Попытка использовать гонку как способ синхронизации: недопустимо, компилятор может удалить или переупорядочить доступы.
• Считать, что DRF-SC относится только к языку Go: это общая концепция, принятая и в других языках; в Go она является основой модели.

Возможные дополнительные вопросы интервьюера

• Что произойдёт, если программа имеет гонку, но она «выглядит» как последовательное выполнение? — Это случайное совпадение, которое может сломаться при смене версии компилятора или платформы; программа некорректна.
• Как связаны DRF-SC и happens-before? — Happens-before — механизм для доказательства отсутствия гонок; если все конфликтующие доступы упорядочены, программа DRF.
• Можно ли ослабить модель до release/acquire? — В Go нет способа изменить модель для атомарных операций — все они seq-cons.

Как happens-before гарантирует причинно-следственную связь?

Краткий ответ

Happens-before гарантирует, что если событие A является причиной события B (A порождает данные, используемые B), то между ними существует цепочка синхронизирующих операций, которая делает A видимым для B. Таким образом, соблюдается причинно-следственная согласованность: следствие всегда наблюдает причину.

Развёрнутый ответ

В распределённых и многопоточных системах причинность означает, что информация не может передаваться быстрее, чем через цепь событий. Модель памяти Go строит причинность через happens-before: если запись W причинно влияет на чтение R (например, через сигнал по каналу), то W happens-before R, и R увидит W. Без этого причинность могла бы нарушиться — например, R видит устаревшие данные, что противоречит интуиции.

Разработчик, использующий каналы и мьютексы, неявно выстраивает причинно-следственные цепочки. Каждый ch <- val — это отправка причинного сообщения; получатель, выполнив <-ch, гарантированно видит все предыдущие записи отправителя. Это принцип, на котором строятся идиома «канал как обещание».

Под капотом (internals)

Причинность поддерживается за счёт того, что барьеры памяти распространяют не только значение, но и все предшествующие записи. При release-семантике все записи до release видны при acquire. Поэтому если A записал x, потом отправил в канал, а B прочитал из канала, то B видит x — это как раз причинная связь «A вычислил x, B использует x». Железные протоколы когерентности кэшей (MESI) гарантируют, что запись, ставшая видимой одному ядру, становится видимой другим при условии выполнения барьеров.

Типичные ошибки кандидатов

• Нарушение причинности при использовании атомиков: если атомарная операция не синхронизирует побочные данные, может возникнуть ситуация, когда флаг увиден, а данные — нет. Нужно следить, чтобы все причинно-зависимые данные были записаны до атомарного store.
• Предположение причинности через time: «раз прошло 10 мс, то запись уже видна». Нет, без синхронизации причинность не гарантируется.
• Использование нескольких каналов без порядка: если нет общих точек синхронизации, горутины могут видеть причинно-несвязанные события в разном порядке, но это уже не нарушает причинность конкретной цепочки.

Возможные дополнительные вопросы интервьюера

• Как бы вы реализовали логический Lamport clock в Go? — Через атомарный счётчик и передачу его через каналы; значение счётчика передавать по каналу, и получатель обновляет свой максимум.
• Может ли случиться, что A happens-before B, но B не видит запись C, которая произошла до A? — Нет, если C происходит до A, то C happens-before B (транзитивность). Всё работает.
• Как причинность помогает в распределённых системах? — Аналогично, мы используем синхронизацию для передачи причинных зависимостей.

Что такое "sequentially consistent" и "relaxed" атомарные операции?

Краткий ответ

Последовательно согласованные (sequentially consistent, SC) атомарные операции создают единый глобальный порядок всех таких операций, видимый всем потокам. Relaxed (ослабленные) операции гарантируют только атомарность, но не создают никаких happens-before отношений и могут переупорядочиваться. В Go все атомарные операции являются последовательно согласованными.

Развёрнутый ответ

В модели C++11 доступны разные memory_order для атомарных операций: memory_order_relaxed, acquire, release, seq_cst. В Go разработчик лишён выбора — единственный режим соответствует seq_cst. Это означает:

• Каждая атомарная операция в Go видима всем потокам в некотором глобальном порядке.
• Если store(1) в одной горутине и store(2) в другой, то все горутины увидят одну и ту же последовательность этих store (какой бы порядок ни сложился). Relaxed мог бы позволить разным горутинам наблюдать разный порядок.
• SC проще для рассуждений, но дороже на некоторых архитектурах (нужен полный барьер памяти).

Пример: atomic.AddInt32(&x, 1) и atomic.LoadInt32(&x) взаимодействуют в глобальном порядке. Нельзя получить ситуацию, когда один поток видит инкремент, но не видит предыдущие изменения, которые видны другому потоку (как в relaxed).

Под капотом (internals)

На x86 обычные атомарные операции с LOCK-префиксом уже являются SC за счёт архитектуры. На ARM64 операции LDAR (load-acquire) и STLR (store-release) обеспечивают только acquire/release. Чтобы получить SC, Go добавляет DMB ISH (Data Memory Barrier) перед загрузками и после сохранений, что приводит к полным барьерам. Это отражается в sync/atomic функциях, генерируемых компилятором.

Типичные ошибки кандидатов

• Попытка воспроизвести relaxed поведение в Go: нельзя; все атомарные операции в Go SC.
• Смешивание атомарных и неатомарных доступов: чтение переменной без atomic после атомарного store приводит к гонке, даже если store был SC — потому что обычное чтение не является acquire.
• Неправильное ожидание, что SC дает глобальный порядок для всех операций в программе: SC охватывает только сами атомарные операции, не неатомарные.

Возможные дополнительные вопросы интервьюера

• Почему Go выбрал только sequentially consistent? — Для простоты и предсказуемости, устраняя целый класс сложных ошибок с memory ordering.
• Есть ли способ эмулировать relaxed в Go? — Нет, и это намеренно. При необходимости обходиться атомиками с SC.
• Какое влияние SC оказывает на производительность lock-free структур? — Требует дополнительных барьеров, что может снизить производительность на ARM; разработчик должен это учитывать.

Как модель памяти Go соотносится с моделями памяти C++11 и Java?

Краткий ответ

Все три модели базируются на DRF-SC и концепции happens-before. Go проще: её атомарные операции только sequentially consistent, нет выбора memory ordering. В Java и C++ разработчик может выбирать relaxed, acquire/release и другие режимы, что даёт больше контроля над производительностью, но увеличивает сложность. Также в Go синхронизирующими операциями являются каналы и sync примитивы, в то время как в C++/Java полагаются на mutex, volatile (Java) и std::atomic.

Развёрнутый ответ

Общие черты:

• DRF-SC гарантируется.
• Базовые happens-before через мьютексы, атомарные операции.
• Компиляторные оптимизации ограничены моделью.

Отличия:

1. Memory ordering selection: C++11 и Java предлагают несколько уровней (relaxed, acquire, release, acq_rel, seq_cst). Go предлагает только seq_cst. Это упрощает модель, но может вызвать избыточные барьеры.
2. Синхронизирующие примитивы: В Go каналы — первоклассный механизм с чёткими гарантиями happens-before. В Java похожие гарантии можно получить через BlockingQueue, но она основана на ReentrantLock и Condition.
3. Volatile: в Java есть volatile переменные с семантикой acquire/release. Go предлагает atomic, который гораздо более явно выражает намерения.
4. Финализаторы: в Java модель памяти определяет happens-before для finalizer, в Go модель для финализаторов более слабая и не является синхронизирующей.
5. Инициализация: в Java final поля в конструкторе имеют особое отношение happens-before (freeze action). В Go инициализация через sync.Once или init.

Под капотом (internals)

C++ модель транслируется в архитектурные барьеры в соответствии с выбранным memory_order. Java использует похожие механизмы. Go компилятор встраивает полные барьеры для всех атомарных операций на слабых архитектурах. На x86 для acquire/release не требуется дополнительных инструкций, но компилятор всё ещё может переупорядочить код; Go компилятор всё равно не использует эту гибкость, вставляя явные LOCK-префиксные инструкции или XCHG.

Типичные ошибки кандидатов

• Перенос привычек из C++ memory_order_relaxed в Go: пытаются использовать грязные трюки, которые не работают, потому что нет relaxed.
• Сравнение sync.Mutex в Go с std::mutex в C++ без учёта, что std::mutex обеспечивает acquire/release, а Go mutex — примерно то же самое.
• Использование sync/atomic для организации lock-free структуры без осознания, что SC-гарантии сильнее, чем нужно, и может быть избыточным.

Возможные дополнительные вопросы интервьюера

• Как Go модель памяти повлияла на дизайн каналов? — Каналы требуют чётких гарантий happens-before для безопасной передачи данных; модель памяти была спроектирована так, чтобы обеспечить эти гарантии эффективно.
• Можно ли получить поведение volatile в Go? — Да, через атомарные операции, но это будет SC, а не просто acquire/release.
• Почему Go отказался от support relaxed memory ordering? — Ради уменьшения когнитивной нагрузки и предотвращения тонких багов.

Как работает atomic.CompareAndSwap и какую гарантию видимости он дает?

Краткий ответ

atomic.CompareAndSwap (CAS) атомарно сравнивает значение в переменной с ожидаемым old, и если совпадает, заменяет на new. В Go успешный CAS создаёт синхронизацию, аналогичную последовательной store, и последующее атомарное чтение этой переменной увидит new. CAS также возвращает true/false. Успешный CAS обеспечивает happens-before для последующих Load той же переменной; неудачный CAS не создаёт синхронизационных гарантий, кроме атомарности.

Развёрнутый ответ

CAS — основа для построения lock-free алгоритмов. Модель памяти Go считает CAS (как Swap и Store) записью: если CAS проходит успешно, он порождает happens-before для последующего атомарного чтения этой переменной. Это значит, что все записи, предшествующие CAS в той же горутине, становятся видимыми для горутины, которая сделает Load после этого CAS и увидит новое значение.

Неудачный CAS не изменяет переменную, поэтому не создаёт новую синхронизацию, но он всё равно является атомарным чтением с acquire-семантикой? На самом деле, в Go CAS всегда имеет семантику acquire/release: он одновременно читает (acquire) и, при успехе, пишет (release). Однако если он провалился, запись не производится, и release не происходит. Тем не менее, acquire-часть CAS (чтение) гарантирует, что последующие чтения из атомарной переменной или из зависимых данных увидят как минимум те значения, которые были видны на момент этого CAS.

Под капотом (internals)

На x86 реализовано через LOCK CMPXCHG, который атомарен и обладает полным барьером памяти. На ARM64 используется последовательность инструкций LDXR / STXR (эксклюзивный доступ) с барьером. STXR представляет release-семантику, если операция успешна. Go runtime функция internal/runtime/atomic.Cas гарантирует правильные memory clobber.

Типичные ошибки кандидатов

• Использование CAS как простого условного store без учета синхронизации: думают, что если CAS провалился, то ничего не изменилось и предыдущие записи всё равно видны. Но без синхронизации может не быть видимости. Нужно в цикле CAS с загрузкой перед попыткой, используя атомарные операции для всех чтений.
• Создание lock-free структуры на CAS без учета ABA-проблемы: CAS может пропустить промежуточные изменения; в Go для указателей нужно использовать tagged pointers или unsafe.Pointer с дополнительными поколениями.
• Попытка синхронизировать неатомарные данные только через успешный CAS: да, работает, потому что успешный CAS — это synch-запись, а последующий Load создаст acquire.

Возможные дополнительные вопросы интервьюера

• Почему CAS в цикле требует Load внутри цикла? — Чтобы получить ожидаемое значение актуальным с правильной acquire-семантикой.
• Чем CAS отличается от Swap? — Swap всегда записывает новое значение и возвращает старое, создавая синхронизацию в любом случае.
• Какая гарантия видимости у atomic.Value.CompareAndSwap? — Аналогично, успешный CAS создаёт happens-before с последующими Load.

Что такое "происходит до" (happens before) при отправке в буферизированный канал?

Краткий ответ

Отправка k-го элемента в буферизированный канал происходит до получения этого же k-го элемента. Это означает, что получатель k-го значения видит все записи, сделанные отправителем до отправки этого элемента. Отправка (k+1)-го элемента не синхронизирована с получением k-го.

Развёрнутый ответ

Модель памяти Go уточняет: буферизированный канал синхронизирует отправку и соответствующее получение. Индекс элемента важен: если отправлено три значения, первое получение синхронизировано с первой отправкой, второе — со второй и т.д. Получатель видит всё, что отправитель сделал до отправки конкретного элемента.

ch := make(chan int, 2)
var data string
go func() {
    data = "first"
    ch <- 1   // отправка 1-го
    data = "second"
    ch <- 2   // отправка 2-го
}()
time.Sleep(time.Millisecond) // только для порядка
fmt.Println(<-ch) // получаем 1, data гарантированно "first" или "second"? 

Важно: после получения <-ch (первый элемент) видна запись data = "first", но не data = "second", потому что получение первого синхронизировано с первой отправкой, которая происходит до присвоения "second". Если сначала получить второй элемент (порядок FIFO не гарантирует, но на практике FIFO), то увидим "second".

Под капотом (internals)

Буферизированный канал использует внутренний sync.Mutex (поле lock в hchan). При отправке мьютекс захватывается, данные копируются в буфер (индекс sendx), затем освобождается. При получении мьютекс также захватывается, данные читаются с recvx. Happens-before: разблокировка мьютекса при отправке происходит до блокировки того же мьютекса при получении того же самого элемента (получение захватывает тот же мьютекс после того, как отправка его освободила). Это повторяет правила мьютекса. Отправка и получение разных элементов не гарантируют синхронизации, так как они оперируют с разными unlock/lock, но FIFO-порядок гарантирует, что получение происходит в порядке отправки.

Типичные ошибки кандидатов

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

Возможные дополнительные вопросы интервьюера

• Что будет, если ёмкость канала равна 0? — Небуферизированный канал, синхронизация иная: отправка и получение непосредственно синхронизированы друг с другом.
• Можно ли использовать буферизированный канал для построения семафора? — Да, но синхронизация при получении будет по описанным правилам.
• Влияет ли закрытие буферизированного канала на синхронизацию неполученных элементов? — Закрытие не создаёт дополнительной синхронизации для уже отправленных элементов сверх уже существующей.

Как происходит "синхронизация" через sync.Mutex?

Краткий ответ

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

Развёрнутый ответ

Подробно механизм: горутина A изменяет общие данные, затем вызывает mu.Unlock(). Этот Unlock содержит release-барьер. Затем горутина B вызывает mu.Lock(), который содержит acquire-барьер. Приобретение мьютекса заставляет B увидеть всё, что A записала до Unlock. Более того, последующий Unlock горутиной B создаст барьер для следующего владельца.

var counter int
var mu sync.Mutex

// G1
mu.Lock()
counter++
mu.Unlock()

// G2
mu.Lock()
counter++
mu.Unlock()

После выполнения G2 видит counter, увеличенный G1. Без мьютекса инкремент неатомарен и может потеряться.

Под капотом (internals)

sync.Mutex использует низкоуровневый runtime.mutex, основанный на futex (Linux) или semaphore (другие ОС). Lock быстрый путь: атомарный CAS на state из 0 в mutexLocked, который на x86 — LOCK CMPXCHG, на ARM64 — LDXR/STXR с последующим DMB при необходимости. Unlock выполняет атомарный XCHG (release). Медленный путь включает semacquire/semrelease, которые также проходят через атомарные операции. Спецификация гарантирует, что оптимизатор не переупорядочит код через вызов этих функций.

Типичные ошибки кандидатов

• Захват мьютекса в одной горутине, разблокировка в другой: не разрешено, вызывает панику. Каждый Lock должен иметь соответствующий Unlock в той же горутине.
• Использование defer mu.Unlock() в цикле: эффективность может упасть, но семантика верна; ошибка может возникать, если defer выходит за пределы критической секции.
• Рекурсивный захват: sync.Mutex не является рекурсивным, повторный Lock из той же горутины приведёт к deadlock.

Возможные дополнительные вопросы интервьюера

• Чем отличается sync.Mutex от sync.RWMutex? — RWMutex позволяет нескольким читателям одновременно, но писатель эксклюзивен.
• Как работает TryLock? — В Go 1.18 появился метод TryLock, использующий атомарный CAS без ожидания, но не заменяет правильную синхронизацию.
• Влияет ли Unlock на упорядочивание операций после него? — Да, это release-барьер, но последующие операции могут быть переупорядочены после него в пределах горутины, однако они не «утекут» до Unlock (ограничение снизу).

Как работает happens-before для atomic.Store и atomic.Load?

Краткий ответ

atomic.Store (запись) в переменную происходит до последующего atomic.Load (чтения) той же переменной, которое возвращает записанное значение. Это классическая release/acquire пара, подкреплённая последовательной согласованностью. Все записи до Store становятся видимыми после Load.

Развёрнутый ответ

Правило для атомарных операций: Store(x, v) happens-before Load(x) если Load наблюдает результат этого Store. Также Store happens-before последующий Store? Нет, между Store отношения нет, но из-за SC все Store образуют глобальный порядок, и Load видит последний по этому порядку Store.
Таким образом, для синхронизации данных достаточно одного атомарного флага:

var val string
var flag atomic.Bool

// writer
val = "done"
flag.Store(true)

// reader
if flag.Load() {
    fmt.Println(val) // видит "done"
}

Store(true) happens-before Load() -> true, все записи до Store видны.

Под капотом (internals)

atomic.Store на уровне ассемблера для uint64 на x86: MOV [addr], val с префиксом XCHG или LOCK? На самом деле, Go использует XCHG для store, который неявно подразумевает LOCK и полный барьер. На ARM64 компилятор генерирует STLR (store-release) и добавляет DMB ISH для достижения SC. atomic.Load на ARM64 — LDAR (load-acquire) с последующим DMB. Эти пары реализуют семантику «происходит до». Кроме того, компилятор в SSA помечает их как AtomicStore и AtomicLoad, что не позволяет переупорядочивать доступы.

Типичные ошибки кандидатов

• Использование обычного присваивания для флага, ожидая, что atomic.Load на него сработает: нет, atomic.Load должен читать переменную, которая была модифицирована atomic.Store. Обычное присваивание и атомарное чтение — гонка.
• Одновременное использование atomic и неатомарного доступа к одной переменной: категорически запрещено.
• Повторные чтения без понимания, что они могут вернуть устаревшее значение: каждое атомарное чтение создаёт синхронизацию только с тем Store, значение которого он прочитал; нельзя думать, что оно «запоминает» предыдущие.

Возможные дополнительные вопросы интервьюера

• Как обеспечить, чтобы Load увидел не только флаг, но и все записи, которые предшествовали Store, выполненному другим потоком? — Этого достаточно: Store happens-before Load, транзитивно всё видно.
• В чём разница между atomic.Load и atomic.Value.Load? — atomic.Value.Load для произвольных типов; под капотом использует аналогичную синхронизацию.
• Можно ли использовать atomic.Store для синхронизации нескольких полей структуры? — Да, если Store делается после записи всех полей, а Load до их чтения.

Как модель памяти Go работает на уровне процессора (x86 vs ARM)?

Краткий ответ

Модель памяти Go является абстракцией над аппаратными моделями. На x86 модель памяти процессора сравнительно сильная (TCO — Total Store Order), что требует меньше явных барьеров. На ARM модель слабая, поэтому компилятор вставляет дополнительные инструкции барьеров (DMB, LDAR/STLR) для реализации гарантий Go. Разработчику не нужно задумываться об архитектуре, но понимание различий помогает при отладке низкоуровневых багов.

Развёрнутый ответ

x86 (Intel/AMD) — Total Store Order (TSO) модель: записи от одного ядра видны другим в том же порядке, кроме возможности локального reordering чтений после записей. Поэтому «store-load» переупорядочивание возможно. Любой атомарный LOCK-префикс вставляет полный барьер. Go атомарные операции на x86 используют LOCK-инструкции и выглядят сравнительно легко.

ARM (AArch64) имеет relaxed memory model: разрешено практически любое переупорядочивание без барьеров. Для синхронизации Go задействует инструкции STLR (store-release) и LDAR (load-acquire), обеспечивающие release/acquire семантику. Чтобы достичь sequentially consistent поведения, как требует Go, добавляются полные барьеры DMB ISH вокруг атомарных операций. Каналы и мьютексы реализованы через тот же механизм (exclusive load/store + barriers). Это накладывает overhead, но модель памяти Go скрывает детали.

Под капотом (internals)

В рантайме Go есть файлы asm_arm64.s и asm_amd64.s, где определены функции вроде runtime∕internal∕atomic.Cas64. Для arm64 Cas часто выполняется через LDXR/STXR + DMB. Для mutex используются LDAXR/STLXR (acquire/release exclusive). Компилятор в SSA напрямую генерирует нужные машинные инструкции в соответствии с архитектурой. Go гарантирует DRF-SC, поэтому компилятор обязан вставить все барьеры.

Типичные ошибки кандидатов

• Тестирование race-условий только на x86 и перенос на ARM: программа может работать без ошибок на x86 благодаря сильной модели, но упасть на ARM.
• Написание пользовательского кода с inline assembly без учёта барьеров: крайне опасно.
• Утверждение, что на ARM программа медленнее из-за барьеров без профилирования: иногда это так, но нужно измерять.

Возможные дополнительные вопросы интервьюера

• Как проверить корректность барьеров на ARM при отсутствии устройства? — Эмулятор QEMU, cloud ARM instances, race detector.
• Влияет ли архитектура Apple Silicon (M1) на модель памяти? — Она основана на ARM, модель слабая, но Apple может иметь некоторые особенности, однако Go следует стандартному ARMv8.
• Можно ли в Go получить преимущество слабой модели для lock-free? — Нет, модель Go запрещает ослабленные атомики; но можно использовать пакет golang.org/x/sys/cpu с осторожностью.

Что такое "store buffer" и как он влияет на видимость данных?

Краткий ответ

Store buffer — это небольшая асинхронная очередь внутри процессора, в которую попадают записи перед тем, как станут видимыми другим ядрам. Из-за него собственное ядро может видеть свою запись сразу, а другие ядра — с задержкой или в другом порядке. Это приводит к нарушению интуитивной видимости и требует барьеров памяти для сброса store buffer (store-release).

Развёрнутый ответ

Процессорное ядро взаимодействует с кэш-памятью. Когда ядро выполняет store инструкцию, данные могут быть сначала помещены в store buffer, а запись в кэш происходит позже. Другие ядра не видят содержимое store buffer, поэтому запись не становится моментально видимой. Более того, store buffer позволяет переупорядочивать видимость записей: запись x=1; y=2 может быть видна другому ядру как y=2, затем x=1, даже если процессор выполняет их по порядку, потому что y попал в кэш раньше x. Модель памяти вводит барьеры (например, SFENCE или DMB ST) для опорожнения store buffer и гарантирования, что все предыдущие записи видны.

В Go каждая синхронизирующая запись (atomic store, Unlock) выполняет release-барьер, который сбрасывает store buffer и делает все накопленные записи глобально наблюдаемыми. При этом acquire-чтение инвалидирует локальный кэш и гарантирует получение актуальных данных.

Под капотом (internals)

На x86 store buffer присутствует, но из-за TSO порядок записей от одного ядра сохраняется, поэтому x=1; y=2 не может переупорядочиться в видимости другим ядром без специальной причины. Однако чтения могут обгонять записи (store-load reorder). MFENCE или LOCK сбрасывает буфер. В ARM store buffer может вызывать любой реордеринг, поэтому используется DMB ST (release) для сброса. Go реализация atomic.Store в ARM включает DMB ISHST перед операцией, если требуется.

Типичные ошибки кандидатов

• Считать, что запись сразу видна: забывают про store buffer и кэши.
• Проверять flag в тесном цикле без acquire-семантики: значение может никогда не обновиться, т.к. процессор может использовать значение из своего буфера/кэша.
• Пытаться вручную "сбрасывать" буфер time.Sleep: не работает, нужен атомарный доступ.

Возможные дополнительные вопросы интервьюера

• Как связаны store buffer и инвалидация кэша (MESI)? — Store buffer позволяет ядру продолжить работу, пока когерентность кэша разрешается; барьер синхронизирует буфер с кэшем.
• Можно ли наблюдать эффект store buffer в программе на Go без гонок? — Нет, если соблюдена модель памяти, эффект скрыт.
• Почему на x86 программа без синхронизации может иногда работать? — TSO маскирует многие реордеринги, но компилятор всё равно может переупорядочить.

Как canal обеспечивает happens-before между отправкой и получением?

Краткий ответ

(Предполагаем опечатку «canal» = channel). Канал обеспечивает happens-before через внутренний механизм синхронизации: отправка в небуферизированный канал напрямую синхронизирована с получением, так как обе операции блокируются друг на друге; в буферизированном — через мьютекс, который связывает отправку k-го элемента и его получение. Это обеспечивает, что всё, записанное до send, видимо после receive.

Развёрнутый ответ

Для небуферизированного канала синхронизация двусторонняя: send happens-before receive и receive happens-before завершение send. Это даёт полный барьер памяти.

Для буферизированного: отправка k-го элемента захватывает мьютекс, копирует данные в буфер, освобождает мьютекс. Когда получатель запрашивает тот же k-й элемент, он захватывает тот же мьютекс после отправки, что и создаёт happens-before. Также FIFO порядок гарантирует, что получатель видит данные в порядке отправки.

Закрытие канала: close(ch) happens-before получение zero-value, что гарантирует, что все отправленные до закрытия значения видны получателю.

Под капотом (internals)

В исходниках runtime/chan.go функция chansend захватывает lock(&c.lock), выполняет действия, unlock. chanrecv делает то же самое для получения. Схема блокировки та же, что и sync.Mutex. Для небуферизированного канала рантайм выполняет прямой обмен без буфера, также с использованием блокировки, но с дополнительными гарантиями пробуждения. При рандеву используется sudog и пробуждение через goready/semrelease.

Типичные ошибки кандидатов

• Попытка использовать канал для синхронизации после send без получения: отправитель не получает обратной синхронизации, пока получатель не примет значение (кроме небуферизированного, где отправка блокируется до получения).
• Изменение данных после отправки по буферизированному каналу: после отправки объект уже может быть прочитан получателем, гонка.
• Путаница с закрытым каналом: думают, что закрытие канала делает видимыми записи после закрытия; неправильно.

Возможные дополнительные вопросы интервьюера

• Как реализовать синхронизацию без блокировки на основе каналов? — Рассмотреть select с default.
• Может ли получение из канала произойти раньше отправки во времени? — В wall-clock времени — нет, но happens-before обеспечивает логическую причинность.
• Что быстрее: синхронизация через канал или через мьютекс? — Мьютекс обычно быстрее для простой критической секции; канал имеет дополнительные накладные расходы на копирование данных.

Как select с дефолтным значением влияет на happens-before?

Краткий ответ

select с блоком default может быть неблокирующим. Если срабатывает default, никакая операция с каналом не выполняется, следовательно, не создаётся отношения happens-before. Только когда выбранная case-операция (send/receive) реально осуществляется, возникают соответствующие синхронизационные гарантии данной операции.

Развёрнутый ответ

select с default часто используется для проверки готовности канала без блокировки. Если канал не готов, выполняется default и select немедленно возвращается. Поскольку ни send, ни receive не произошли, никакой синхронизации не произошло. Это приводит к тому, что данные, которые могли бы быть записаны до send в другой горутине, не становятся видимыми.

Пример:

select {
case msg := <-ch:
    // здесь есть синхронизация с соответствующей отправкой
    fmt.Println(msg)
default:
    // нет синхронизации
}

Частая ошибка: пытаться читать переменную, которую другая горутина могла изменить, полагая, что неблокирующее чтение канала создаст барьер. Это не так.

Под капотом (internals)

select реализован в runtime/select.go через selectgo(). Он проверяет все case-операции, и если канал не готов, и есть default, сразу возвращает индекс default. Никакие блокировки или атомарные операции не выполняются с каналом, поэтому барьеры не вставляются. Если же case выполняется, то функции chansend или chanrecv вызываются, и они уже добавляют необходимые барьеры.

Типичные ошибки кандидатов

• Использование select с default для ожидания готовности без последующей синхронизации: если later выполнена блокирующая операция с каналом, она даст синхронизацию, но сам default нет.
• Попытка реализовать семафор через неблокирующий select без учета видимости: значение, записанное до отправки в канал, может не быть видно при успешном select? На самом деле, если отправка прошла, синхронизация есть. Но если select выбрал default, её нет.
• Ошибочное ожидание, что default сам по себе является acquire-барьером: нет, он ничего не синхронизирует.

Возможные дополнительные вопросы интервьюера

• Может ли select с default использоваться для неблокирующей отправки? — Да, но нужно быть готовым, что данные могут быть не отправлены; если отправка прошла, синхронизация есть.
• Как select с несколькими case и default обеспечивает справедливость? — Порядок проверки случаен, но на happens-before не влияет.
• Есть ли гарантия, что после default другие операции все ещё увидят старые значения? — Нет никаких гарантий видимости между горутинами без синхронизации, поэтому поведение неопределено.

Как runtime.Gosched влияет на видимость памяти?

Краткий ответ

runtime.Gosched передаёт управление планировщику, приостанавливая текущую горутину и позволяя другим выполняться. Он не создаёт отношения happens-before и не гарантирует видимости памяти. Вызов Gosched нельзя использовать как механизм синхронизации; он влияет только на планирование, но не на упорядочивание памяти.

Развёрнутый ответ

Многие ошибочно полагают, что Gosched действует как yield в других языках и «обновляет» память. Однако модель памяти Go не относит Gosched к синхронизирующим операциям. После Gosched другая горутина может начать выполнение, но это не гарантирует, что записи текущей горутины станут видны. Более того, другая горутина может вообще не увидеть эти записи, если нет явных атомарных или мьютексных операций.

Пример неверного использования:

var done bool
// goroutine 1
done = true
runtime.Gosched()

// goroutine 2
for !done {
    runtime.Gosched()
}

Это не гарантирует выхода из цикла, так как done может быть закэширован.

Под капотом (internals)

runtime.Gosched реализован как mcall(gosched_m) или gopark в зависимости от платформы. Он помещает текущую горутину в runq и вызывает schedule(). При переключении контекста планировщик сохраняет/восстанавливает регистры, но не выполняет никаких барьеров памяти, связанных с видимостью данных пользовательских переменных. Память горутины может оставаться в локальных кэшах и store buffer'ах. Поэтому другие горутины могут не видеть изменений.

Типичные ошибки кандидатов

• Использование Gosched для «борьбы» с гонками: это не исправляет гонку, только меняет расписание.
• Поллинг флага с Gosched: энергично-ожидаемый цикл всё равно нуждается в атомарном чтении флага.
• Утверждение, что Gosched даёт эффект как time.Sleep(0), но с синхронизацией: нет.

Возможные дополнительные вопросы интервьюера

• Может ли Gosched ускорить проявление гонки при отладке? — Может изменить порядок выполнения, но не детерминированно.
• Какие примитивы гарантируют видимость при уступке управления? — Только синхронизирующие операции; sync.Mutex, каналы, runtime.Gosched — никогда.
• Как правильно уступать с синхронизацией? — Использовать канал с select или sync.Cond.

Почему "двойная проверка" (double-checked locking) не работает без atomic?

Краткий ответ

Классический паттерн двойной проверки (double-checked locking) для ленивой инициализации ошибочен без атомарных операций, потому что чтение указателя/флага без acquire-семантики может видеть неинициализированный объект или частично созданный объект. В Go нужна синхронизация через sync.Once или ручное использование atomic.Load и atomic.Store.

Развёрнутый ответ

В Java double-checked locking не работал до введения volatile. Аналогично в Go:

var instance *MyStruct
var mu sync.Mutex

func Get() *MyStruct {
    if instance == nil { // гонка: чтение без синхронизации
        mu.Lock()
        if instance == nil {
            instance = &MyStruct{data: "init"} // запись
        }
        mu.Unlock()
    }
    return instance
}

Проблема: другая горутина может увидеть, что instance != nil, но при этом структура может быть видна не полностью (например, поле data пустое) из-за реордеринга записи указателя и инициализации полей. Причина в том, что первое чтение instance не имеет acquire-семантики и не синхронизировано с записью под мьютексом (которая создаёт release только для тех, кто берёт Lock). Правильное решение — либо всегда захватывать мьютекс перед чтением, либо использовать atomic.LoadPointer/atomic.StorePointer или sync.Once.

Под капотом (internals)

Запись instance = &MyStruct{data: "init"} может быть скомпилирована следующим образом: сначала запись data, потом запись указателя instance. Процессор может переставить эти записи, и instance обновится до того, как data станет видимым. Теперь другая горутина делает if instance != nil — обычное чтение без барьера, видит указатель, но может не увидеть data. Атомарное Store создаёт release, которое гарантирует, что все записи до Store видны. Последующее atomic.Load с acquire-семантикой увидит их.

Типичные ошибки кандидатов

• Попытка исправить добавлением мьютекса только в части записи: Lock только при nil, а чтение без Lock — ошибка.
• Использование atomic.Value для одного значения, но не для всех: если структура содержит мутабельные поля, нужно также синхронизировать их.
• Неверная реализация на sync.Once в цикле: Once вызывается один раз, что идеально для ленивой инициализации.

Возможные дополнительные вопросы интервьюера

• Как sync.Once решает проблему double-checked locking? — Использует атомарный флаг и мьютекс внутри, что даёт корректные барьеры.
• Можно ли реализовать double-checked locking с atomic.CompareAndSwap? — Да, но нужно внимательно обработать случай, когда CAS провалился, и убедиться, что чтение после провала также атомарно.
• Почему в C++ это работало с std::atomic и memory_order? — Потому что atomic с acquire/release даёт необходимую синхронизацию.

Как sync.Once гарантирует, что функция выполнится только один раз?

Краткий ответ

sync.Once использует атомарный флаг done и sync.Mutex. Горутина, вызывающая Do, сначала атомарно читает флаг. Если он установлен, возвращается немедленно. Если нет, захватывает мьютекс, снова проверяет флаг (double-checked locking), вызывает функцию, и после успешного выполнения устанавливает флаг атомарным store. Это гарантирует однократность и видимость побочных эффектов для последующих вызовов.

Развёрнутый ответ

Внутренняя структура:

type Once struct {
    done uint32
    m    Mutex
}
func (o *Once) Do(f func()) {
    if atomic.LoadUint32(&o.done) == 0 {
        o.doSlow(f)
    }
}
func (o *Once) doSlow(f func()) {
    o.m.Lock()
    defer o.m.Unlock()
    if o.done == 0 {
        defer atomic.StoreUint32(&o.done, 1)
        f()
    }
}

Атомарное чтение done в начале — быстрое. Если 0, захватывается мьютекс и перепроверяется. Мьютекс обеспечивает, что только одна горутина войдёт в критическую секцию. После вызова f(), atomic.Store с release-семантикой делает visible done=1, что гарантирует, что последующие атомарные чтения (acquire) увидят 1 и барьер памяти сделает видимыми все записи из f(). Таким образом, обеспечивается и однократность, и синхронизация.

Под капотом (internals)

В рантайме atomic.LoadUint32 и StoreUint32 на x86 используют обычные MOV, но с указанием барьера в Го-коде через SSA (вставка LOCK-префикса не требуется для атомарности 32-бит выровненных данных на x86, но компилятор обеспечивает, что это атомарное чтение с семантикой acquire за счёт того, что дальнейшие операции оптимизатор не переносит выше). На ARM64 Load превращается в LDAR. Store — STLR. Мьютекс добавляет свои барьеры.

Типичные ошибки кандидатов

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

Возможные дополнительные вопросы интервьюера

• Можно ли сбросить Once для повторного использования? — Нет, публичного API нет; нужно создать новый экземпляр.
• Как sync.Once соотносится с init() в плане видимости? — init() выполняется один раз при загрузке пакета, но не лениво.
• Что произойдёт, если внутри f() снова вызвать Do того же Once? — deadlock, потому что мьютекс уже захвачен.

Как sync.Cond обеспечивает happens-before?

Краткий ответ

sync.Cond обеспечивает happens-before через связанный sync.Mutex. Горка, сигнализирующая о событии, делает запись общего состояния, затем вызывает Signal/Broadcast, обычно перед этим удерживая мьютекс. Ожидающая горутина просыпается из Wait и вновь захватывает тот же мьютекс. Так как release мьютекса при Unlock до сигнала happens-before acquire при Lock в ожидающей горутине после пробуждения, все изменения видны.

Развёрнутый ответ

Классический пример:

cond.L.Lock()
ready = true
cond.Signal()
cond.L.Unlock()

// ожидание:
cond.L.Lock()
for !ready {
    cond.Wait() // Unlock, sleep, Lock
}
// видит ready == true и другие изменения
cond.L.Unlock()

Wait() атомарно разблокирует мьютекс (release) и засыпает. Signal() пробуждает спящего. После пробуждения Wait() снова захватывает мьютекс (acquire). Поэтому всё, что было сделано сигнализирующей горутиной перед Unlock (и между Lock и Unlock), становится видно после возврата из Wait. Если сигнал послан без мьютекса, может не быть отношения happens-before с пробуждением, но поскольку состояние защищено мьютексом, корректность обычно сохраняется (пробуждение после Wait перепроверяет условие).

Под капотом (internals)

В runtime/sema.go sync.Cond использует runtime.semacquire/semrelease и список ожидающих. Мьютекс встроен как L. При Wait выполняется runtime.notifyListWait для добавления в список, затем разблокировка L, semacquire. При Signal вызывается runtime.notifyListNotifyOne и semrelease. semrelease имеет release-семантику, semacquire — acquire. Пробуждение приводит к тому, что горутина после semacquire захватывает L, выполняя lockWithRank с acquire-барьером.

Типичные ошибки кандидатов

• Вызов Signal без мьютекса: Signal можно вызывать и без блокировки, но это может привести к тому, что сигнал потеряется из-за пробуждения раньше, чем ожидающая горутина вошла в ожидание. Для надёжности Signal выполняют под тем же мьютексом.
• Неправильный цикл проверки: не использовать for, тогда ложное пробуждение (spurious wakeup) может привести к логической ошибке.
• Использование Cond вместо канала для уведомлений один-к-одному: Cond сложнее; для простых уведомлений лучше канал.

Возможные дополнительные вопросы интервьюера

• Чем Broadcast отличается от Signal в контексте happens-before? — Broadcast пробуждает всех ожидающих, каждый из них при пробуждении получит acquire на мьютексе, создавая независимые отношения.
• Как организовать уведомление нескольких горутин о готовности данных? — Использовать sync.Cond.Broadcast с общим мьютексом.
• Можно ли обойтись без Cond, используя sync.WaitGroup? — WaitGroup подходит для ожидания завершения, а не для условного ожидания изменения состояния.

Что такое "синхронизация через создание горутины" (go statement)?

Краткий ответ

Это отношение happens-before, порождаемое оператором go: все операции, выполненные до go, происходят до начала выполнения переданной функции. Гарантируется, что горутина видит состояние памяти на момент запуска, что позволяет безопасно передать параметры и разделяемые ссылки.

Развёрнутый ответ

Модель памяти утверждает: go f() happens-before вызов f. Это означает, что аргументы, захваченные замыканием, и все записи в стек, сделанные до go, будут видны в f. Это простейший способ безопасной публикации данных новой горутине.

msg := "hello"
go func(m string) {
    fmt.Println(m) // видит "hello"
}(msg)
msg = "world" // эта запись не видна в горутине, если нет синхронизации.

Важно: изменения разделяемых данных после go не обязательно видны; если нужно, чтобы горутина видела обновления, нужна дополнительная синхронизация.

Под капотом (internals)

go в рантайме превращается в newproc(fn), который выделяет g, копирует аргументы (или указатели захваченных переменных) в стек горутины, и помещает её в runq. Операция помещения в runq (через атомарный runqput) реализована с необходимым защитным барьером: все записи, сделанные до публикации горутины в runq, упорядочены до её запуска. Когда планировщик извлекает горутину (runqget), выполняется acquire-барьер, который подхватывает эти записи. Таким образом, newproc -> runqput (release) -> ... runqget (acquire) -> старт горутины.

Типичные ошибки кандидатов

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

Возможные дополнительные вопросы интервьюера

• Гарантирует ли go запуск горутины немедленно? — Нет, она может быть запланирована позже; гарантируется только видимость состояния до go.
• Что будет с паникой в запущенной горутине? — Она аварийно завершает программу, если не перехвачена.
• Как измерить накладные расходы go? — Использовать бенчмарки, но не полагаться на синхронизационные свойства для времени исполнения.

Как happens-before предотвращает гонки данных?

Краткий ответ

Гонка данных (data race) — это конкурентный доступ к одной переменной, где хотя бы один доступ — запись, без синхронизации (отсутствие happens-before). Happens-before предотвращает гонки, устанавливая строгий порядок между конфликтующими доступами: если запись W происходит до чтения R (W happens-before R), то это не гонка, а корректная синхронизация.

Развёрнутый ответ

В Go гонка данных определяется как ситуация, когда две горутины обращаются к одной и той же ячейке памяти, как минимум одна из них — запись, и доступы не упорядочены отношением happens-before (то есть конкурентны). Если программа DRF (Data-Race-Free), то между любыми двумя конфликтующими доступами есть happen-before. Таким образом, построение happens-before через синхронизирующие примитивы является инструментом избегания гонок.

Пример корректной программы: запись в переменную под мьютексом и чтение под этим же мьютексом — Unlock happens-before Lock и чтение видит запись.

Под капотом (internals)

Race detector инструментирует память и отслеживает happens-before отношения, создаваемые синхронизациями. При обнаружении двух доступов без порядка он сигнализирует о гонке. Рантайм не предотвращает гонки автоматически; ответственность разработчика.

Типичные ошибки кандидатов

• Вера, что атомарные операции предотвращают все гонки: атомарные операции синхронизируют только свою переменную, но если есть связанная структура данных, может остаться гонка.
• Отсутствие синхронизации при конкурентной записи в map: map не безопасна для конкурентной записи без мьютекса.
• Использование go test -race только один раз: race detector может пропустить гонку, если она не проявилась при данном планировке; нужны многократные запуски и нагрузочное тестирование.

Возможные дополнительные вопросы интервьюера

• Может ли программа без гонок иметь недетерминированное поведение? — Да, в смысле порядка выполнения горутин, но видимость данных будет детерминирована моделью памяти.
• Какие есть инструменты кроме race detector? — go tool trace, статические анализаторы вроде staticcheck.
• Как гарантировать отсутствие гонок при компиляции? — На уровне языка невозможно; только тестирование и code review.

Как race detector использует happens-before для поиска гонок?

Краткий ответ

Race detector (на основе ThreadSanitizer) динамически отслеживает события синхронизации (мьютексы, атомики, каналы) и строит граф happens-before. Он инструментирует доступы к памяти и проверяет: нет ли двух обращений к одному адресу без установленного порядка «происходит до» между ними. Если находит, сообщает о гонке.

Развёрнутый ответ

При сборке с -race компилятор вставляет в программу вызовы функций рантайма __tsan_*. Для каждой синхронизирующей операции (Lock, Unlock, send, receive, atomic, start goroutine) записываются события с временными метками и идентификаторами горутин. Для каждого доступа к памяти также записываются записи. Алгоритм собирает эти метаданные и ищет конфликты: если есть два доступа, один запись, и они не упорядочены (ни один не happens-before другого), фиксируется гонка. Отношение happens-before вычисляется на основе логических часов (vector clocks). Если есть цепочка синхронизаций, она обеспечивает порядок, и race detector не сигнализирует.

Под капотом (internals)

Рантайм Go интегрирует C++ библиотеку tsan. В src/runtime/race/race_unix.go и race_windows.go определены обертки. Инструментирование добавляется в SSA-оптимизаторе (cmd/compile/internal/ssa). Для каждого атомарного операции генерируется вызов raceacquire/racerelease, для доступа к памяти — raceaccess. Логические часы реализованы как массив 64-битных чисел на каждую горутину.

Типичные ошибки кандидатов

• Запуск race detector только на одном ядре: он наиболее эффективен при многопоточности; на одном ядре может не выявить гонку.
• Игнорирование предупреждений race детектора в тестах: иногда считают, что это ложное срабатывание, но обычно нет.
• Отключение race при тестировании из-за медлительности: тогда гонки остаются незамеченными.

Возможные дополнительные вопросы интервьюера

• Может ли race detector давать ложные срабатывания? — В Go крайне редко, обычно указывает на реальную проблему.
• Как race detector обрабатывает happens-before для пользовательских синхронизаций? — Только для известных примитивов; пользовательский код с unsafe может обходить детектор.
• Какие есть ограничения? — Не обнаруживает гонку на уровне неатомарных 64-битных записей на 32-битных системах, если не выравнены.

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

Краткий ответ

Безопасная публикация (safe publication) требует синхронизации: либо запись объекта под мьютексом, а чтение — под тем же мьютексом; либо атомарная запись указателя с последующим атомарным чтением; либо передача через канал с семантикой happens-before. Важно, чтобы и сам объект, и все его доступные для изменения поля были видны.

Развёрнутый ответ

Неправильно: просто присвоить глобальной переменной указатель — другая горутина может увидеть указатель, но неинициализированные поля. Правильные подходы:

1. Через канал:

ch := make(chan *Object, 1)
go func() {
    obj := &Object{data: "init"}
    ch <- obj
}()
ans := <-ch // видит полностью инициализированный obj

2. Через sync.Mutex:

var mu sync.Mutex
var obj *Object
mu.Lock()
obj = &Object{...}
mu.Unlock()
// читатели: mu.Lock(); o := obj; mu.Unlock()

3. Атомарный указатель:

var obj atomic.Pointer[Object]
// writer
obj.Store(&Object{...})
// reader
o := obj.Load() // полностью видимый

Важно: после публикации через атомарный Store или канал, нельзя модифицировать внутренние поля без дополнительной синхронизации.

Под капотом (internals)

atomic.Pointer.Store выполняет операцию с release-семантикой (барьер), а Load — acquire. Канал при отправке делает release, при получении acquire, аналогично. Мьютекс работает через acquire/release при Lock/Unlock.

Типичные ошибки кандидатов

• Публикация через обычный указатель с последующим time.Sleep — нет гарантии.
• Передача через канал мутируемого слайса и его изменение после отправки: после отправки получатель может читать слайс параллельно с изменением отправителем, гонка.
• Использование sync.Map для хранения объекта и последующее изменение его полей без блокировки: требует дополнительной защиты.

Возможные дополнительные вопросы интервьюера

• Как опубликовать карту (map)? — Карта небезопасна для конкурентного доступа; нужно обернуть в sync.Mutex или использовать sync.Map.
• В чём преимущество атомарного указателя перед мьютексом? — Меньше блокировок, блокировка происходит только в момент смены указателя.
• Можно ли публиковать объект через sync.Cond? — Да, при пробуждении и после захвата мьютекса; это корректно.

Что такое "синхронизированная публикация" (safe publication)?

Краткий ответ

Синхронизированная публикация — это идиома, обеспечивающая, что объект, созданный одной горутиной, безопасно передаётся другой горутине, так что все начальные записи в объект видны получателю. Это достигается выполнением публикации через синхронизирующую операцию (канал, мьютекс, атомарный указатель), создающую happens-before между инициализацией и использованием.

Развёрнутый ответ

Подробнее: safe publication гарантирует, что не только ссылка на объект становится доступной, но и все записи, сделанные при его инициализации до публикации, видны после получения. Например, паттерн «инициализация под мьютексом»:

var instance *MyType
var mu sync.Mutex

func get() *MyType {
    mu.Lock()
    defer mu.Unlock()
    if instance == nil {
        instance = &MyType{field: compute()}
    }
    return instance
}

При возврате из get под мьютексом, читатель видит полностью инициализированный объект. Однако если читатель выполняет get() без удержания мьютекса? Тогда safe publication не гарантирована, если только не используется sync.Once или атомарный указатель.

Ещё пример: отправка по каналу безопасно публикует объект для получателя.

Под капотом (internals)

Безопасная публикация опирается на отношение happens-before между записью и чтением. Рантайм Go гарантирует это через барьеры, как обсуждалось.

Типичные ошибки кандидатов

• Хранение глобального указателя без синхронизации и уверенность, что он виден: забывают о safe publication.
• Ипользование sync.Once безопасно, но попытка безопасно опубликовать изменяемый объект без дополнительной синхронизации после первой публикации: нужно защищать и последующие изменения.
• Предположение, что fmt.Println выполняет безопасную публикацию: он не гарантирует видимость аргументов.

Возможные дополнительные вопросы интервьюера

• В чём разница между safe publication и просто синхронизацией? — Это частный случай синхронизации, когда объект становится доступным другим потокам.
• Можно ли опубликовать мапу через канал безопасно? — Да, если после отправки никто не пишет в мапу. Получатель должен либо не модифицировать, либо синхронизироваться.
• Как безопасно опубликовать результат работы горутины? — Через канал, WaitGroup, мьютекс, atomic.Pointer.

Как происходит happens-before при использовании sync.Pool.Put и Get?

Краткий ответ

Не происходит. sync.Pool.Put и Get не являются синхронизирующими операциями и не создают отношения happens-before. Память объекта, полученного из пула, не гарантированно содержит последние изменения, сделанные перед Put в другой горутине.

Развёрнутый ответ

Это часто неочевидно. Модель памяти Go говорит: Put и Get пула не порождают happens-before. Следовательно, если горутина изменяет объект и кладёт в пул, а другая извлекает его, состояние объекта может оказаться «старым» или частично видимым. Пул предназначен исключительно для снижения аллокаций, а не для обмена данными.

var buf bytes.Buffer
buf.WriteString("data")
pool.Put(&buf)

// другая горутина:
b := pool.Get().(*bytes.Buffer)
fmt.Println(b.String()) // может быть пусто, если не повезло

Нужно явно сбрасывать состояние объекта после Get (вызов Reset()), и перед Put также сбрасывать, чтобы не оставлять мусор.

Под капотом (internals)

Пул использует локальные кэши P (private), доступ к которым не синхронизирован стандартными барьерами. GC периодически очищает объекты из пула (путем зануления указателей). Планировщик не добавляет барьеры при перемещении объектов между P (переход через общий список), используя минимальные атомарные операции только для организации очереди, а не для синхронизации данных.

Типичные ошибки кандидатов

• Передача состояния через пул: например, запись результата в объект, Put, надежда, что получатель увидит. Исправление: использовать канал.
• Хранение в пуле объектов, чувствительных к порядку: при Get состояние может быть любым; всегда инициализируйте заново.
• Забывают, что пул может вернуть nil, если нет объектов и New не задана: нужно проверять.

Возможные дополнительные вопросы интервьюера

• Можно ли реализовать safe publication с помощью пула, добавив свою синхронизацию? — Можно, но тогда зачем пул? Обычно синхронизация вокруг Put/Get неэффективна.
• Как минимизировать аллокации и при этом иметь корректность? — Использовать каналы или мьютексы для передачи готовых объектов.
• Какие примитивы дают happens-before? — Только явные синхронизирующие операции, не пул.

Что такое "consume vs acquire semantics" в контексте атомарных операций Go?

Краткий ответ

Consume семантика — ослабленная версия acquire, которая гарантирует, что только данные, зависимые по data dependency от загруженного значения, видны. Acquire гарантирует видимость всех записей, предшествующих release. В Go атомарные операции с Load дают acquire-семантику (фактически seq-cst), и consume не используется, что упрощает модель и исключает необходимость явного управления зависимостями данных.

Развёрнутый ответ

В C++11 есть memory_order_consume, который гарантирует, что операции, зависящие от загруженного значения, видны в порядке соответствующего release. Однако из-за сложности компиляторной оптимизации (компилятор может разрушить dependency) на практике потребление обычно заменяется acquire. Go компилятор не поддерживает consume; все атомарные чтения являются acquire (и sequentially consistent). Это означает, что при atomic.Load видимость не ограничивается зависимыми данными — видны все записи, предшествующие соответствующему Store. Это проще, но дороже.

Пример на Go: нет способа указать consume. Любое чтение атомарной переменной даёт полную барьерную гарантию.

Под капотом (internals)

На уровне процессора понятия consume примерно соответствует LDAPR (load-acquire PC-relative) на ARM, но из-за проблем компилятора с сохранением зависимостей, Go использует LDAR, что даёт acquire. Вся семантика реализуется как полный барьер (DMB после LDAR для достижения SC). Поэтому consume в Go не реализован.

Типичные ошибки кандидатов

• Ожидание более слабой гарантии от atomic.Load: предполагают, что она аналогична consume и не синхронизирует несвязанные переменные — ошибочно; она видит всё.
• Попытка воспроизвести consume через unsafe и ассемблер: чревато ошибками, не поощряется.
• Неправильное понимание терминологии: путают acquire/release с consume.

Возможные дополнительные вопросы интервьюера

• Почему consume исключили из эффективной практики в C++? — Из-за проблем с разрушением зависимостей компилятором.
• Можно ли в Go получить эффект consume с помощью атомиков? — Нет, и не нужно.
• Какая семантика у atomic.Load в Go? — Sequentially consistent, что включает acquire.

Как sync/atomic операции обеспечивают барьеры памяти?

Краткий ответ

Операции sync/atomic в Go вставляют явные инструкции барьеров памяти на уровне ассемблера, зависящие от архитектуры (например, LOCK-префикс или XCHG на x86, DMB/STLR/LDAR на ARM). Эти барьеры гарантируют как атомарность, так и соблюдение отношения happens-before: Store содержит release-барьер, Load — acquire-барьер, а некоторые операции — полный последовательный барьер для удовлетворения SC.

Развёрнутый ответ

В коде Go написание atomic.StoreInt64(&x, 1) не просто помещает значение в память. Компилятор преобразует это в вызов внутренней функции runtime∕internal∕atomic.Store64, которая на x86 выглядит как XCHG или MOV+LOCK. XCHG с памятью неявно блокирует шину и сбрасывает store buffer, обеспечивая полный барьер. На ARM64 компилятор генерирует STLR (store-release) плюс DMB ISH для достижения SC. Также компилятор вставляет //go:noescape и volatile-атрибуты, предотвращающие оптимизации, которые могли бы нарушить барьер.

Аналогично atomic.Load на ARM64 это LDAR (load-acquire) + DMB. Таким образом, каждая операция несёт с собой один или два барьера, которые делают видимыми предыдущие записи и не позволяют переупорядочивать.

Под капотом (internals)

SSA-бэкенд компилятора Go имеет операции OpAtomicLoad, OpAtomicStore, каждая из которых при генерации машинного кода на основе архитектуры создаёт соответствующие зоны барьера. В частности, на ARM64 OpAtomicStore для uint64 генерирует: STLR R1, (R0) затем DMB ISH. Это указано в src/cmd/compile/internal/ssa/gen/ARM64.rules.

Типичные ошибки кандидатов

• Полагают, что атомарные операции бесплатны на x86: они медленнее обычных mov на порядок из-за блокировки шины и сброса буфера.
• Миксуют атомарные и обычные доступы для одной переменной: барьер есть только у атомарной операции; обычный доступ свободно переупорядочивается.
• Пишут код, где в цикле делают атомарный Load без необходимости: чрезмерно дорого, но иногда необходимо.

Возможные дополнительные вопросы интервьюера

• Можно ли создать атомарную операцию без барьера, если нужна только атомарность? — В Go нет; все атомарные операции несут полный барьер SC.
• Как сравнить производительность атомарных операций между архитектурами? — Бенчмарки с go test -bench.
• Почему atomic.Value может быть быстрее мьютекса? — Потому что в быстром пути использует только атомарный Load, без блокировки.

Почему atomic.Load и atomic.Store не гарантируют полную упорядоченность без happens-before?

Краткий ответ

atomic.Load и Store являются отдельными операциями. Если нет отношения happens-before между конкретным Store и конкретным Load, то Load может не увидеть Store, либо увидеть его в «непоследовательном» порядке относительно других Store. Happens-before возникает только тогда, когда Load наблюдает результат Store, но не между произвольными Store разных горутин. Полная упорядоченность всех операций требует дополнительных связей.

Развёрнутый ответ

Допустим, потоки:

G1: Store(x, 1) // A
G2: Store(y, 1) // B
G3: Load(x) -> 1, Load(y) -> 0

Здесь Load(x) видит A, но между A и B нет happens-before (хотя Store(x) happens-before Load(x)). Однако между Store(x) и Store(y) порядка нет, поэтому Load(y) может увидеть 0. Если бы все операции были глобально упорядочены, такого не случилось бы. SC в Go даёт глобальный порядок только для самих атомарных операций, но не гарантирует, что все они упорядочены единым образом для разных наблюдателей? На самом деле, SC означает, что все атомарные операции видны всем горутинам в одном и том же общем порядке (total order). Тогда если Load(x) видит 1 (означает, что Store(x) предшествует Store(y) в глобальном порядке), то Load(y) должен увидеть 1? В приведённом примере это невозможно в SC. Так что пример невалиден для Go атомиков из-за SC. Вернёмся к объяснению: Go атомарные операции последовательно согласованы, а значит все Store/Load участвуют в едином порядке. Однако без happens-before между Store и конкретным Load мы не можем знать, какой именно Store будет прочитан. Happens-before здесь — это локальное отношение, которое позволяет установить, какое значение гарантированно будет прочитано. Полная упорядоченность всех операций есть, но для предсказания конкретного исхода нужно happens-before между конкретными событиями.

Уточним: вопрос может иметь в виду, что сам по себе Store и Load не создают синхронизации для других переменных без пары. Ответ уже был дан.

Под капотом (internals)

SC реализовано через полные барьеры. Несмотря на это, два независимых Store могут чередоваться, но все процессоры увидят один и тот же порядок. Happens-before же локально гарантирует, что Load видит конкретный Store.

Типичные ошибки кандидатов

• Попытка использовать одиночный Store без пары Load как глобальный барьер: он синхронизирует только с тем, кто сделает Load. Без Load синхронизации нет.
• Использование atomic для построения сложной логики, не обеспечивая парность: приводит к гонкам.

Возможные дополнительные вопросы интервьюера

• Гарантирует ли SC идентичность порядка всех операций на всех ядрах? — Да, в пределах SC атомиков; но обычные операции могут видеть разное.
• Почему атомарные Load/Store в Go медленнее на ARM? — Из-за дополнительных DMB для SC.

Как работает "memory ordering" на уровне процессора и как Go скрывает это от разработчика?

Краткий ответ

Memory ordering определяет, в каком порядке операции с памятью видны другим ядрам. Процессоры реализуют различные модели: от строгой (x86 TSO) до слабой (ARM), допускающей разнообразные реордеринги. Go скрывает эти детали за моделью памяти и синхронизирующими примитивами, вставляя необходимые барьеры и не позволяя разработчику напрямую оперировать memory ordering. Разработчик видит лишь последовательную согласованность для атомарных операций.

Развёрнутый ответ

На процессоре:

• x86: Load могут быть переупорядочены с более старыми Store (store-load реордеринг), но другие реордеринги запрещены.
• ARM: почти любые реордеринги разрешены без барьеров.
  Go компилятор для атомарных операций на ARM вставляет DMB-барьеры, чтобы гарантировать поведение SC. Для мьютексов и каналов также используются acquire/release инструкции с дополнительными барьерами. Разработчику не нужно писать встроенный ассемблер с барьерами, достаточно использовать sync/atomic и sync примитивы.

Модель памяти Go абстрагирует железячные различия, гарантируя DRF-SC. При этом компилятор сам выбирает оптимальный (но безопасный) набор инструкций.

Под капотом (internals)

В cmd/compile/internal/ssa/gen прописаны правила для каждой платформы: для OpAtomicLoad на ARM64 генерируется LDAR плюс DMB; для OpAtomicStore — STLR + DMB. На x86 достаточно обычного MOV с LOCK для CAS, но для Store иногда XCHG. Всё это скрыто в бэкенде компилятора. Разработчик не имеет языкового доступа к выбору порядка.

Типичные ошибки кандидатов

• Самоуверенность в знании особенностей x86 и написание кода без синхронизации, который работает только на x86: на ARM упадёт.
• Использование unsafe.Pointer для обхода модели памяти: чревато неуловимыми багами.
• Неправильное ручное введение MFENCE через cgo: может конфликтовать с моделью Go.

Возможные дополнительные вопросы интервьюера

• Можно ли в Go использовать cgo для тонкого контроля memory ordering? — Можно, но это опасно и ломает кроссплатформенность.
• Какие средства предлагает Go для низкоуровневой синхронизации? — Только sync/atomic; больше ничего.
• Как Go гарантирует, что его модель памяти совместима с аппаратными барьерами? — Тестированием и формальной верификацией компилятора.

Как модель памяти Go работает для "finalizers"?

Краткий ответ

Финализаторы (runtime.SetFinalizer) не создают отношения happens-before и не являются синхронизирующими операциями. Выполнение финализатора не гарантирует видимости записей, сделанных горутинами, которые владели объектом до сборки мусора. Для любой синхронизации в финализаторе необходимо использовать явные механизмы (мьютексы, атомики).

Развёрнутый ответ

Модель памяти Go не определяет порядок между завершением использования объекта и запуском его финализатора относительно других горутин. Нельзя полагаться на финализатор для освобождения конкурентных ресурсов или оповещения других горутин без дополнительной синхронизации. Единственная гарантия — финализатор запускается в некоторой момент после того, как объект стал недостижим. Однако другие горутины могут всё ещё работать с устаревшими ссылками (если передали их, не синхронизируя).

Пример опасного кода:

type Resource struct { mu sync.Mutex; data []byte }
r := &Resource{}
runtime.SetFinalizer(r, func(r *Resource) {
    r.mu.Lock() // может быть небезопасно, если кто-то ещё владеет ссылкой
    cleanup(r.data)
    r.mu.Unlock()
})

Лучше использовать явный вызов Close() с синхронизацией.

Под капотом (internals)

Финализаторы вызываются из runtime.MStats или GC worker'а (runtime.mfinal). Перед запуском финализатора объект уже удалён из кучи. Но рантайм не вставляет никаких барьеров памяти между последним использованием объекта и запуском финализатора. Поэтому состояние памяти, записанное теми, кто использовал объект, не гарантированно видно финализатору. Единственное, что гарантируется — финализатор выполняется один раз.

Типичные ошибки кандидатов

• Попытка восстанавливать консистентность state через финализатор: ненадёжно, лучше заставить пользователя вызывать Close.
• Блокировка финализатора надолго: задерживает GC.
• Передача финализатору объекта с конкурентными изменениями: гонка.

Возможные дополнительные вопросы интервьюера

• Как обеспечить, чтобы финализатор видел актуальные данные? — Нужно добавить синхронизацию (например, atomic) между последним использованием и финализатором, но это сложно. Лучше избегать.
• Может ли финализатор инициировать новую ссылку на объект? — Да, объект может быть «воскрешён», но это плохая практика.

Как sync.Map обеспечивает безопасную публикацию данных?

Краткий ответ

sync.Map гарантирует, что Store для ключа происходит до Load для этого же ключа, если Load возвращает сохранённое значение. Это обеспечивает безопасную публикацию значения: получатель видит именно то, что записал отправитель. Также атомарные обновления внутри sync.Map обеспечивают видимость изменений без дополнительных мьютексов.

Развёрнутый ответ

sync.Map комбинирует две структуры: read-only map (read) и dirty map. При Store новое значение записывается в entry, которая представляет собой атомарный указатель на значение (либо экспулсированное). Чтение (Load) идёт через read map без блокировки, атомарно следуя за entry. Операция Store использует атомарную замену указателя на entry, поэтому Load, который увидит эту entry, получит новое значение. Между Store и успешным Load образуется happens-before: Store помечает entry новым значением (release-store), Load загружает его (acquire-load). Также LoadOrStore при добавлении нового ключа использует внутренний мьютекс, что создаёт дополнительное отношение для первого появления ключа. Это позволяет sync.Map быть безопасным для конкурентного доступа.

var m sync.Map
m.Store("k", "v")
// ...
val, ok := m.Load("k") // ok==true, val=="v"

Под капотом (internals)

Структура sync.Map включает read — atomic.Value (содержит readOnly struct), dirty map под sync.Mutex. Каждая entry (any) — это unsafe.Pointer на трёхвозможное состояние: nil, значение, expunged. Store атомарно заменяет указатель, используя atomic.StorePointer (release). Load использует atomic.LoadPointer (acquire). В случае, когда ключ отсутствует в read, захватывается мьютекс для продвижения dirty, что добавляет вторую линию защиты.

Типичные ошибки кандидатов

• Изменение полей объекта, хранящегося в sync.Map, после Store без синхронизации: видимость гарантирована только для ссылки, но не для состояния объекта. Нужно или заменять весь объект, или использовать sync.Mutex внутри.
• Избыточное использование sync.Map в ущерб обычной map+Mutex: sync.Map выигрывает при стабильном наборе ключей и частых чтениях.
• Предположение, что Range видит согласованное состояние: итерация может пропустить или увидеть дубликаты при конкурентной записи, хотя отдельные значения валидны.

Возможные дополнительные вопросы интервьюера

• Чем sync.Map отличается от обычной map с RWMutex? — Оптимизирован для случая частых чтений и редких записей; обеспечивает lock-free чтение.
• Какие гарантии даёт Range по отношению happens-before? — Спецификация не устанавливает глобальные гарантии; элементы, записанные до старта Range, могут быть или не быть видимы, если есть параллельные записи.
• Может ли sync.Map заменить atomic.Value? — Не совсем, atomic.Value для одного значения, sync.Map — key-value хранилище.

Что такое «правило единого писателя» в контексте модели памяти Go?

Краткий ответ

«Правило единого писателя» (single writer) — эмпирический принцип упрощения конкурентного доступа: если для каждой переменной существует только одна горутина, которая может её изменять (но может быть много читателей), и это гарантируется синхронизацией, то можно избегать блокировок при чтении. Модель памяти Go не освящает это правило, но поддерживает через атомарные операции.

Развёрнутый ответ

Правило означает: структурируйте код так, чтобы для каждого изменяемого поля была только одна горутина-автор, которая изменяет поле либо под мьютексом, либо с использованием атомарных записей, и публикует изменения через синхронизацию. Читатели могут безопасно читать без блокировок, если соблюдён happens-before между записью и чтением. Однако это не отменяет необходимость синхронизации: если единственный писатель находится в другой горутине, читатель всё равно должен обеспечить видимость, обычно через атомарное чтение флага обновления.

Пример: горутина-писатель регулярно обновляет конфигурацию и публикует через atomic.StorePointer. Читатели делают atomic.LoadPointer и уверены в согласованности.

Под капотом (internals)

Реализация через атомарные stores и loads. Важно, чтобы писатель был единственным, иначе могут возникать конфликты при атомарных операциях (CAS). Если писателей несколько, нужен CAS или блокировка.

Типичные ошибки кандидатов

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

Возможные дополнительные вопросы интервьюера

• Как реализовать single writer без atomic? — Можно через небуферизированный канал, где писатель отправляет обновления, а читатель — единственный приёмщик.
• Что эффективнее: мьютекс или atomic указатель с single writer? — Atomic быстрее, если писатель редко обновляет.
• Применимо ли правило к слайсам? — Если слайс не изменяется после публикации, да; иначе нужна синхронизация.

Как модель памяти влияет на дизайн lock-free структур данных?

Краткий ответ

Модель памяти с DRF-SC и SC-атомарными операциями одновременно упрощает и ограничивает lock-free дизайн в Go: упрощает, потому что не нужно думать о выборе memory ordering (все операции SC); ограничивает, потому что отсутствие relaxed атомиков делает невозможными некоторые оптимизации, связанные с пропуском излишних барьеров. Lock-free структуры в Go обычно опираются на CAS и атомарные указатели, но не могут достичь такого же уровня производительности на слабых архитектурах, как в C++ с relaxed.

Развёрнутый ответ

Lock-free структуры (стек, очередь, списки) в C++ часто используют memory_order_relaxed для операций, не требующих синхронизации, и acquire/release только там, где нужна. В Go все атомарные операции SC, что добавляет дополнительные барьеры и снижает производительность, особенно на ARM. Однако это исключает класс ошибок, связанных с недостаточной упорядоченностью.

При проектировании lock-free структуры в Go приходится полагаться на то, что каждый атомарный CAS или Store создаёт полный барьер. Это заставляет минимизировать количество атомарных операций, объединять обновления. Часто используют atomic.Pointer с заменой целых узлов. обычные неатомарные чтения полей в узлах подходят только если узел неподвижен после публикации.

Пример lock-free очереди Майкла-Скотта на Go: использует atomic.Pointer для головы и хвоста. Каждый CAS обходится дороже, но корректен.

Под капотом (internals)

CAS в Go генерирует полные барьеры, поэтому даже если логически достаточно relaxed, всё равно выполняются DMB инструкции. Это видно в ассемблере. Отсутствие memory_order_relaxed означает, что компилятор не может оптимизировать код, убирая избыточные барьеры.

Типичные ошибки кандидатов

• Попытка использовать обычные указатели вместо атомарных в lock-free структуре: гонка.
• Избыточные атомарные операции: если структура имеет много полей, обновляемых вместе, лучше упаковать в одну структуру и атомарно переключать указатель.
• Игнорирование ABA-проблемы: CAS на unsafe.Pointer может страдать от ABA; нужно использовать двойной словный CAS или generational counter, но в Go CAS на unsafe.Pointer безопасен с точки зрения ABA? На самом деле GC предотвращает освобождение памяти, но ABA всё ещё возможна при переиспользовании узлов из пула. Решение — tagged pointers или atomic.Uintptr.

Возможные дополнительные вопросы интервьюера

• Какая lock-free очередь является самой производительной в Go? — Часто используют дисциплины на основе каналов, но для lock-free — имплементация LKQueue.
• Как влияет GC на lock-free структуры? — GC может освобождать узлы, облегчая управление памятью, в отличие от C++.
• Стоит ли реализовывать lock-free в Go? — В редких случаях, когда есть профилирование, показывающее, что мьютексы — узкое место, и архитектура позволяет; в большинстве случаев каналы и мьютексы достаточно эффективны.