Kada pasirenkate threading, multiprocessing ar asyncio?

Question

Accepted Answer

Python siūlo tris concurrency modelius, o teisingas pasirinkimas pirmiausia priklauso nuo to, ar jūsų darbas yra **I/O-bound** ar **CPU-bound** — sprendimas, kurio forma dėl GIL (kuris neleidžia gijoms lygiagrečiai vykdyti Python kodo).

## Trys modeliai

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

Gijos gerai veikia I/O-bound užduotims (tinklas, failai, DB), nes GIL atlaisvinamą laukiant — keli laukai vyksta kartu. Jie **nepritaikyti** CPU-bound darbui pagreitinti.

## multiprocessing — CPU-bound paralelizmas

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

Dėl sunkaus CPU darbo (vaizdo apdorojimas, matematika, duomenų apdorojimas), atskiri procesai išvengia vieno GIL ir iš tikrųjų veikia lygiagrečiai keliose šerdyse. Kaina: didesnis pridėtinis kaštai (proceso paleidimas) ir duomenys turi būti **serijalizuoti** tarp procesų (nėra bendrintos atminties pagal numatytuosius nustatymus).

## asyncio — didelės 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 tvarko daugybę lygiagrečių I/O operacijų vienoje gijoje, efektyviau nei gijos (nėra per-gija papildomo naudojimo) — idealu serveriams ir didelės lygiagretumo tinklo kodui.

## Sprendimo vadovas

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

## Kodėl tai svarbu

Teisingo concurrency modelio pasirinkimas yra vienas iš svarbiausių Python aparatūros veiksmų, ir jei jį pasirinksite neteisingai (klasikavimas: gijos CPU-bound darbui, kuris GIL padarys nenaudingą) sukuria kodą, kuris neplečiasi.

Vadovaujantis GIL: **gijos/asyncio I/O-bound** (GIL atlaisvinamą laukiant — concurrency veikia) ir **multiprocessing CPU-bound** (atskiri GIL tikram paralelizmui), su asyncio patinkamiau pasirinkus didelę concurrency.

Supratimas apie kiekvieno modelio stiprybes, išlaidas (proceso papildomumas/serijalizacija, asyncio bibliotekos reikalavimus), ir I/O-vs-CPU sprendimą yra būtina norint parašyti concurrent Python, kuris iš tikrųjų suteikia veiktumą.