Comment synchronisez-vous l'accès à l'état partagé ?

Question

Accepted Answer

**La synchronisation** coordonne l'accès des threads à l'état mutable partagé afin que les opérations ne s'entrelacent pas dangereusement, en prévenant les **conditions de course**. Java offre plusieurs mécanismes, du mot-clé `synchronized` intégré aux verrous explicites et aux atomiques sans verrous.

## synchronized — exclusion mutuelle (verrous intrinsèques)

```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` assure qu'un seul thread exécute le code protégé à la fois (exclusion mutuelle) et fournit une **visibilité** — les modifications d'un thread deviennent visibles aux autres (cela franchit la barrière mémoire).

## volatile — visibilité sans 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` garantit que les lectures/écritures d'une variable sont visibles entre les threads — mais ne rend **PAS** atomiques les opérations composées (comme `count++`). Utilisez-le pour les drapeaux simples, pas pour les opérations lecture-modification-écriture.

## Classes Atomic — atomicité sans verrou

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

Les classes Atomic fournissent des opérations thread-safe sans verrous — souvent plus rapides que `synchronized` pour les compteurs/accumulateurs simples.

## Verrous explicites — plus de contrôle

```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 des fonctionnalités que `synchronized` ne possède pas : `tryLock()` (non-bloquant), les attentes temporisées, l'équité et la séparation lecture-écriture.

## Les dangers à gérer

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

## Pourquoi c'est important

La synchronisation est essentielle pour la correction chaque fois que plusieurs threads accèdent à un état mutable partagé — sans elle, les conditions de course produisent des données corrompues et des défaillances intermittentes, presque impossibles à déboguer.

Connaître les outils et leurs garanties précises est critique : `synchronized` (exclusion mutuelle + visibilité), `volatile` (visibilité uniquement — PAS d'atomicité, une idée fausse courante), les classes Atomic (sans verrou pour les opérations simples) et les verrous explicites (contrôle avancé).

Également important est la compréhension des dangers — **interblocage** et sur-synchronisation nuisant aux performances — et la discipline de synchroniser minimalement et régulièrement.

Ceci est une connaissance fondamentale, à enjeux élevés, pour le Java côté serveur concurrent et un sujet d'entretien approfondi qui distingue les développeurs qui peuvent écrire du code multithreadé correct.