Concurrency & Async

Tvůj backend skoro nikdy nedělá jen jednu věc — obsluhuje spoustu uživatelů naráz. A jakmile běží víc věcí „současně" a sahají na stejná data, začnou se dít zvláštní věci: výsledky, které nesedí, zaseknutí, chyby, co se objeví jen pod zátěží a v testech nikdy. Tahle kapitola tě naučí, proč se to děje a jak tomu předejít. Neboj, půjdeme pomalu.

Pár pojmů na úvod

• Souběžně (concurrently) = víc úloh „probíhá" v překrývajícím se čase. Server vyřizuje request od Aleny, Bórise i Cyrila zhruba ve stejnou chvíli.
• Vlákno (thread) = „pracovní linka" uvnitř programu, která vykonává kód. Program může mít jedno vlákno, nebo víc běžících paralelně.
• Proces = celá běžící instance programu (má vlastní paměť). Víc procesů = víc nezávislých kopií.
• Sdílený stav = data, ke kterým má přístup víc úloh naráz (společná proměnná, čítač, cache). Tady vzniká většina problémů.

Concurrency vs Parallelism (nepleť si)

• Concurrency (souběžnost) = zvládat víc úloh najednou tím, že mezi nimi rychle přepínáš. Zvládneš i na jednom procesoru.
• Parallelism (paralelismus) = vykonávat víc úloh opravdu naráz na víc procesorech zároveň.

Analogie: jeden kuchař, který žongluje třemi jídly a střídá je, = concurrency. Tři kuchaři, každý u svého jídla, = parallelism.

I/O-bound vs CPU-bound — podle tohohle volíš strategii

Než cokoli zrychluješ, zjisti, čím tvůj kód tráví čas:

• I/O-bound = většinu času čekáš na něco vnějšího (odpověď z databáze, ze sítě, z disku). Procesor zatím nedělá nic. Řešení: async — místo čekání mezitím obsluž jinou úlohu. Sem patří většina běžného backendu. (I/O = input/output, tedy vstup/výstup — komunikace s okolím.)
• CPU-bound = většinu času počítáš (šifrování, zpracování obrázků, komprese). Tady async nepomůže — práci musíš rozdělit na víc procesorů (parallelism).

Častý omyl: hodit async na výpočetně náročnou práci. Nezrychlí to nic — jen zablokuješ to jediné vlákno (viz event loop níže).

Dva způsoby, jak zvládat souběžnost

Vlákna (threads) — používá Java, Go, Python…

Operační systém spouští víc vláken, která můžou běžet paralelně na víc jádrech. Sdílejí ale paměť, takže když dvě vlákna sahají na stejná data, musíš je synchronizovat (viz zámky níže). Vlákno něco stojí (paměť, přepínání). Go to řeší levnými „mini-vlákny" zvanými goroutines.

⚠️ Python má výjimku — GIL (Global Interpreter Lock): standardní Python (CPython) pouští v jednu chvíli jen jedno vlákno s Python kódem, takže vlákna ti CPU-bound práci nezparalelizují (na to potřebuješ víc procesů). Na čekání (I/O) vlákna v Pythonu pomůžou, na počítání ne. (V Javě a Go vlákna paralelně počítají normálně. Pozn. k 2026: Python 3.13+ má experimentální free-threaded build bez GILu — tohle omezení se začíná měnit, ale defaultně pořád platí.)

Event loop (asynchronní model) — používá Node.js, Python asyncio

Tady běží kód na jednom vlákně, ale chytře. Když narazí na čekání (třeba dotaz do databáze), neztuhne — poznamená si „až přijde odpověď, vrať se sem" a mezitím obslouží další úlohu. Je to jako jeden velmi rychlý číšník, který místo postávání u kuchyně bere zatím další objednávky a vrací se pro hotové jídlo, až je nachystané. Tímhle zvládne tisíce souběžných spojení levně.

⚠️ V event loopu nikdy „neztuhni" dlouhým výpočtem (těžká matematika, nekonečný while). Máš jen jedno vlákno — když ho zaměstnáš na 3 vteřiny, všichni ostatní uživatelé ty 3 vteřiny čekají. Náročné výpočty dej do samostatného vlákna nebo procesu.

async/await, na které narazíš v kódu, je jen čitelnější zápis téhle asynchronní práce.

⚠️ Event loop ≠ paralelismus. Jedna instance Node jede na jednom jádře — async ti pomůže zvládat spoustu čekání naráz, ale nevyužije 8 jader CPU. Na to potřebuješ víc procesů (cluster / víc instancí za load balancerem), nebo na CPU práci worker threads. Async je o I/O, ne o jádrech.

