¿Cuándo eliges threading, multiprocessing o asyncio?

Question

Accepted Answer

Python ofrece tres modelos de concurrencia, y elegir correctamente depende sobre todo de si tu trabajo está **limitado por I/O** o **limitado por CPU**, una decisión muy condicionada por el GIL (que impide que los hilos ejecuten código Python en paralelo).

## Los tres 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 concurrencia limitada por I/O

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

Los hilos funcionan bien para tareas limitadas por I/O (red, archivos, BD) porque el GIL se libera durante la espera: varias esperas avanzan de forma concurrente. **No** aceleran el trabajo limitado por CPU.

## multiprocessing: para paralelismo limitado por CPU

```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 el trabajo intensivo en CPU (procesamiento de imágenes, cálculos, procesamiento de datos), los procesos separados evitan el GIL único y se ejecutan realmente en paralelo sobre múltiples núcleos. El costo: mayor sobrecarga (arranque de procesos) y los datos deben **serializarse** entre procesos (sin memoria compartida por defecto).

## asyncio: para I/O de alta concurrencia

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

asyncio maneja números enormes de operaciones de I/O concurrentes en un solo hilo, de forma más eficiente que los hilos (sin sobrecarga por hilo): ideal para servidores y código de red de alta concurrencia.

## La guía de decisión

```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 qué es importante

Elegir el modelo de concurrencia correcto es una de las decisiones de rendimiento más trascendentales en Python, y equivocarse (el error clásico: hilos para trabajo limitado por CPU, que el GIL vuelve inútiles) lleva a código que no escala.

La lógica rectora se deriva del GIL: **hilos/asyncio para trabajo limitado por I/O** (el GIL se libera durante las esperas, así que la concurrencia funciona) y **multiprocessing para trabajo limitado por CPU** (GILs separados para paralelismo real), con asyncio preferido cuando la concurrencia es muy alta.

Comprender las fortalezas de cada modelo, sus costos (sobrecarga de procesos/serialización, los requisitos de librerías de asyncio) y la decisión I/O-vs-CPU es esencial para escribir Python concurrente que de verdad ofrezca rendimiento.