Wann wählen Sie threading, multiprocessing oder asyncio?

Question

Accepted Answer

Python bietet drei Concurrency-Modelle, und die richtige Wahl hängt hauptsächlich davon ab, ob Ihre Arbeit **I/O-gebunden** oder **CPU-gebunden** ist — eine Entscheidung, die stark durch die GIL geprägt wird (die Threads daran hindert, Python-Code parallel auszuführen).

## Die drei Modelle

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

Threads funktionieren gut für I/O-gebundene Aufgaben (Netzwerk, Dateien, DB), da die GIL während des Wartens freigegeben wird — mehrere Wartezeiten verlaufen gleichzeitig. Sie **beschleunigen nicht** CPU-gebundene Arbeit.

## multiprocessing — für CPU-gebundenen Parallelismus

```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-intensive Arbeit (Bildverarbeitung, Mathematik, Datenverarbeitung) umgehen separate Prozesse die einzelne GIL und laufen wirklich parallel auf mehreren Kernen. Die Kosten: höherer Overhead (Prozessstart) und Daten müssen zwischen Prozessen **serialisiert** werden (keine gemeinsamer Speicher standardmäßig).

## asyncio — für hochgradig nebenläufiges 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 verwaltet riesige Mengen gleichzeitiger I/O-Operationen in einem Thread, effizienter als Threads (kein Pro-Thread-Overhead) — ideal für Server und hochgradig nebenläufigen Netzwerkcode.

## Warum es wichtig ist

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

## Warum es wichtig ist

Die Wahl des richtigen Concurrency-Modells ist eine der folgenreichsten Python-Performance-Entscheidungen, und es falsch zu machen (der klassische Fehler: Threads für CPU-gebundene Arbeit, was die GIL unbrauchbar macht) führt zu Code, der nicht skaliert.

Die Leitlogik folgt aus der GIL: **Threads/asyncio für I/O-gebunden** (GIL wird während Wartezeiten freigegeben — Concurrency funktioniert) und **multiprocessing für CPU-gebunden** (separate GILs für echten Parallelismus), wobei asyncio bevorzugt wird, wenn Concurrency sehr hoch ist.

Das Verständnis der Stärken jedes Modells, der Kosten (Prozess-Overhead/Serialisierung, asyncios Bibliotheksanforderungen) und der I/O-versus-CPU-Entscheidung ist unverzichtbar für das Schreiben von nebenläufigem Python, das wirklich Performance liefert.