🧩 Coordination: how to synchronize chaos — Java Blocking vs Reactor vs Go

Concurrency is not about “starting many threads”. It’s about agreements between them.

Imagine a restaurant kitchen: — cooks (threads / goroutines) — orders (tasks) — and the main question: how do they coordinate?

Today you will see 3 worlds:

• 🟨 Blocking Java — “everyone waits”
• 🟣 Reactor (Reactive Streams) — “everything flows, no one blocks”
• 🔵 Go — “simple goroutines + channels”

Wait All Tasks (Barrier Join)

Wait All Tasks — 🎬 «final credits» 🍿, waiting for everyone to finish

💬 Explanation

You start several tasks — and want to continue only when all are complete.

It's like a team of builders: you can't hand over the house until everyone has finished their part.

• Java: CountDownLatch — a counter that decrements to zero
• Reactor: Mono.when — collects several async streams
• Go: WaitGroup — added tasks → waiting

🗺️ Diagram

Tasks:
 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()

// creating latch for 3 tasks
CountDownLatch latch = new CountDownLatch(3);

Runnable task = () -> {
    // performing work
    System.out.println("Task done");
    
    // decrementing the counter
    latch.countDown();
};

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

// waiting for all to complete
latch.await();

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

// three asynchronous streams
Mono<String> m1 = Mono.just("A");
Mono<String> m2 = Mono.just("B");
Mono<String> m3 = Mono.just("C");

// waiting for all to complete
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")
}()

// blocking until all finish
wg.Wait()

fmt.Println("All done")

For 🟨 Java Blocking: use CountDownLatch only for short-lived tasks — under the hood the thread is really “sleeping” and consuming resources.

For 🟣 Reactor: do not insert .block() — it breaks the entire non-blocking pipeline and turns it into blocking hell.

For 🔵 Go: always place defer wg.Done() — otherwise you'll forget and get a deadlock.

API gateway (🟣 Reactor): collect responses from several services → Mono.when → faster and non-blocking.

Batch processing (🟨 Java): started 5 tasks → waited → recorded the result — simple and clear.

Parallel workers (🔵 Go): processing a queue — WaitGroup waits for all workers to complete.

Mutex (Critical Section)

Mutex — 🔒 «one key to the door» 🚪, only one inside

💬 Explanation

When several threads want to modify the same data — control is needed.

Otherwise, there will be chaos: race condition.

Mutex = «only one goes inside».

• Java: synchronized
• Reactor: avoids shared state
• Go: sync.Mutex

🗺️ Diagram

Threads:
 T1 ─┐
 T2 ─┼──▶ [ LOCK ] → critical section → unlock
 T3 ─┘

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

🟣 Reactor:
 no lock → immutable / sequence

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

private int counter = 0;

public synchronized void inc() {
    // only one thread here
    counter++;
}

// avoiding shared state
Flux.range(1, 10)
    .map(i -> i * 2) // immutable transform
    .subscribe();

var mu sync.Mutex
counter := 0

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

For 🟨 Java: avoid nested synchronized — under the hood this can lead to deadlock through monitor locks.

For 🟣 Reactor: do not carry mutable state — the power of reactive is that data is not shared between threads.

For 🔵 Go: if you use a mutex — consider if it can be replaced with a channel (message passing).

Cache (🟨 Java): synchronize access to Map — otherwise race condition.

Streaming pipeline (🟣 Reactor): better to do immutable transformations — no locks needed.

Low-level services (🔵 Go): mutex for counters, metrics, shared state.

First Result Wins

First Result Wins — 🏁 «the first one gets the slippers» ⚡, we take the fastest

💬 Explanation

You launch several tasks — and take the first result.

The others — you ignore or cancel.

It's like a request to several CDNs — we take the fastest response.

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

🗺️ Diagram

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

the others are canceled / ignored

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

// take the first one that completes
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)
}

For 🟨 Java: be sure to think about canceling the other tasks — otherwise, they continue to run and consume resources.

For 🟣 Reactor: use timeout + fallback — this strengthens the pattern.

For 🔵 Go: close channels or add context — otherwise, goroutine leaks.

Multi-CDN (all): send requests → take the fastest → reduce latency.

Failover (🟨 Java): main service + backup — anyOf.

High-load services (🟣 Reactor): race between cache and DB.

Network clients (🔵 Go): select between several data sources.

Join Futures

