Come sincronizzi l'accesso allo stato condiviso?

Question

Accepted Answer

**Sincronizzazione** coordina l'accesso dei thread allo stato mutevole condiviso in modo che le operazioni non si intreccino pericolosamente, prevenendo **race condition**. Java offre diversi meccanismi, dalla parola chiave `synchronized` integrata ai lock espliciti e agli atomic lock-free.

## synchronized — esclusione reciproca (intrinsic lock)

```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` assicura che solo un thread esegua il codice protetto alla volta (esclusione reciproca) e garantisce **visibilità** — i cambiamenti di un thread diventano visibili agli altri (supera la memoria barrier).

## volatile — visibilità senza atomicità

```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` garantisce che le letture/scritture di una variabile siano visibili tra i thread — ma **NON** rende atomiche le operazioni composte (come `count++`). Usalo per semplici flag, non per read-modify-write.

## Atomic class — atomicità lock-free

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

Le classi Atomic forniscono operazioni thread-safe senza lock — spesso più veloci di `synchronized` per semplici contatori/accumulatori.

## Explicit Lock — più controllo

```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` offre funzionalità che `synchronized` non ha: `tryLock()` (non-blocking), attese temporizzate, fairness e separazione lettura-scrittura.

## I pericoli da gestire

```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
```

## Perché è importante

La sincronizzazione è essenziale per la correttezza ogni volta che più thread accedono a uno stato mutevole condiviso — senza di essa, le race condition producono dati corrotti e guasti intermittenti, quasi impossibili da debuggare.

Conoscere gli strumenti e le loro precise garanzie è critico: `synchronized` (esclusione reciproca + visibilità), `volatile` (solo visibilità — NON atomicità, un malinteso comune), classi atomic (lock-free per operazioni semplici) e Explicit Lock (controllo avanzato).

È altrettanto importante comprendere i pericoli — **deadlock** e over-synchronization che danneggiano le prestazioni — e la disciplina di sincronizzare minimamente e coerentemente.

Questa è una conoscenza fondamentale, ad alta posta in gioco, per il Java lato server concorrente e un argomento di intervista profondo che distingue gli sviluppatori che sanno scrivere codice multithreaded corretto.