Hvornår vælger du threading, multiprocessing eller asyncio?

Question

Accepted Answer

Python tilbyder tre concurrency-modeller, og det rigtige valg afhænger primært af, om dit arbejde er **I/O-bound** eller **CPU-bound** — en beslutning, der i høj grad formes af GIL (som forhindrer tråde i at køre Python-kode parallelt).

## De tre modeller

```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 — til I/O-bound 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åde fungerer godt til I/O-bound opgaver (netværk, filer, DB), fordi GIL frigives under ventetid — flere ventetider forløber samtidigt. De **accelererer ikke** CPU-bound arbejde.

## multiprocessing — til CPU-bound parallelisme

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

Til CPU-tung arbejde (billedbehandling, matematik, databehandling) omgår separate processer den enkelte GIL og kører virkelig parallelt på flere kerner. Omkostningerne: højere overhead (processtart) og data skal **serialiseres** mellem processer (ingen delt hukommelse som standard).

## asyncio — til høj-concurrency 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 håndterer enorme mængder af samtidige I/O-operationer på én tråd, mere effektivt end tråde (ingen per-tråd overhead) — ideelt til servere og høj-concurrency netværkskode.

## Beslutningsvejledning

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

## Hvorfor det betyder noget

At vælge den rigtige concurrency-model er en af de mest afgørende Python-performancebeslutninger, og at få det forkert (den klassiske fejl: tråde til CPU-bound arbejde, som GIL gør ubrugelig) fører til kode, der ikke skalerer.

Den vejledende logik kommer fra GIL: **tråde/asyncio til I/O-bound** (GIL frigives under ventetider — concurrency fungerer) og **multiprocessing til CPU-bound** (separate GILs for ægte parallelisme), med asyncio som foretrukket, når concurrency er meget høj.

At forstå hver models styrker, omkostninger (processoverhead/serialisering, asyncios bibliotekskrav) og I/O-versus-CPU-beslutningen er væsentlig for at skrive concurrent Python, der faktisk leverer performance.