Кратко — ключевая разница: в многопоточности у вас единое адресное пространство и общая память, синхронизация даёт атомарность/видимость за счёт локальных примитивов и барьеров; в распределённых системах узлы общаются сообщениями через ненадёжную сеть, нет общего состояния «по умолчанию», поэтому нужны протоколы согласования (кворумы, журнал, выбор лидера, персистентность), которые дороже и сложнее.
1) Гонка данных в Java (shared memory)
- Случай: два потока одновременно пишут/читают одно поле — возможна гонка, некорректный результат.
- Механизмы:
- synchronized: обеспечивает взаимное исключение (mutex) и семантику happens-before: выход из synchronized делает видимыми изменения другим, вход — видит предшествующие изменения. Подходит для критических секций, обеспечивает атомарность нескольких операций.
- volatile: гарантирует видимость и запрещает определённые перестановки компилятором/процессором; чтение/запись одного volatile-поля атомарно, но составные операции (например, read-modify-write) не атомарны.
- AtomicInteger (java.util.concurrent.atomic): предоставляет атомарные примитивы (get, set, getAndIncrement, compareAndSet) на основе CAS (compare-and-swap) и встроленных барьеров; позволяет lock-free алгоритмы для одноэлементных атомарных обновлений.
- Почему это работает: все потоки видят одну память, CPU/VM обеспечивают инструкции с семантикой атомарности и видимости, можно использовать барьеры и локальные примитивы с малой задержкой.
2) Согласование в кластере (message passing)
- Проблема: несколько узлов должны договориться о едином значении или порядке операций (например, кто лидер, какой следующий коммит в журнале).
- Характерные трудности: сетевые задержки, потеря/дублирование/перестановка сообщений, частичные отказы узлов, разделение сети (partition). Нельзя оперировать общей памятью — только отправлять/получать сообщения.
- Протоколы: Paxos, Raft (а также Zab, Viewstamped Replication и т.д.)
- Основные механизмы: выбор лидера (в Raft), упорядоченный распределённый журнал (replicated log), кворумы (большинство) для записи и прочтения, персистентное хранение метаданных (term, votedFor, лог) чтобы пережить перезапуск узла, таймауты/повторные попытки.
- Кворум: чтобы гарантировать пересечение подтверждений, большинство. Для $N$ узлов большинство — $\lceil \frac{N}{2}\rceil$; чтобы терпеть $f$ отказов нужно $N=2f+1$.
- Почему простые локальные примитивы не работают: нет общей памяти и нет атомарного CAS между машинами. CAS-операцию на кластере можно «симулировать» только с помощью распределённого согласования (например, выполнить compare-and-set как транзакцию, согласованную большинством), но это потребует сетевых раундтрипов и персистентности.
3) Соотношение механизмов и когда какие применимы
- synchronized/locks: применимы только внутри одного процесса/JVM (или внутри узла при использовании локальных потоков). Дистрибутивный аналог — распределённый замок (distributed lock), но такой замок должен опираться на сервис согласования (Zookeeper, etcd), который сам реализует протокол консенсуса; его корректность зависит от кворумов и персистентности.
- volatile: обеспечивает локальную видимость/барьеры; в сетевой среде частично аналог — гарантии доставки/порядка сообщений (TCP — порядок между двумя узлами) и семантика «запись в журнал + репликация = видимость», но этого недостаточно для согласованного, линейноизменяемого состояния без консенсуса.
- AtomicInteger / CAS: даёт lock-free, быстрые атомарные операции в памяти. Распределённый аналог — атомарный счётчик/регистры, реализуемые через консенсус (replicated state machine). Их реализация требует множества RTT и персистентности, поэтому значительно медленнее.
- Журналы + кворумы (Raft/Paxos): применимы только в распределённых системах; они дают упорядоченную, линейную историю операций и выдерживают частичные отказы при условии достаточного числа узлов.
4) Примеры соответствия и выводы
- Локальная гонка в Java: решается synchronized (mutual exclusion), volatile (видимость одного поля) или AtomicInteger (CAS для инкремента) — всё быстро, короткая задержка, не требует персистентности.
- Распределённая задача «обновить счётчик атомарно во всём кластере»: нельзя просто применить AtomicInteger; нужно протокол консенсуса, который:
- согласует одну операции инкремента как запись в реплицированный журнал (либо leader append + replicate + commit по кворуму),
- хранит изменения на диск/в стабильном хранилище,
- обеспечивает, что после коммита любой клиент увидит изменения (линейная консистентность).
- Распределённые замки/атомарные регистры реализуются поверх консенсуса (например, Zookeeper/etcd), поэтому их стоимость и поведение подчинены сетевым свойствам и ограничениям CAP.
Коротко: в shared-memory вы решаете гонки с примитивами памяти (locks, barriers, CAS) — дешёво и локально; в message-passing вы решаете согласование через протоколы консенсуса (кворумы, журнал, лидер, персистентность) — правильно, но дороже и с учётом сетевых отказов.