Když dvě souběžné operace čtou a zapisují stejná data a výsledek závisí na tom, kdo to stihl dřív, vzniká race condition („závod"). Příklad se sdíleným čítačem:

Oba přečetli 10 dřív, než kterýkoli stihl zapsat, takže oba zapsali 11 a jedno zvýšení se „ztratilo". Je to stejný problém jako u databáze (Databáze), jen v paměti aplikace. Objevuje se přes sdílený stav: globální proměnná, cache, čítač.

Jak se bránit:

• Atomické operace — operace, kterou nelze přerušit v půlce (databázové/Redis INCR zvýší čítač v jednom kroku, takže se dva nemůžou „protnout").
• Zámky (locks) — kus kódu, kde se sahá na sdílená data, smí provádět vždy jen jeden naráz.
• Nesdílet měnitelný stav — nejlepší řešení. Drž stav venku (databáze, Redis) a měň ho atomicky, ne ve sdílené proměnné v paměti.

Zámky a další synchronizační nástroje

• Mutex / Lock — pustí do „chráněné zóny" jen jednoho naráz.
• Semaphore — pustí nejvýš N naráz (např. „max 5 souběžných volání cizího API").
• Read-Write lock — buď víc čtenářů zároveň, NEBO jeden zapisovatel.

Každý zámek znamená čekání a riziko deadlocku (viz níže). Proto platí: čím míň sdíleného stavu, tím míň zámků, tím míň problémů.

Deadlock — vzájemné zaseknutí

Deadlock nastane, když dvě úlohy čekají každá na to, co drží ta druhá — a nikdo se nehne navždy:

Úloha 1 drží zámek A, chce B
Úloha 2 drží zámek B, chce A   →  nikdo se nepohne

Existuje teorie (Coffmanovy podmínky), ale pro tebe stačí praktická obrana: zabírej zámky vždy ve stejném pořadí (pak nemůže vzniknout to vzájemné čekání) a dávej jim timeout, ať se případně samy uvolní místo věčného zaseknutí.

Příbuzný jev: starvation (vyhladovění) — úloha se nikdy nedostane ke zdroji, protože ji pořád předbíhají ostatní.

Pooly — nevyráběj nové vlákno/spojení na každou úlohu

Vytvořit vlákno nebo spojení něco stojí, a kdybys je dělal donekonečna, vyčerpáš zdroje a spadneš. Řešení je pool: pevná sada „pracantů", kteří se recyklují, a přebytek úloh počká ve frontě. Je to stejný princip jako connection pooling u databáze. Navíc tě omezený pool chrání před přetížením (jednomu úkolu nedovolí spotřebovat všechno).

Backpressure — tlak zpět

Když něco vyrábí práci rychleji, než ji stíháš zpracovávat, musí existovat způsob, jak říct „zpomal" (nebo úkoly odmítat, nebo mít frontu s limitem). Tomu se říká backpressure. Bez něj fronta nebo paměť roste, až dojde paměť a program spadne (OOM = out of memory). Souvisí s asynchronními frontami.

Failure modes — jak to v praxi praská

• Race condition → občas špatný výsledek pod zátěží, v testech se nikdy neprojeví (proto se těmhle bugům říká „heisenbug" — zmizí, jakmile se na ně díváš).
• Deadlock → zaseknuté requesty, vyčerpaná vlákna.
• Zablokovaný event loop → jeden těžký výpočet položí celou instanci.
• Vyčerpaný pool → když se použité vlákno/spojení „neuklidí", dojdou a nové requesty čekají věčně.
• Neomezená souběžnost → tisíce paralelních volání naráz zahltí cizí službu (chybí semaphore/pool).

🛠️ Cvičení

1. Zablokuj event loop. V Node.js napiš endpoint s těžkým synchronním while cyklem na pár vteřin. Během něj pošli druhý request a sleduj, že stojí celá instance. Pak výpočet přesuň do samostatného vlákna.
2. Race na čítači. Spusť 1000× paralelně „zvyš čítač o 1" nad sdílenou proměnnou bez atomicity a sleduj, že výsledek není 1000. Pak použij atomický INCR a porovnej.
3. Vyrob deadlock. Dvě úlohy, dva zámky, opačné pořadí zabírání → zaseknutí. Pak to oprav sjednocením pořadí zámků.
4. Omez souběžnost. Máš 500 URL ke stažení. Napiš to tak, aby běželo nejvýš 10 naráz (semaphore / pool), ne všech 500 najednou (zahltil bys cíl i sebe).
5. I/O vs CPU. U každé úlohy rozhodni, jestli pomůže async, nebo víc procesů: zavolat 3 API, zmenšit 1000 obrázků, přečíst velký soubor, vypočítat hashe hesel.

🧠 Otázky & odpovědi