🧩 Coordination: как синхронизировать хаос — Java Blocking vs Reactor vs Go

Конкурентность — это не про «запустить много потоков». Это про договорённости между ними.

Представь кухню ресторана: — повара (потоки / горутины) — заказы (задачи) — и главный вопрос: как они координируются?

Сегодня ты увидишь 3 мира:

• 🟨 Blocking Java — «каждый ждёт»
• 🟣 Reactor (Reactive Streams) — «всё течёт, никто не блокирует»
• 🔵 Go — «простые горутины + каналы»

Wait All Tasks (Barrier Join)

Wait All Tasks — 🎬 «финальные титры» 🍿, ждём пока все закончат

💬 Объяснение

Ты запускаешь несколько задач — и хочешь продолжить только когда все завершились.

Это как команда строителей: нельзя сдавать дом, пока каждый не закончил свою часть.

• Java: CountDownLatch — счётчик, уменьшается до нуля
• Reactor: Mono.when — собирает несколько async потоков
• Go: WaitGroup — добавил задачи → ждёшь

🗺️ Схема

Задачи:
 T1 ──┐
 T2 ──┼──▶ [ WAIT ALL ] ──▶ Continue
 T3 ──┘

🟨 Java:
 T1 → countDown()
 T2 → countDown()
 T3 → countDown()
 main → await()

🟣 Reactor:
 Mono1 ─┐
 Mono2 ─┼──▶ Mono.when() → done
 Mono3 ─┘

🔵 Go:
 wg.Add(3)
 go T1 → wg.Done()
 go T2 → wg.Done()
 go T3 → wg.Done()
 wg.Wait()

// создаём latch на 3 задачи
CountDownLatch latch = new CountDownLatch(3);

Runnable task = () -> {
    // выполняем работу
    System.out.println("Task done");
    
    // уменьшаем счётчик
    latch.countDown();
};

new Thread(task).start();
new Thread(task).start();
new Thread(task).start();

// ждём пока все завершатся
latch.await();

System.out.println("All done!");

// три асинхронных потока
Mono<String> m1 = Mono.just("A");
Mono<String> m2 = Mono.just("B");
Mono<String> m3 = Mono.just("C");

// ждём завершения всех
Mono.when(m1, m2, m3)
    .doOnTerminate(() -> System.out.println("All done"))
    .subscribe();

var wg sync.WaitGroup

wg.Add(3)

go func() {
    defer wg.Done()
    fmt.Println("Task 1 done")
}()

go func() {
    defer wg.Done()
    fmt.Println("Task 2 done")
}()

go func() {
    defer wg.Done()
    fmt.Println("Task 3 done")
}()

// блокируемся пока все не закончат
wg.Wait()

fmt.Println("All done")

Для 🟨 Java Blocking: используй CountDownLatch только для короткоживущих задач — под капотом поток реально «спит» и жрёт ресурсы.

Для 🟣 Reactor: не вставляй .block() — это ломает весь non-blocking pipeline и превращает его в blocking ад.

Для 🔵 Go: всегда ставь defer wg.Done() — иначе забудешь и получишь deadlock.

API gateway (🟣 Reactor): собираешь ответы от нескольких сервисов → Mono.when → быстрее и не блокирует.

Batch processing (🟨 Java): запустил 5 задач → дождался → записал результат — просто и понятно.

Параллельные воркеры (🔵 Go): обработка очереди — WaitGroup ждёт завершения всех воркеров.

Mutex (Critical Section)

Mutex — 🔒 «один ключ на дверь» 🚪, только один внутри

💬 Объяснение

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

Иначе будет хаос: race condition.

Mutex = «внутрь заходит только один».

• Java: synchronized
• Reactor: избегает shared state
• Go: sync.Mutex

🗺️ Схема

Потоки:
 T1 ─┐
 T2 ─┼──▶ [ LOCK ] → critical section → unlock
 T3 ─┘

