O que é um deadlock, e como preveni-lo, evitá-lo ou detectá-lo?

Question

IT Interview Practice · Accepted Answer

Um **deadlock** é um estado em que duas ou mais threads estão cada uma **bloqueada para sempre**, cada uma esperando por um recurso que outra mantém. Nada progride.

## As quatro condições necessárias (de Coffman)

As quatro precisam valer ao mesmo tempo — remova qualquer uma e o deadlock se torna impossível:

```text
1. Mutual exclusion   → a resource is held exclusively (only one holder at a time)
2. Hold and wait      → a thread holds one resource while waiting to acquire another
3. No preemption      → resources can't be forcibly taken; only released voluntarily
4. Circular wait      → a cycle: T1 waits for R2 (held by T2), T2 waits for R1 (held by T1)
```

```text
   T1 ──holds──▶ R1        T1 wants R2 ──▶ (held by T2)
   T2 ──holds──▶ R2        T2 wants R1 ──▶ (held by T1)   ← cycle = deadlock
```

## Lidando com deadlock

- **Prevenção** — projete de modo que uma das condições nunca possa valer. O mais prático: elimine o **circular wait** impondo uma **ordem global de locks** (sempre adquira A antes de B). Ou ataque o **hold-and-wait** pegando todos os locks necessários de uma vez.
- **Evitação (avoidance)** — conceda um pedido apenas se o sistema permanecer em um estado "seguro" no qual toda thread ainda possa terminar (o **algoritmo do Banqueiro**). Ele precisa saber de antemão a necessidade máxima de recursos de cada thread, então raramente é usado na prática.
- **Detecção e recuperação** — deixe os deadlocks acontecerem, escaneie periodicamente o **wait-for graph** em busca de um ciclo, e então recupere matando ou fazendo rollback de uma vítima. Os bancos de dados fazem exatamente isso: detectam deadlocks e abortam uma transação com um erro de "deadlock victim".
- **Ignorar (o "algoritmo do avestruz")** — se os deadlocks são raros, apenas reinicie; muitos OSes aceitam isso para alguns recursos.

## Por que isso importa

Deadlock é um tópico clássico de entrevista porque o framework das quatro condições é uma ferramenta de diagnóstico precisa: diante de um travamento, você pode perguntar "qual condição eu consigo quebrar?" Em sistemas reais a resposta preferida é a **ordem consistente de locks** (que previne o circular wait) — uma regra que você aplica toda vez que pega mais de um lock. Reconhecer que seu banco de dados lança erros de deadlock-victim, e saber simplesmente refazer (retry) aquela transação, é uma aplicação prática direta.

As quatro condições necessárias (de Coffman)

Lidando com deadlock

Por que isso importa

Perguntas relacionadas