Como você sincroniza o acesso a estado compartilhado?

Question

Accepted Answer

**Sincronização** coordena o acesso de threads ao estado mutável compartilhado para que as operações não se intercalem perigosamente, prevenindo **condições de corrida**. Java oferece vários mecanismos, desde a palavra-chave `synchronized` integrada até locks explícitos e atômicos sem lock.

## synchronized — exclusão mútua (locks intrínsecos)

```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` garante que apenas uma thread execute o código protegido por vez (exclusão mútua) e fornece **visibilidade** — mudanças de uma thread se tornam visíveis para outras (atravessa a barreira de memória).

## volatile — visibilidade sem atomicidade

```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` garante que leituras/escritas de uma variável sejam visíveis entre threads — mas **NÃO** torna operações compostas (como `count++`) atômicas. Use para sinalizadores simples, não para leitura-modificação-escrita.

## Classes Atomic — atomicidade sem lock

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

Classes atômicas fornecem operações thread-safe sem locks — geralmente mais rápidas que `synchronized` para contadores/acumuladores simples.

## Locks Explícitos — mais controle

```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` oferece recursos que `synchronized` não possui: `tryLock()` (não-bloqueante), esperas cronometradas, fairness e separação leitura-escrita.

## Os perigos a gerenciar

```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 que isso importa

Sincronização é essencial para correção sempre que múltiplas threads acessam estado mutável compartilhado — sem ela, condições de corrida produzem dados corrompidos e falhas intermitentes, quase impossíveis de depurar.

Conhecer as ferramentas e suas garantias precisas é crítico: `synchronized` (exclusão mútua + visibilidade), `volatile` (apenas visibilidade — NÃO atomicidade, um mal-entendido comum), classes atômicas (sem lock para operações simples) e Locks explícitos (controle avançado).

Igualmente importante é compreender os perigos — **deadlock** e sincronização excessiva prejudicando o desempenho — e a disciplina de sincronizar minimamente e consistentemente.

Este é conhecimento essencial e de alto risco para Java concorrente no lado do servidor e um tópico profundo em entrevistas que distingue desenvolvedores que conseguem escrever código multithreaded correto.