🟨 Java:
 synchronized(obj) { ... }

🟣 Reactor:
 нет lock → immutable / sequence

🔵 Go:
 mu.Lock()
 ...
 mu.Unlock()

private int counter = 0;

public synchronized void inc() {
    // только один поток здесь
    counter++;
}

// избегаем shared state
Flux.range(1, 10)
    .map(i -> i * 2) // immutable transform
    .subscribe();

var mu sync.Mutex
counter := 0

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

Для 🟨 Java: избегай вложенных synchronized — под капотом это может привести к deadlock через блокировку мониторов.

Для 🟣 Reactor: не тащи mutable state — вся сила reactive в том, что данные не делятся между потоками.

Для 🔵 Go: если используешь mutex — подумай, можно ли заменить на channel (message passing).

Кэш (🟨 Java): синхронизация доступа к Map — иначе race condition.

Streaming pipeline (🟣 Reactor): лучше делать immutable transformations — никаких lock не нужно.

Low-level сервисы (🔵 Go): mutex для счётчиков, метрик, shared state.

First Result Wins

First Result Wins — 🏁 «кто первый — того и тапки» ⚡, берём самый быстрый

💬 Объяснение

Ты запускаешь несколько задач — и берёшь первый результат.

Остальные — игнорируешь или отменяешь.

Это как запрос в несколько CDN — берём самый быстрый ответ.

• Java: CompletableFuture.anyOf
• Reactor: Flux.first
• Go: select

🗺️ Схема

 T1 ──┐
 T2 ──┼──▶ [ FIRST ] ──▶ result
 T3 ──┘

остальные отменяются / игнорируются

CompletableFuture<String> f1 = slow();
CompletableFuture<String> f2 = fast();

// берём первый завершившийся
CompletableFuture.anyOf(f1, f2)
    .thenAccept(result -> {
        System.out.println(result);
    });

Flux.first(
    slowFlux(),
    fastFlux()
).subscribe(System.out::println);

select {
case r := <-fast:
    fmt.Println(r)
case r := <-slow:
    fmt.Println(r)
}

Для 🟨 Java: обязательно продумывай отмену остальных задач — иначе они продолжают работать и жрут ресурсы.

Для 🟣 Reactor: используй timeout + fallback — это усиливает паттерн.

Для 🔵 Go: закрывай каналы или добавляй context — иначе утечки горутин.

Multi-CDN (все): отправляешь запросы → берёшь самый быстрый → ускорение latency.

Failover (🟨 Java): основной сервис + резервный — anyOf.

High-load сервисы (🟣 Reactor): race между cache и DB.

Network clients (🔵 Go): select между несколькими источниками данных.

Join Futures

Join Futures — 🧺 собрать корзину результатов, множество async задач → один итог

💬 Объяснение

Представь кухню ресторана.

Ты заказал:

• бургер
• картошку
• напиток

Каждое блюдо готовится отдельно.

Но официант приносит один поднос.

Это и есть Join Futures.

Мы запускаем несколько async задач и потом собираем их результаты в один.

В разных мирах это делается по-разному:

• 🟨 Java Blocking — список Future + get()
• 🟣 Reactor — flatMap + collect
• 🔵 Go — goroutines + channel

🗺️ Схема

JOIN FUTURES

Задача A ----\
              \
Задача B ----- JOIN ----> итоговый результат
              /
Задача C ----/


Java Blocking

Thread1 -> Task A
Thread2 -> Task B
Thread3 -> Task C

main thread:
futureA.get()
futureB.get()
futureC.get()


Java Reactive (Reactor)

Flux(tasks)
   -> flatMap(asyncCall)
   -> collectList()

не блокирует поток


Go

go taskA()
go taskB()
go taskC()

results <- channel

for i := 0; i < 3; i++ {
   result := <-results
}

📊 Сводная таблица

ExecutorService pool = Executors.newFixedThreadPool(3);

