Jak synchronizować dostęp do stanu współdzielonego?

Question

Accepted Answer

**Synchronizacja** koordynuje dostęp wątków do współdzielonego mutable'a stanu tak, aby operacje nie przeplatały się niebezpiecznie, zapobiegając **race conditions**. Java oferuje kilka mechanizmów, od wbudowanego słowa kluczowego `synchronized` po jawne locki i atomowe operacje bez locków.

## synchronized — wzajemne wykluczanie (intrinsic locks)

```java
class BankAccount {
    private double balance;

// synchronized method — acquires the object's lock; only ONE thread at a time
    public synchronized void withdraw(double amount) {
        if (balance >= amount) {
            balance -= amount;   // protected — no interleaving
        }
    }
    // synchronized block — finer-grained, lock on a specific object
    public void deposit(double amount) {
        synchronized (this) {
            balance += amount;
        }
    }
}
```

`synchronized` zapewnia, że tylko jeden wątek wykonuje chroniony kod jednocześnie (wzajemne wykluczanie) i zapewnia **widoczność** — zmiany dokonane przez jeden wątek stają się widoczne dla innych (przekracza barierę pamięci).

## volatile — widoczność bez atomowości

```java
private volatile boolean running = true;   // guarantees VISIBILITY across threads

public void stop() { running = false; }     // other threads see the change immediately
public void run() { while (running) { ... } } // without volatile, might never see false
```

`volatile` gwarantuje, że odczyty/zapisy zmiennej są widoczne między wątkami — ale **NIE** czyni operacji złożonych (takich jak `count++`) atomowymi. Używaj go dla prostych flag, a nie dla operacji odczyt-modyfikacja-zapis.

## Klasy Atomic — atomowość bez locków

```java
AtomicInteger counter = new AtomicInteger(0);
counter.incrementAndGet();        // atomic ++ without locking (uses CPU CAS instructions)
counter.compareAndSet(5, 10);     // atomic conditional update
```

Klasy atomowe zapewniają operacje thread-safe bez locków — często szybsze niż `synchronized` dla prostych liczników/akumulatorów.

## Jawne Locki — większa kontrola

```java
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
    // critical section
} finally {
    lock.unlock();   // ALWAYS unlock in finally
}
// ReadWriteLock allows many concurrent readers but exclusive writers
```

`ReentrantLock` oferuje cechy, których `synchronized` pozbawiony: `tryLock()` (nieblokujący), czasowe oczekiwania, uczciwość i separację odczyt-zapis.

## Zagrożenia do zarządzania

```text
⚠️ Deadlock — two threads each hold a lock the other needs → both stuck forever
   (avoid by always acquiring locks in a consistent order)
⚠️ Performance — over-synchronizing serializes everything, killing concurrency
   (synchronize the SMALLEST necessary section)
⚠️ Forgetting to unlock (with explicit Locks) → use try/finally
```

## Dlaczego to ważne

Synchronizacja jest niezbędna dla poprawności zawsze, gdy wiele wątków ma dostęp do współdzielonego mutable'a stanu — bez niej race conditions powodują uszkodzenie danych i sporadyczne, niemal niemożliwe do debugowania błędy.

Znajomość narzędzi i ich precyzyjnych gwarancji jest krytyczna: `synchronized` (wzajemne wykluczanie + widoczność), `volatile` (tylko widoczność — NIE atomowość, częste nieporozumienie), klasy atomowe (bez locków dla prostych operacji) i jawne Locki (zaawansowana kontrola).

Równie ważne jest zrozumienie zagrożeń — **deadlock** i nadmierna synchronizacja szkodzące wydajności — oraz dyscyplina synchronizowania minimalnie i konsekwentnie.

To jest fundamentalna, wysokostawna wiedza dla współbieżnego, serverowego Java i głębokie pytanie na rozmowę, które odróżnia programistów potrafących pisać poprawny kod wielowątkowy.