Threads vs Processes vs Async — The Decision Guide

The Three Models in One Breath

threading — many threads in one process, sharing memory. The GIL means they interleave, not parallelize, on CPU. Great for overlapping blocking I/O.
multiprocessing — many processes, each with its own interpreter and its own GIL. The only stdlib way to get true CPU parallelism in pure Python. Memory is isolated; data crosses via pickling/IPC.
asyncio — a single thread running an event loop that juggles thousands of tasks, switching only at await. Cheapest per-task, but needs async-aware libraries.

Key Insight: the choice is driven almost entirely by what your work is waiting on. Waiting on a CPU → processes. Waiting on the network/disk → threads or async. Everything else (memory, overhead, complexity) is a tie-breaker.

The Big Comparison

	threading	multiprocessing	asyncio
True CPU parallelism	❌ No (one GIL)	✅ Yes (a GIL each)	❌ No (one thread)
Memory	Shared by default	Isolated; pickle/IPC to share	Shared (same thread)
Data-passing cost	Free (shared objects)	Serialization overhead per call	Free (shared objects)
Per-unit cost	Heavy — OS thread, ~MBs of stack	Heaviest — full process + startup	Tiny — a coroutine object
Realistic scale	tens–low hundreds	~ number of CPU cores	tens of thousands
Switching	Preemptive (OS, anywhere)	Preemptive (OS, separate)	Cooperative (only at `await`)
Race conditions	Everywhere — need locks	Rare — no shared memory	Rare — switches are predictable
Best workload	Blocking I/O w/ sync libraries	CPU-bound number crunching	Massive concurrent I/O
Library requirement	Any (works w/ `requests`)	Args/results must be picklable	Needs async libs (`httpx`, `asyncpg`)
Complexity	Medium (locks, races)	Medium (serialization, spawn)	High (async all the way down)

The Decision, as a Flowchart

flowchart TD START["What is your work
mostly doing?"] --> CPU{"CPU-bound?
(crunching numbers
in pure Python)"} CPU -->|Yes| PROC["multiprocessing /
ProcessPoolExecutor
(or NumPy/C)"] CPU -->|"No — it's I/O-bound"| SCALE{"Thousands of tasks
AND able to rewrite
with async libraries?"} SCALE -->|Yes| ASYNC["asyncio"] SCALE -->|"No / stuck with
sync libraries"| THREADS["threading /
ThreadPoolExecutor"]

Read it top-down:

CPU-bound (image processing, ML, parsing, math) → processes. Threads can't help; the GIL blocks them.
A moderate pile of blocking I/O with libraries you can't or won't rewrite (requests, a sync DB driver) → threads.
Thousands of concurrent I/O tasks and you can commit to async libraries → async, which scales to that many for almost no memory.

Same Task, Three Ways

concurrent.futures is the great unifier: the same code becomes threads or processes by swapping one class. That makes it trivial to A/B a workload and see which model your problem actually wants.

from concurrent.futures import ThreadPoolExecutor, ProcessPoolExecutor

def work(item):
    ...   # do something with item
    return item

items = range(100)

# I/O-bound → threads (shared memory, cheap, works with sync libs)
with ThreadPoolExecutor(max_workers=16) as pool:
    results = list(pool.map(work, items))

# CPU-bound → processes (true parallelism; `work` & args must pickle)
with ProcessPoolExecutor() as pool:            # same API, one word changed
    results = list(pool.map(work, items))

And the async equivalent, which lives in its own world with await:

import asyncio, httpx   # note: an ASYNC http client, not `requests`

async def fetch(client, url):
    r = await client.get(url)          # yields control here — loop runs others
    return r.status_code

async def main(urls):
    async with httpx.AsyncClient() as client:
        return await asyncio.gather(*(fetch(client, u) for u in urls))

asyncio.run(main(["https://example.com"] * 1000))   # 1000 tasks, one thread

The catch with async: it's all-or-nothing. A single blocking call (a sync requests.get, a heavy CPU loop, time.sleep) freezes the entire event loop and every task on it. Threads tolerate blocking calls; async does not.

The Subtleties That Bite

Processes pay a serialization tax. Every argument in and result out is pickled. For tiny tasks, that overhead can dwarf the work — processes only win when each task is genuinely CPU-heavy.
Not everything is picklable. Lambdas, local functions, open sockets, and file handles can't cross a process boundary. Threads and async have no such restriction.
Startup method matters. On macOS and Windows the default is spawn — a fresh interpreter per process, so module-level code re-runs and you need the if __name__ == "__main__": guard.
Async needs an async ecosystem. Reaching for threads lets you keep every synchronous library you already use; async makes you replace them.

Hybrid is normal. Real systems mix them: an async web server that offloads a CPU-bound job to a ProcessPoolExecutor via loop.run_in_executor, or a thread pool that shells work out to worker processes. Pick the model per workload, not per program.

Key Takeaways

If your work is…	Use	Because
CPU-bound (pure Python)	processes	Only way past the GIL for real parallelism
A handful of blocking I/O tasks, sync libs	threads	Simple, shares memory, GIL frees on I/O
Thousands of I/O tasks you can rewrite	async	Scales huge for almost no memory
Threads vs processes, same code	`concurrent.futures`	Swap Thread↔Process pool executor, one line

Going deeper on async? There's a sibling guide covering the event loop, coroutines, and await in detail — see the async guides.