List<Future<Integer>> futures = new ArrayList<>();

for (int i = 0; i < 3; i++) {

    // отправляем задачу в thread pool
    futures.add(pool.submit(() -> {

        // имитация работы
        Thread.sleep(1000);

        return 10;
    }));
}

int sum = 0;

for (Future<Integer> future : futures) {

    // БЛОКИРУЕМСЯ пока результат не готов
    sum += future.get();
}

System.out.println(sum);

Flux.range(1,3)

    // запускаем async задачи
    .flatMap(i -> Mono.fromCallable(() -> {

        Thread.sleep(1000);

        return 10;

    }))

    // собираем все результаты
    .collectList()

    .map(list -> list.stream()
                     .mapToInt(Integer::intValue)
                     .sum())

    .subscribe(System.out::println);

package main

import "fmt"

func worker(ch chan int) {

    // имитация работы
    ch <- 10
}

func main() {

    results := make(chan int)

    for i := 0; i < 3; i++ {

        // запускаем горутину
        go worker(results)
    }

    sum := 0

    for i := 0; i < 3; i++ {

        // получаем результат
        sum += <-results
    }

    fmt.Println(sum)
}

🟨 Java Blocking — никогда не вызывай future.get() внутри большого цикла без пула потоков. Это превращает async код обратно в синхронный.
🟣 Reactor — избегай .block() внутри reactive pipeline. Это разрушает всю модель неблокирующего исполнения.
🔵 Go — всегда контролируй количество чтений из канала. Если отправили 5 сообщений — нужно 5 чтений.

API aggregator (Backend For Frontend) — собираем данные из нескольких сервисов. Очень типичный Join Futures.
Search service — поиск по нескольким индексам.
Microservice gateway — объединение ответов нескольких downstream сервисов.

Semaphore limit

Semaphore limit — 🚦 светофор задач, ограничение количества параллельных операций

💬 Объяснение

Представь мост.

По нему может ехать только 10 машин одновременно.

Если приехала 11-я — она ждёт.

Это делает Semaphore.

🗺️ Схема

LIMIT CONCURRENCY

Tasks -> [ LIMIT 5 ] -> execution


Java Blocking

Semaphore(5)
acquire()
run task
release()


Reactor

flatMap(task, concurrency=5)


Go

buffered channel size=5

📊 Сводная таблица

Semaphore semaphore = new Semaphore(5);

semaphore.acquire();

try {

    // выполняем задачу
    callService();

} finally {

    // освобождаем слот
    semaphore.release();
}

Flux.range(1,100)

.flatMap(i ->
    callService(i),
    5 // ограничение concurrency
)

.subscribe();

sem := make(chan struct{}, 5)

sem <- struct{}{}

go func() {

    callService()

    <-sem
}()

🟨 Java Blocking — всегда освобождай semaphore в finally, иначе система постепенно зависнет.
🟣 Reactor — всегда указывай concurrency в flatMap если вызываешь внешний сервис.
🔵 Go — buffered channel идеально подходит как semaphore.

Database connection limiting.
External API rate limiting.
Worker pool управление нагрузкой.

Join Service

Join Service — 🎬 дождаться финала всех актёров, запуск набора задач и ожидание завершения

💬 Объяснение

Представь фильм.

Сцена считается завершённой только когда все актёры закончили.

Это и есть Join Service.

🗺️ Схема

TASK GROUP EXECUTION

Task A
Task B
Task C

       ↓

WAIT ALL FINISH


Java

invokeAll()


Reactor

merge()


Go

WaitGroup

📊 Сводная таблица

ExecutorService pool =
    Executors.newFixedThreadPool(3);

List<Callable<String>> tasks = List.of(
    () -> "A",
    () -> "B",
    () -> "C"
);

List<Future<String>> results =
    pool.invokeAll(tasks);

Flux.merge(

    serviceA(),
    serviceB(),
    serviceC()

).subscribe();

