Quando scegli threading, multiprocessing o asyncio?

Question

Accepted Answer

Python offre tre modelli di concorrenza, e la scelta corretta dipende principalmente dal fatto che il tuo lavoro sia **I/O-bound** o **CPU-bound** — una decisione fortemente influenzata dal GIL (che impedisce ai thread di eseguire il codice Python in parallelo).

## I tre modelli

```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 — per concorrenza 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
```

I thread funzionano bene per attività I/O-bound (rete, file, DB) perché il GIL viene rilasciato durante l'attesa — le attese multiple procedono in concorrenza. Non accelerano **mai** il lavoro CPU-bound.

## multiprocessing — per parallelismo 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
```

Per lavori pesanti da CPU (elaborazione immagini, matematica, elaborazione dati), i processi separati aggirano il GIL singolo e girano veramente in parallelo su più core. Il costo: overhead maggiore (avvio del processo) e i dati devono essere **serializzati** tra i processi (nessuna memoria condivisa per impostazione predefinita).

## asyncio — per I/O ad alta concorrenza

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

asyncio gestisce un numero enorme di operazioni I/O concorrenti su un singolo thread, più efficientemente dei thread (senza overhead per thread) — ideale per server e codice di rete ad alta concorrenza.

## La guida decisionale

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

## Perché è importante

Scegliere il modello di concorrenza giusto è una delle decisioni di prestazione più importanti di Python, e scegliere male (l'errore classico: thread per lavoro CPU-bound, che il GIL rende inutile) porta a codice che non si scala.

La logica guida scorre dal GIL: **thread/asyncio per I/O-bound** (GIL rilasciato durante l'attesa — la concorrenza funziona) e **multiprocessing per CPU-bound** (GIL separati per vero parallelismo), con asyncio preferito quando la concorrenza è molto alta.

Comprendere i punti di forza di ogni modello, i costi (overhead di processo/serializzazione, requisiti della libreria asyncio) e la decisione I/O-vs-CPU è essenziale per scrivere Python concorrente che effettivamente fornisce prestazioni.