O que causa deadlocks e como você os previne?

Question

Accepted Answer

Um **deadlock** ocorre quando duas (ou mais) transações cada uma mantém um lock que a outra precisa, então nenhuma pode prosseguir — elas ficam presas esperando uma pela outra eternamente. Bancos de dados detectam deadlocks e os resolvem **abortando uma transação** (a "vítima"), que deve tentar novamente. Entender as causas e prevenção é importante para aplicações concorrentes.

## Como um deadlock acontece

```text
Transaction A: locks row 1, then wants row 2
Transaction B: locks row 2, then wants row 1
→ A waits for B (to release row 2), B waits for A (to release row 1) → DEADLOCK
  Neither can proceed; they're waiting on each other in a cycle.
```

```sql
-- Transaction A                    -- Transaction B (concurrent)
BEGIN;                              BEGIN;
UPDATE accounts SET .. WHERE id=1;  UPDATE accounts SET .. WHERE id=2;  -- each locks a row
UPDATE accounts SET .. WHERE id=2;  UPDATE accounts SET .. WHERE id=1;  -- each wants the OTHER's
-- → DEADLOCK: the database aborts one transaction
```

## Como bancos de dados tratam deadlocks

```text
Databases DETECT deadlocks (find the cycle of waiting transactions) and resolve them
by ABORTING one transaction (the victim) with a deadlock error → it must RETRY.
→ Your application must handle the deadlock error and retry the transaction.
```

## Estratégias de prevenção

```text
✓ CONSISTENT LOCK ORDERING — always acquire locks in the SAME order (e.g. always
  lock the lower account id first). This breaks the cycle → the #1 prevention technique.
✓ Keep transactions SHORT — hold locks for less time (less chance to overlap)
✓ Access tables/rows in a consistent order across all transactions
✓ Use lower isolation levels where appropriate (less locking)
✓ Avoid user interaction / long operations inside a transaction (holds locks too long)
✓ Handle deadlock errors with RETRY logic (deadlocks can't be fully eliminated)
```

A **#1 prevenção** é **ordenação consistente de locks**: se todas as transações adquirem locks na mesma ordem (por ex. sempre o id menor primeiro), a espera circular não pode se formar.

## O padrão de retry

```text
Since deadlocks can still happen, applications should catch the deadlock error and
RETRY the transaction (often a few times with a small delay). This is standard
resilience for concurrent database code.
```

## Por que isso importa

Deadlocks são um problema de concorrência importante em bancos de dados — eles ocorrem em qualquer aplicação com transações concorrentes que modificam dados sobrepostos, e entendê-los é conhecimento valioso de nível sênior para construir sistemas concorrentes robustos.

Entender a **causa** — duas transações cada uma mantendo um lock que a outra precisa, criando uma espera circular onde nenhuma pode prosseguir — é o fundamento.

Saber como bancos de dados **tratam** deadlocks (detectando o ciclo e abortando uma transação como vítima, que deve tentar novamente) é importante porque significa que sua **aplicação deve lidar com erros de deadlock com lógica de retry** — deadlocks não podem ser totalmente eliminados, então código concorrente resiliente captura o erro de deadlock e tenta novamente (um padrão padrão e importante).

As **estratégias de prevenção** são o conhecimento prático chave, especialmente a técnica #1: **ordenação consistente de locks** (sempre adquirindo locks na mesma ordem em todas as transações, o que quebra a condição de espera circular que causa deadlocks) — junto com manter transações curtas (mantendo locks brevemente), acessando recursos em uma ordem consistente, e evitando operações longas dentro de transações.

Como deadlocks causam problemas reais (transações falhadas, erros, desempenho degradado) em aplicações de banco de dados concorrentes, e como entender sua causa (esperas circulares de locks), prevenção (especialmente ordenação consistente de locks e transações curtas), e a necessidade de lógica de retry é o que permite você construir sistemas concorrentes robustos, entender deadlocks é conhecimento valioso de nível sênior para qualquer aplicação com acesso significativo a banco de dados concorrente — uma preocupação operacional frequentemente relevante e um tópico de entrevista avançado comum demonstrando compreensão de concorrência de banco de dados e resiliência.