var wg sync.WaitGroup

wg.Add(3)

go func() {
    defer wg.Done()
}()

go func() {
    defer wg.Done()
}()

go func() {
    defer wg.Done()
}()

wg.Wait()

🟨 Java Blocking — invokeAll отлично подходит для batch задач.
🟣 Reactor — merge полезен для объединения потоков сервисов.
🔵 Go — WaitGroup это самый простой способ синхронизации горутин.

Fan-out / Fan-in architecture.
Parallel microservice calls.
Batch data processing.

Thread coordination

Thread coordination — 🔔 звонок между потоками, один поток ждёт сигнал другого

💬 Объяснение

Представь кухню ресторана.

Один повар готовит стейк. Другой — гарнир.

Но гарнир можно начинать только после сигнала.

Повар кричит:

“Готово!”

И второй начинает работу.

Это и есть Thread coordination.

Потоки ждут сигнал друг друга.

В разных мирах:

• 🟨 Java — wait / notify
• 🟣 Reactor — signal
• 🔵 Go — channel

🗺️ Схема

THREAD COORDINATION

Thread A ---- work ---- notify ---->
                                   Thread B resumes


Java Blocking

Thread B
  wait()

Thread A
  notify()


Reactive

Publisher -> signal -> Subscriber


Go

goroutine A -> channel -> goroutine B

📊 Сводная таблица

class Worker {

    private final Object lock = new Object();
    private boolean ready = false;

    public void waitForSignal() throws Exception {

        synchronized (lock) {

            while (!ready) {

                // поток засыпает
                lock.wait();
            }

            System.out.println("Signal received");
        }
    }

    public void sendSignal() {

        synchronized (lock) {

            ready = true;

            // будим ожидающий поток
            lock.notify();
        }
    }
}

Mono<String> signal =
    Mono.just("ready");

signal
    .doOnNext(v -> {

        // событие выступает сигналом
        System.out.println("Signal received");
    })
    .subscribe();

package main

import "fmt"

func main() {

    signal := make(chan bool)

    go func() {

        // поток ждёт сигнал
        <-signal

        fmt.Println("Signal received")
    }()

    // отправляем сигнал
    signal <- true
}

🟨 Java Blocking — всегда используй wait() внутри while. Это защита от ложных пробуждений JVM.
🟣 Reactor — думай о событиях как о сигналах между частями pipeline.
🔵 Go — никогда не отправляй в канал, если никто не читает.

Producer-consumer pipeline — один поток производит данные, другой ждёт сигнал готовности.
Event-driven системы — реакция на события вместо polling.
Синхронизация этапов обработки данных.

Race control

Race control — 🏁 один финишный коридор, контроль порядка доступа к данным

💬 Объяснение

Представь банкомат.

К нему может подойти только один человек.

Если двое попытаются одновременно — начнётся хаос.

Это называется race condition.

Поэтому нужен контроль доступа.

В разных мирах:

• 🟨 Java — synchronized
• 🟣 Reactor — concatMap (гарантирует порядок)
• 🔵 Go — mutex

🗺️ Схема

RACE CONTROL

Task A \
        -> critical section
Task B /

only one allowed


Java

synchronized block


Reactive

concatMap -> sequential processing


Go

mutex lock

📊 Сводная таблица

class Counter {

    private int value = 0;

    public synchronized void increment() {

        // только один поток
        // может войти сюда

        value++;
    }
}

Flux.range(1,5)

.concatMap(i -> {

    // задачи выполняются
    // строго по очереди

    return Mono.just(i);
})

.subscribe();

package main

import (
    "sync"
)

var mutex sync.Mutex
var counter int

func increment() {

    mutex.Lock()

    counter++

    mutex.Unlock()
}

🟨 Java Blocking — держи synchronized блоки максимально короткими.
🟣 Reactor — concatMap полезен когда важен порядок событий.
🔵 Go — используй defer mutex.Unlock() чтобы избежать забытых unlock.

