Concurrency

Enables concurrent execution of multiple independent I/O-bound tasks while abstracting away manual thread creation, lifecycle management, and resource cleanup.

Web scraping: fetching many URLs in parallel without sequential network delays; Batch API calls: sending independent requests to multiple endpoints concurrently; File processing: reading or hashing many files simultaneously to overlap I/O wait times

concurrent.futures module, I/O-bound Python applications, web crawlers, batch API clients, data ingestion pipelines

with ThreadPoolExecutor(max_workers=num_workers) as executor: futures = [executor.submit(func, arg) for arg in iterable]

with ThreadPoolExecutor(...) as executor: futures = [executor.submit(..., ...) for ... in ...]

num_workers: int or None (default min(32, os.cpu_count() + 4)), func: callable to execute in thread, arg: argument passed to func, iterable: collection whose items become arguments

• concurrent.futures.as_completed
• concurrent.futures.wait
• future.result
• future.exception
• executor.map

• executor.map(func
• iterable): simpler API returning results in order but hides Future objects — less control over individual task handling
• ProcessPoolExecutor: for CPU-bound tasks needing true parallelism — tradeoff is inter-process serialization overhead
• asyncio.gather: cooperative concurrency without OS threads — tradeoff is requiring async/await throughout the call stack

1. Submitting tasks that share mutable state without locks → race conditions producing corrupted data; 2. Calling future.result() inside the list comprehension instead of after submission → blocks each task sequentially, defeating parallelism; 3. Using ThreadPoolExecutor for CPU-bound work → GIL serializes execution, no speedup gained; 4. Forgetting the 'with' statement and managing shutdown manually → risk of resource leak if exception occurs before shutdown; 5. Never checking futures for exceptions → silent failures where future.result() would raise but the error goes unobserved

ProcessPoolExecutor: bypasses GIL for CPU-bound work but incurs serialization overhead; asyncio.gather: cooperative single-thread concurrency requiring async functions; threading.Thread: manual thread creation with full control but no pooling or auto-cleanup

Coming from Java: may expect ThreadPoolExecutor to require an explicit fixed pool size — Python defaults to min(32, os.cpu_count() + 4) since 3.8; Coming from Go: may expect goroutine-level lightweight concurrency — Python threads are OS-level threads with significant per-thread memory overhead; Coming from JavaScript: may assume single-threaded event loop semantics — Python threads can truly execute in parallel during I/O waits

• ThreadPoolExecutor submit
• ProcessPoolExecutor submit
• executor.map
• as_completed
• Future.result
• Future.exception

1. Do NOT use for CPU-bound tasks due to the GIL — use ProcessPoolExecutor instead; 2. Each OS thread consumes ~8MB of stack memory by default, so max_workers implicitly caps memory usage; 3. The default max_workers changed in Python 3.8 from cpu_count * 5 to min(32, os.cpu_count() + 4), which can dramatically alter behavior on high-core machines

Reduces wall-clock time for I/O-bound workloads by overlapping wait times across threads, while guaranteeing thread pool cleanup even on exceptions — preventing resource leaks in long-running services.

Like a temp agency for short jobs — you hire a pool of workers, hand out task tickets (futures), and the agency guarantees cleanup when the shift ends.

The 'with' block calls executor.shutdown(wait=True) on exit, blocking until all submitted futures complete. To submit fire-and-forget tasks without waiting, manage the executor lifetime explicitly and call shutdown(wait=False).

asyncio.gather with async/await for higher-concurrency I/O without thread overhead; ProcessPoolExecutor for CPU-bound parallelism