Quando você escolhe threading, multiprocessing ou asyncio?

Question

Accepted Answer

Python oferece três modelos de concorrência, e a escolha correta depende principalmente de se seu trabalho é **I/O-bound** ou **CPU-bound** — uma decisão fortemente influenciada pelo GIL (que impede que threads executem código Python em paralelo).

## Os três modelos

```text
threading        → multiple threads, ONE process. GIL-limited for CPU.
multiprocessing  → multiple PROCESSES, each its own interpreter/GIL → true parallelism.
asyncio          → single thread, cooperative coroutines yielding at await points.
```

## threading — para concorrência I/O-bound

```python
from concurrent.futures import ThreadPoolExecutor

# ✅ good for I/O — the GIL is RELEASED during I/O waits, so waits overlap
with ThreadPoolExecutor(max_workers=10) as ex:
    results = list(ex.map(download_url, urls))   # many downloads concurrently
```

Threads funcionam bem para tarefas I/O-bound (rede, arquivos, DB) porque o GIL é liberado durante a espera — múltiplas esperas procedem concorrentemente. Elas **não** aceleram trabalho CPU-bound.

## multiprocessing — para paralelismo CPU-bound

```python
from concurrent.futures import ProcessPoolExecutor

# ✅ good for CPU — separate processes each have their own GIL → use all cores
with ProcessPoolExecutor(max_workers=4) as ex:
    results = list(ex.map(heavy_computation, data))   # genuine parallelism
```

Para trabalho pesado em CPU (processamento de imagens, matemática, manipulação de dados), processos separados contornam o GIL único e executam verdadeiramente em paralelo em múltiplos núcleos. O custo: overhead maior (inicialização de processo) e dados devem ser **serializados** entre processos (sem memória compartilhada por padrão).

## asyncio — para I/O de alta concorrência

```python
import asyncio
# ✅ best for MANY concurrent I/O operations (thousands) — lightest weight
await asyncio.gather(*(fetch(url) for url in urls))
```

asyncio manipula enormes quantidades de operações I/O concorrentes em uma thread, de forma mais eficiente que threads (sem overhead por-thread) — ideal para servidores e código de rede com alta concorrência.

## O guia de decisão

```text
CPU-bound (computation)              → multiprocessing
I/O-bound, moderate concurrency      → threading (simple, works with sync libraries)
I/O-bound, HIGH concurrency          → asyncio (thousands of connections, but needs
                                       async-compatible libraries)
Mixed CPU + I/O                       → combine (e.g. asyncio + a process pool for CPU)
```

## Por que isso importa

Escolher o modelo de concorrência correto é uma das decisões de desempenho Python mais consequentes, e acertar errado (o erro clássico: threads para trabalho CPU-bound, que o GIL torna inútil) leva a código que não escala.

A lógica orientadora flui do GIL: **threads/asyncio para I/O-bound** (GIL liberado durante esperas — concorrência funciona) e **multiprocessing para CPU-bound** (GILs separados para paralelismo real), com asyncio preferido quando a concorrência é muito alta.

Compreender os pontos fortes de cada modelo, custos (overhead de processo/serialização, requisitos de biblioteca do asyncio) e a decisão I/O-vs-CPU é essencial para escrever Python concorrente que realmente entrega desempenho.