Обновление shared кеша.
Последовательная обработка финансовых операций.
Очереди событий.

Fork-Join

Fork-Join — 🌳 раздели дерево задачи, параллельно реши ветки и собери результат

💬 Объяснение

Представь огромную задачу.

Например — подсчитать сумму миллионов чисел.

Один поток будет считать очень долго.

Поэтому мы:

• делим задачу
• решаем части параллельно
• объединяем результат

Это и есть Fork-Join.

🗺️ Схема

FORK JOIN

        task
       /   \
    task   task
    / \     / \
   a  b    c   d

join results

📊 Сводная таблица

ForkJoinPool pool = new ForkJoinPool();

int result =
    pool.submit(() ->
        IntStream.range(0,1000)
        .parallel()
        .sum()
    ).get();

Flux.range(1,1000)

.parallel()

.runOn(Schedulers.parallel())

.reduce(Integer::sum)

.subscribe(System.out::println);

jobs := make(chan int, 100)

for w := 0; w < 4; w++ {

    go worker(jobs)
}

for i := 0; i < 100; i++ {

    jobs <- i
}

🟨 Java Blocking — ForkJoinPool идеально подходит для CPU-heavy задач.
🟣 Reactor — parallel() используй только для CPU задач, не IO.
🔵 Go — worker pool лучше ограничивать количеством CPU.

Big data обработка.
Parallel computation.
Distributed batch processing.

Ordered join

Ordered join — 📦 собрать посылки по номеру, параллельные задачи → результаты в исходном порядке

💬 Объяснение

Представь конвейер доставки.

Пять курьеров развозят посылки одновременно. Но клиент должен получить их в правильном порядке.

Даже если посылка №3 приехала раньше №2 — её нужно подождать.

Это и есть Ordered Join.

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

В разных технологиях:

• 🟨 Java — список Future
• 🟣 Reactor — concat
• 🔵 Go — упорядоченный канал

🗺️ Схема

ORDERED JOIN

Tasks executed in parallel:

Task1 ----\
Task2 -----\ 
Task3 -------> execution
Task4 -----/
Task5 ----/

BUT results must be returned in order

Result1
Result2
Result3
Result4
Result5


Java Blocking

Future1.get()
Future2.get()
Future3.get()


Reactive

Flux.concat()

ensures order


Go

channel with ordered aggregation

📊 Сводная таблица

ExecutorService pool =
    Executors.newFixedThreadPool(3);

// список задач
List<Callable<Integer>> tasks = List.of(
    () -> 1,
    () -> 2,
    () -> 3
);

// запускаем все задачи
List<Future<Integer>> futures =
    pool.invokeAll(tasks);

// получаем результаты строго по порядку
for (Future<Integer> f : futures) {

    // get() блокирует поток
    // пока результат не готов
    System.out.println(f.get());
}

Flux<Integer> flux1 = Mono.just(1).flux();
Flux<Integer> flux2 = Mono.just(2).flux();
Flux<Integer> flux3 = Mono.just(3).flux();

// concat гарантирует
// сохранение порядка

Flux.concat(flux1, flux2, flux3)
    .subscribe(System.out::println);

package main

import "fmt"

func worker(id int, ch chan int) {

    // отправляем результат
    ch <- id
}

func main() {

    ch := make(chan int)

    for i := 1; i <= 3; i++ {

        go worker(i, ch)
    }

    // читаем результаты
    // и можем упорядочить их
    for i := 0; i < 3; i++ {

        fmt.Println(<-ch)
    }
}

🟨 Java Blocking — список Future автоматически сохраняет порядок задач, поэтому безопасно использовать invokeAll.
🟣 Reactor — concat обеспечивает строгий порядок событий, но снижает параллелизм pipeline.
🔵 Go — для упорядочивания результатов лучше использовать индексированные структуры.

