¿Cómo sincronizas el acceso al estado compartido?

Question

Accepted Answer

**Synchronization** coordina el acceso de los threads al estado mutable compartido para que las operaciones no se intercalen peligrosamente, previniendo **race conditions**. Java ofrece varios mecanismos, desde la palabra clave `synchronized` integrada hasta locks explícitos y atómicas sin locks.

## synchronized — exclusión mutua (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` asegura que solo un thread ejecute el código protegido a la vez (exclusión mutua) y proporciona **visibility** — los cambios realizados por un thread se hacen visibles a otros (cruza la barrera de memoria).

## volatile — visibility sin atomicity

```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` garantiza que las lecturas/escrituras de una variable sean visibles entre threads — pero **NO** hace que las operaciones compuestas (como `count++`) sean atómicas. Úsalo para banderas simples, no para read-modify-write.

## Atomic classes — atomicity sin locks

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

Las clases Atomic proporcionan operaciones thread-safe sin locks — a menudo más rápidas que `synchronized` para contadores/acumuladores simples.

## Explicit Locks — más control

```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` ofrece características que `synchronized` no tiene: `tryLock()` (non-blocking), esperas temporizadas, fairness, y separación de lectura-escritura.

## Los peligros a gestionar

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

## Por qué es importante

La sincronización es esencial para la corrección siempre que múltiples threads accedan al estado mutable compartido — sin ella, las race conditions producen datos corruptos y fallos intermitentes, prácticamente imposibles de depurar.

Conocer las herramientas y sus garantías precisas es crítico: `synchronized` (exclusión mutua + visibility), `volatile` (visibility solo — NO atomicity, un malentendido común), clases atómicas (lock-free para operaciones simples), y Locks explícitos (control avanzado).

Igualmente importante es entender los peligros — **deadlock** y sobre-sincronización perjudicando el rendimiento — y la disciplina de sincronizar mínima y consistentemente.

Este es conocimiento central y de alto riesgo para Java concurrente del lado servidor, y un tema de entrevista profundo que distingue a los desarrolladores que pueden escribir código multithreaded correcto.