När väljer du threading, multiprocessing eller asyncio?

Question

Accepted Answer

Python erbjuder tre concurrency-modeller, och valet beror framför allt på om ditt arbete är **I/O-bundet** eller **CPU-bundet** — ett beslut som i stor utsträckning formas av GIL (som förhindrar trådar från att köra Python-kod parallellt).

## De tre modellerna

```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 — för I/O-bunden concurrency

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

Trådar fungerar bra för I/O-bundna uppgifter (nätverk, filer, DB) eftersom GIL släpps under väntetiden — flera väntningar kan fortskrida samtidigt. De påskyndar **inte** CPU-bundet arbete.

## multiprocessing — för CPU-bunden parallelism

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

För CPU-tungt arbete (bildbehandling, matematik, datakrossning) kringgår separata processer den enskilda GIL och körs verkligen parallellt på flera kärnor. Kostnaden: högre overhead (processstart) och data måste **serialiseras** mellan processer (ingen delad minne som standard).

## asyncio — för högt samtidig I/O

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

asyncio hanterar ett enormt antal samtidiga I/O-operationer på en tråd, mer effektivt än trådar (ingen overhead per tråd) — idealisk för servrar och högsamtida nätverkskod.

## Beslutsguiden

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

## Varför det spelar roll

Att välja rätt concurrency-modell är ett av de mest konsekventiella prestandabesluten i Python, och att göra det fel (det klassiska misstaget: trådar för CPU-bundet arbete, vilket GIL gör värdelöst) leder till kod som inte skalas.

Den vägledande logiken följer från GIL: **trådar/asyncio för I/O-bundet** (GIL släpps under väntningar — concurrency fungerar) och **multiprocessing för CPU-bundet** (separata GIL:ar för verklig parallelism), med asyncio föredraget när samtidigheten är mycket hög.

Att förstå varje modells styrkor, kostnader (processoverhead/serialisering, asyncio:s bibliotekskrav) och I/O-vs-CPU-beslutet är väsentligt för att skriva samtidig Python som faktiskt levererar prestanda.