Join Futures — 🧺 collect a basket of results, many async tasks → one final result

💬 Explanation

Imagine a restaurant kitchen.

You ordered:

• burger
• fries
• drink

Each dish is prepared separately.

But the waiter brings one tray.

This is Join Futures.

We start several async tasks and then collect their results into one.

In different worlds, this is done differently:

• 🟨 Java Blocking — list of Future + get()
• 🟣 Reactor — flatMap + collect
• 🔵 Go — goroutines + channel

🗺️ Diagram

JOIN FUTURES

Task A ----\
              \
Task B ----- JOIN ----> final result
              /
Task 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()

does not block thread


Go

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

results <- channel

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

📊 Summary Table

ExecutorService pool = Executors.newFixedThreadPool(3);

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

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

    // sending task to thread pool
    futures.add(pool.submit(() -> {

        // simulating work
        Thread.sleep(1000);

        return 10;
    }));
}

int sum = 0;

for (Future<Integer> future : futures) {

    // BLOCKING until result is ready
    sum += future.get();
}

System.out.println(sum);

Flux.range(1,3)

    // launching async tasks
    .flatMap(i -> Mono.fromCallable(() -> {

        Thread.sleep(1000);

        return 10;

    }))

    // collecting all results
    .collectList()

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

    .subscribe(System.out::println);

package main

import "fmt"

func worker(ch chan int) {

    // simulating work
    ch <- 10
}

func main() {

    results := make(chan int)

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

        // launching goroutine
        go worker(results)
    }

    sum := 0

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

        // getting result
        sum += <-results
    }

    fmt.Println(sum)
}

🟨 Java Blocking — never call future.get() inside a large loop without a thread pool. This turns async code back into synchronous.
🟣 Reactor — avoid .block() inside the reactive pipeline. This breaks the entire model of non-blocking execution.
🔵 Go — always control the number of reads from the channel. If you sent 5 messages — you need 5 reads.

API aggregator (Backend For Frontend) — collecting data from multiple services. Very typical Join Futures.
Search service — searching across multiple indexes.
Microservice gateway — combining responses from several downstream services.

Semaphore limit

Semaphore limit — 🚦 semaphore of tasks, limiting the number of parallel operations

💬 Explanation

Imagine a bridge.

Only 10 cars can pass at the same time.

If the 11th car arrives — it waits.

This is done by Semaphore.

🗺️ Diagram

LIMIT CONCURRENCY

Tasks -> [ LIMIT 5 ] -> execution


Java Blocking

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


Reactor

flatMap(task, concurrency=5)


Go

buffered channel size=5

📊 Summary Table

Semaphore semaphore = new Semaphore(5);

semaphore.acquire();

try {

    // execute the task
    callService();

} finally {

    // release the slot
    semaphore.release();
}

Flux.range(1,100)

.flatMap(i ->
    callService(i),
    5 // limit concurrency
)

.subscribe();

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

sem <- struct{}{}

go func() {

    callService()

    <-sem
}()

🟨 Java Blocking — always release semaphore in finally, otherwise the system will gradually hang.
🟣 Reactor — always specify concurrency in flatMap if calling external service.
🔵 Go — buffered channel is perfect as semaphore.

Database connection limiting.
External API rate limiting.
Worker pool load management.

Join Service

Join Service — 🎬 wait for all actors to finish, start task set and wait for completion

💬 Explanation

Imagine a movie.

A scene is considered complete only when all actors have finished.

That is the Join Service.

🗺️ Scheme

TASK GROUP EXECUTION

Task A
Task B
Task C

       ↓

WAIT ALL FINISH


Java

invokeAll()


Reactor

merge()


Go

WaitGroup

📊 Summary Table

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 is great for batch tasks.
🟣 Reactor — merge is useful for combining service streams.
🔵 Go — WaitGroup is the simplest way to synchronize goroutines.

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

Thread coordination

Thread coordination — 🔔 a call between threads, one thread waits for a signal from another

💬 Explanation

Imagine a restaurant kitchen.

One chef is preparing a steak. Another one is preparing a side dish.

But the side dish can only be started after the signal.

The chef shouts:

“Ready!”

And the second chef starts working.

This is Thread coordination.

Threads wait for each other's signals.

In different worlds:

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

🗺️ Diagram

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

📊 Summary Table

class Worker {

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