Aggregation API — нужно вернуть данные сервисов строго в том же порядке.
Streaming pipelines — обработка событий в фиксированной последовательности.
Batch ETL — обработка файлов, где порядок важен.

Barrier sync

Barrier sync — 🚧 общая линия старта, все потоки ждут друг друга

💬 Объяснение

Представь марафон.

Бегуны должны стартовать одновременно.

Даже если кто-то пришёл раньше — он ждёт остальных.

Когда все готовы — старт.

Это и есть Barrier Sync.

🗺️ Схема

BARRIER SYNC

Thread A ----\
Thread B ----- WAIT -----> continue together
Thread C ----/


Java

CyclicBarrier.await()


Reactive

zip()


Go

WaitGroup

📊 Сводная таблица

CyclicBarrier barrier =
    new CyclicBarrier(3);

Runnable worker = () -> {

    try {

        System.out.println("Ready");

        // поток ждёт остальных
        barrier.await();

        System.out.println("Start together");

    } catch(Exception e){}
};

Mono.zip(

    serviceA(),
    serviceB(),
    serviceC()

).subscribe(tuple -> {

    System.out.println("All results ready");

});

var wg sync.WaitGroup

wg.Add(3)

go func() {
    defer wg.Done()
}()

go func() {
    defer wg.Done()
}()

go func() {
    defer wg.Done()
}()

// ждём всех
wg.Wait()

🟨 Java Blocking — CyclicBarrier полезен в parallel algorithms.
🟣 Reactor — zip отлично подходит для объединения результатов сервисов.
🔵 Go — всегда вызывай wg.Add() до запуска goroutines.

Microservice orchestration — ожидание ответов нескольких сервисов.
Parallel computation — синхронизация этапов алгоритма.
Distributed pipelines — координация workers.

Conditional wait

Conditional wait — 🎣 ждать событие по условию, поток просыпается только когда условие выполнено

💬 Объяснение

Многие новички делают так:

sleep(1 second) → проверить условие → sleep снова.

Это называется polling.

Гораздо лучше — ждать событие реактивно.

То есть поток просыпается только тогда, когда условие выполнено.

Это называется Conditional Wait.

🗺️ Схема

CONDITIONAL WAIT

condition false -> wait

condition true -> resume


Java

Condition.await()


Reactive

filter + retry


Go

select

📊 Сводная таблица

Lock lock = new ReentrantLock();

Condition ready =
    lock.newCondition();

lock.lock();

try {

    // поток ждёт условия
    ready.await();

} finally {

    lock.unlock();
}

Flux.interval(Duration.ofSeconds(1))

.filter(v -> v > 5)

.next()

.subscribe(v ->
    System.out.println("Condition met")
);

select {

case msg := <-channel:

    fmt.Println(msg)

case <-time.After(time.Second):

    fmt.Println("timeout")

}

🟨 Java Blocking — Condition безопаснее wait/notify и даёт более точный контроль.
🟣 Reactor — filter + retry позволяет ждать событие без блокировки.
🔵 Go — select идеально подходит для сетевых серверов.

Event-driven системы.
Network servers.
Reactive pipelines обработки данных.

RW lock

RW lock — 📚 читальный зал библиотеки, много читателей но только один писатель

💬 Объяснение

Представь библиотеку.

Десятки людей могут читать книгу одновременно.

Но редактировать книгу может только один человек.

Это оптимизация доступа:

• много readers
• один writer

Это называется Read-Write Lock.

В Java есть специальный класс:

ReentrantReadWriteLock

В Go есть аналог:

sync.RWMutex

Reactive мире обычно избегает shared state, поэтому отдельного аналога нет.

🗺️ Схема

READ WRITE LOCK

Readers:
R1
R2
R3
R4

all allowed simultaneously

Writer:

W1

exclusive access


Java

readLock() / writeLock()


Reactive

avoid shared state


Go

RWMutex.RLock()
RWMutex.Lock()

📊 Сводная таблица

