Go vs Java - сравнение модели памяти: happens-before, visibility, reorder, synchronization events, write/read barriers

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

И Go, и Java вводят формальную memory model, которая определяет когда изменения одного потока становятся видимыми для другого.

Основная идея - Happens-before

Главное правило моделей памяти — отношение happens-before. Если операция A happens-before B, то все изменения памяти, сделанные в A, гарантированно видны в B.

A happens-before B

Проблема без синхронизации

Go

package main

import "fmt"

var x int
var ready bool

func writer() {
    x = 42
    ready = true
}

func reader() {
    if ready {
        fmt.Println(x)
    }
}

Интуитивно кажется, что если ready == true, то x уже равен 42. Но процессор может изменить порядок инструкций или держать данные в кеше CPU.

Java

int x = 0;
boolean ready = false;

void writer() {
    x = 42;
    ready = true;
}

void reader() {
    if (ready) {
        System.out.println(x);
    }
}

В Java возникает та же проблема: поток может увидеть ready=true, но старое значение x.

Решение: синхронизация

Go (channel)

package main

import "fmt"

var x int
var ch = make(chan struct{})

func writer() {
    x = 42
    close(ch)
}

func reader() {
    <-ch
    fmt.Println(x)
}

Закрытие канала создаёт happens-before связь между потоками.

Java (volatile)

volatile boolean ready;
int x;

void writer() {
    x = 42;
    ready = true;
}

void reader() {
    if (ready) {
        System.out.println(x);
    }
}

Запись volatile гарантирует happens-before между потоками.

Instruction Reordering

Компилятор и CPU могут менять порядок инструкций ради оптимизации, если это не влияет на результат внутри одного потока.

x = 1
y = 2

может выполняться как

y = 2
x = 1

Visibility (видимость)

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

CPU1: x = 10
CPU2: читает x

CPU2 может увидеть старое значение.

Synchronization events

Go

• channel send → receive
• mutex unlock → lock
• WaitGroup.Done → Wait
• atomic operations
• close(channel)

Java

• synchronized exit → enter
• volatile write → read
• Lock.unlock → lock
• Thread.start
• Thread.join
• Future.get

Философия языков

Go

Do not communicate by sharing memory;
share memory by communicating.

Основная идея Go — передавать данные через каналы между goroutines.

Java

Thread
   ↓
shared memory
   ↓
synchronization

Java исторически использует модель общей памяти с синхронизацией.

Data Race

Data race возникает когда:

• два потока обращаются к одной переменной
• хотя бы один поток пишет
• нет синхронизации

В Go есть встроенный детектор:

go run -race main.go

Предварительный итог

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

Write Barrier

Write barrier — это специальная инструкция рантайма, вставляемая при записи указателей или ссылок на объекты в память. Она нужна для работы сборщика мусора (GC), чтобы корректно отслеживать новые и изменённые объекты во время параллельной сборки.

Концептуальный пример в Go:

node.child = newNode
// runtime автоматически добавляет write barrier для GC

В Java JVM использует аналогичные write barriers в современных сборщиках (G1, ZGC, Shenandoah) для отслеживания изменений ссылок:

node.child = newNode;
// JVM вставляет write barrier для безопасной работы GC

Read Barrier

Read barrier — это проверка при чтении указателя или ссылки, используемая некоторыми сборщиками мусора, чтобы корректно обработать объекты, которые могли быть перемещены в памяти во время concurrent GC.

Пример в Go:

child := node.child
// runtime может выполнить read barrier, чтобы убедиться, что ссылка актуальна

Пример в Java (ZGC или Shenandoah):

Node child = node.child;
// JVM может вставить read barrier при чтении перемещаемого объекта

Итоговое сравнение: Go vs Java Memory Model

Go и Java используют схожую концепцию happens-before, которая гарантирует видимость изменений между потоками при правильной синхронизации. Основное отличие в философии: Go пропагандирует передачу данных через каналы (share memory by communicating), а Java традиционно использует разделяемую память с синхронизацией (shared memory + synchronization).

Главный практический вывод: большинство багов многопоточности возникают не из-за количества потоков, а из-за неверной синхронизации и неправильного представления о порядке выполнения инструкций. Использование каналов в Go и synchronized/volatile в Java помогает безопасно управлять памятью.

Для Go разработчиков: Do not communicate by sharing memory; share memory by communicating.
Для Java разработчиков: правильное использование volatile, synchronized и concurrent-структур обеспечивает предсказуемость.

Использование встроенных инструментов вроде go run -race в Go и анализ data races в Java помогает выявлять ошибки на раннем этапе.