    public void waitForSignal() throws Exception {

        synchronized (lock) {

            while (!ready) {

                // thread goes to sleep
                lock.wait();
            }

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

    public void sendSignal() {

        synchronized (lock) {

            ready = true;

            // waking up the waiting thread
            lock.notify();
        }
    }
}

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

signal
    .doOnNext(v -> {

        // the event acts as a signal
        System.out.println("Signal received");
    })
    .subscribe();

package main

import "fmt"

func main() {

    signal := make(chan bool)

    go func() {

        // thread waits for a signal
        <-signal

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

    // sending the signal
    signal <- true
}

🟨 Java Blocking — always use wait() inside a while. This protects against false awakenings from the JVM.
🟣 Reactor — think of events as signals between parts of the pipeline.
🔵 Go — never send to a channel if no one is reading.

Producer-consumer pipeline — one thread produces data, another waits for a readiness signal.
Event-driven systems — react to events instead of polling.
Synchronization of data processing stages.

Race control

Race control — 🏁 one finish corridor, access control to data

💬 Explanation

Imagine an ATM.

Only one person can approach it.

If two try to do so at the same time — chaos will ensue.

This is called a race condition.

That's why access control is needed.

In different worlds:

• 🟨 Java — synchronized
• 🟣 Reactor — concatMap (guarantees order)
• 🔵 Go — mutex

🗺️ Diagram

RACE CONTROL

Task A \
        -> critical section
Task B /

only one allowed


Java

synchronized block


Reactive

concatMap -> sequential processing


Go

mutex lock

📊 Summary Table

class Counter {

    private int value = 0;

    public synchronized void increment() {

        // only one thread
        // can enter here

        value++;
    }
}

Flux.range(1,5)

.concatMap(i -> {

    // tasks are executed
    // strictly in order

    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 — keep synchronized blocks as short as possible.
🟣 Reactor — concatMap is useful when the order of events is important.
🔵 Go — use defer mutex.Unlock() to avoid forgotten unlocks.

Updating shared cache.
Sequential processing of financial operations.
Event queues.

Fork-Join

Fork-Join — 🌳 split the task tree, solve branches in parallel and collect the result

💬 Explanation

Imagine a huge task.

For example — to sum millions of numbers.

One thread will take a very long time.

Therefore, we:

• split the task
• solve parts in parallel
• combine the result

This is Fork-Join.

🗺️ Diagram

FORK JOIN

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

join results

📊 Summary table

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 is perfect for CPU-heavy tasks.
🟣 Reactor — use parallel() only for CPU tasks, not IO.
🔵 Go — better to limit the worker pool to the number of CPUs.

Big data processing.
Parallel computation.
Distributed batch processing.

Ordered join

Ordered join — 📦 collect packages by number, parallel tasks → results in the original order

💬 Explanation

Imagine a delivery pipeline.

Five couriers deliver packages simultaneously. But the customer must receive them in the correct order.

Even if package №3 arrives before №2 — it needs to be waited for.

This is Ordered Join.

We run tasks in parallel, but collect the result in the original order.

In different technologies:

• 🟨 Java — list of Future
• 🟣 Reactor — concat
• 🔵 Go — ordered channel

🗺️ Diagram

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

📊 Summary Table

ExecutorService pool =
    Executors.newFixedThreadPool(3);

// list of tasks
List<Callable<Integer>> tasks = List.of(
    () -> 1,
    () -> 2,
    () -> 3
);

// run all tasks
List<Future<Integer>> futures =
    pool.invokeAll(tasks);

// get results strictly in order
for (Future<Integer> f : futures) {

    // get() blocks the thread
    // until the result is ready
    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 guarantees
// order preservation

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

package main

import "fmt"

func worker(id int, ch chan int) {

    // send result
    ch <- id
}

func main() {

    ch := make(chan int)

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

        go worker(i, ch)
    }

    // read results
    // and can order them
    for i := 0; i < 3; i++ {

        fmt.Println(<-ch)
    }
}

🟨 Java Blocking — the list of Future automatically preserves the order of tasks, so it's safe to use invokeAll.
🟣 Reactor — concat ensures strict order of events but reduces pipeline parallelism.
🔵 Go — for ordering results, it's better to use indexed structures.

Aggregation API — needs to return service data strictly in the same order.
Streaming pipelines — processing events in a fixed sequence.
Batch ETL — processing files where order is important.

Barrier sync

Barrier sync — 🚧 common start line, all threads wait for each other

💬 Explanation

Imagine a marathon.

Runners must start simultaneously.

Even if someone arrives earlier — they wait for the others.

When everyone is ready — start.

This is Barrier Sync.

🗺️ Diagram

BARRIER SYNC

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


Java

CyclicBarrier.await()


Reactive

zip()


Go

WaitGroup

📊 Summary Table

CyclicBarrier barrier =
    new CyclicBarrier(3);

Runnable worker = () -> {

    try {

        System.out.println("Ready");

        // thread waits for the others
        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()
}()

// wait for all
wg.Wait()

🟨 Java Blocking — CyclicBarrier is useful in parallel algorithms.
🟣 Reactor — zip is great for combining results from services.
🔵 Go — always call wg.Add() before starting goroutines.

Microservice orchestration — waiting for responses from multiple services.
Parallel computation — synchronization of algorithm stages.
Distributed pipelines — coordination of workers.

Conditional wait

Conditional wait — 🎣 wait for an event based on a condition, the thread wakes up only when the condition is met

💬 Explanation

Many beginners do this:

sleep(1 second) → check condition → sleep again.

This is called polling.

Much better — wait for an event reactively.

That is, the thread wakes up only when the condition is met.

This is called Conditional Wait.

🗺️ Diagram

CONDITIONAL WAIT

condition false -> wait

condition true -> resume


Java

Condition.await()


Reactive

filter + retry


Go

select

📊 Summary table

Lock lock = new ReentrantLock();

Condition ready =
    lock.newCondition();

lock.lock();

try {

    // the thread waits for the condition
    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 is safer than wait/notify and provides more precise control.
🟣 Reactor — filter + retry allows waiting for an event without blocking.
🔵 Go — select is perfect for network servers.

Event-driven systems.
Network servers.
Reactive data processing pipelines.

RW lock

RW lock — 📚 reading room of the library, many readers but only one writer

💬 Explanation

Imagine a library.

Dozens of people can read a book simultaneously.

But only one person can edit the book.

This is an optimization of access:

• many readers
• one writer

This is called Read-Write Lock.

In Java, there is a special class:

ReentrantReadWriteLock

In Go, there is an analog:

sync.RWMutex

The reactive world usually avoids shared state, so there is no separate analog.

🗺️ Diagram

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()

📊 Summary Table

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 usually avoids 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 is perfect for read-heavy workloads (e.g. caches).
🟣 Reactive — it's better to completely avoid shared mutable state.
🔵 Go — RWMutex is faster than regular Mutex with a large number of readers.

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

Phaser sync

Phaser sync — 🏗️ construction in stages, participants synchronize at each phase

💬 Explanation

Imagine building a house.

There are stages:

• foundation
• walls
• roof

You cannot build the roof until the walls are finished.

Phaser is a barrier for multiple phases of execution.

🗺️ Scheme

PHASER

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

📊 Summary Table

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();

// custom synchronization example
// through channels and waitgroup

🟨 Java Blocking — Phaser is better than CyclicBarrier when there are more than one phase.
🟣 Reactive — pipeline stages naturally replace phaser.
🔵 Go — sometimes it's easier to use multiple WaitGroups.

Game engines.
Simulation systems.
multi-phase algorithms.

Latch reuse

Latch reuse — 🔄 many starts of the race, synchronization is used over and over again

💬 Explanation

CountDownLatch is a one-time barrier.

When the counter reaches zero — that's it.

It cannot be used again.

Therefore, for reuse, you need to:

• create a new latch
• recreate the pipeline
• reset the channel

🗺️ Diagram

LATCH REUSE

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

📊 Summary Table

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 is good for one-time synchronization.
🟣 Reactive — pipeline is recreated for each data stream.
🔵 Go — channel often serves as a completion signal.

Integration tests orchestration.
Batch processing.
Signal completion workflows.

OUTPUT

All three worlds solve one problem:

the coordination of parallel tasks.

But they do it differently.

• 🟨 Java Blocking — a rich set of synchronization primitives
• 🟣 Reactive Java — avoids shared state and uses pipelines
• 🔵 Go — minimalism: mutex + channels

A simple selection rule:

• Shared state and high concurrency → RWLock
• Many stages of the algorithm → Phaser
• Waiting for a group of tasks → Latch

Senior level is not knowledge of the API.

It is understanding how tasks are coordinated.