import java.util.concurrent.locks.*;

class Cache {

    private final ReentrantReadWriteLock lock =
        new ReentrantReadWriteLock();

    private int value = 0;

    public int read() {

        lock.readLock().lock();

        try {

            return value;

        } finally {

            lock.readLock().unlock();
        }
    }

    public void write(int v) {

        lock.writeLock().lock();

        try {

            value = v;

        } finally {

            lock.writeLock().unlock();
        }
    }
}

// reactive обычно избегает shared state

Flux.range(1,10)

.map(v -> v * 2)

.subscribe();

package main

import "sync"

var mutex sync.RWMutex
var value int

func read() int {

    mutex.RLock()
    defer mutex.RUnlock()

    return value
}

func write(v int) {

    mutex.Lock()
    defer mutex.Unlock()

    value = v
}

🟨 Java Blocking — RWLock идеально подходит для read-heavy workloads (например кеши).
🟣 Reactive — лучше полностью избегать shared mutable state.
🔵 Go — RWMutex быстрее обычного Mutex при большом количестве readers.

In-memory cache.
Configuration storage.
Read-heavy microservices.

Phaser sync

Phaser sync — 🏗️ стройка по этапам, участники синхронизируются на каждой фазе

💬 Объяснение

Представь стройку дома.

Есть этапы:

• фундамент
• стены
• крыша

Нельзя строить крышу пока не закончены стены.

Phaser — это барьер для нескольких фаз выполнения.

🗺️ Схема

PHASER

Phase 1 -> barrier
Phase 2 -> barrier
Phase 3 -> barrier

📊 Сводная таблица

Phaser phaser = new Phaser(3);

Runnable worker = () -> {

    System.out.println("Phase 1 done");

    phaser.arriveAndAwaitAdvance();

    System.out.println("Phase 2 done");
};

Flux.just("phase1","phase2")

.concatMap(stage ->
    process(stage)
)
.subscribe();

// пример кастомной синхронизации
// через каналы и waitgroup

🟨 Java Blocking — Phaser лучше CyclicBarrier когда фаз больше одной.
🟣 Reactive — pipeline этапы естественно заменяют phaser.
🔵 Go — иногда проще использовать несколько WaitGroup.

Game engines.
Simulation systems.
multi-phase algorithms.

Latch reuse

Latch reuse — 🔄 много стартов гонки, синхронизация используется снова и снова

💬 Объяснение

CountDownLatch — это одноразовый барьер.

Когда счётчик достиг нуля — всё.

Его нельзя использовать снова.

Поэтому для повторного использования нужно:

• создавать новый latch
• пересоздавать pipeline
• сбрасывать канал

🗺️ Схема

LATCH REUSE

Round 1 -> latch
Round 2 -> new latch
Round 3 -> new latch

📊 Сводная таблица

CountDownLatch latch =
    new CountDownLatch(3);

Runnable worker = () -> {

    latch.countDown();
};

latch.await();

Flux.range(1,3)

.flatMap(this::process)

.collectList()

.subscribe();

done := make(chan bool)

go func() {

    done <- true

}()

<-done

🟨 Java Blocking — CountDownLatch хорош для одноразовой синхронизации.
🟣 Reactive — pipeline создаётся заново для каждого потока данных.
🔵 Go — канал часто выступает сигналом завершения.

Integration tests orchestration.
Batch processing.
Signal completion workflows.

ВЫВОД

Все три мира решают одну проблему:

координацию параллельных задач.

Но делают это по-разному.

• 🟨 Java Blocking — богатый набор синхронизационных примитивов
• 🟣 Reactive Java — избегает shared state и использует pipelines
• 🔵 Go — минимализм: mutex + channels

Простое правило выбора:

• Shared state и высокая конкуренция → RWLock
• Много этапов алгоритма → Phaser
• Ожидание группы задач → Latch

Senior уровень — это не знание API.

Это понимание того, как задачи координируются.