Коротко — сначала о терминах, затем о сравнении и практических предпочтениях.
1) Концепции
- Конкурентность — способность системы справляться с несколькими задачами, чередуя выполнение так, что они логически перекрываются во времени (не обязательно одновременно).
- Параллелизм — одновременное выполнение задач на двух и более физических единицах (ядрах/процессорах).
Пример различия: можно иметь конкурентную систему на одном ядре (переключение контекста), а для параллелизма нужны $N\ge 2$ ядер.
2) Многопоточность (threads)
- Механизм: несколько потоков в одном процессе, разделяют память (общие данные, куча). Планирование обычно предemptive ОС (или user-level).
- Плюсы: низкие накладные расходы на создание/контекстную смену, быстрая передача данных через общую память. Хороша для задач с общей памятью и частым взаимодействием.
- Минусы: гонки, необходимость синхронизации (мьютексы, условные переменные), риск дедлоков, менее устойчива к отказам (ошибка потока может ухудшить весь процесс). В некоторых реализациях (как CPython) потоки не дают параллелизма из‑за GIL.
- Подходит: многозадачные блокирующие операции на языке без GIL (Java, C++), приложения с плотным взаимодействием между задачами.
3) Многопроцессность (processes)
- Механизм: несколько процессов, каждый с собственной памятью; обмен через IPC (сокеты, пайпы, shared memory).
- Плюсы: отказоустойчивость и изоляция, простой параллелизм на $N$ ядрах (нет GIL), масштабируемость, безопаснее с точки зрения состояния.
- Минусы: выше накладные расходы на создание и IPC, сложнее шарить состояние.
- Подходит: CPU‑bound вычисления (на $N$ ядрах), тяжёлые вычислительные задачи, контейнеризованные/микросервисные архитектуры.
4) Асинхронный ввод‑вывод (async I/O, event loop, async/await)
- Механизм: один (или несколько) потоков с неблокирующими операциями и циклом событий; переключение задач кооперативное при ожидании I/O. Использует epoll/kqueue/io_uring и т.п.
- Плюсы: очень эффективно при большом числе одновременных I/O‑операций: низкая память на соединение, малые накладные расходы на переключение, высокая пропускная способность для I/O‑bound задач.
- Минусы: код должен быть неблокирующим и "функционально" построен (инверсии управления), сложно использовать для тяжёлых CPU‑операций в том же потоке; библиотекам нужно поддерживать неблокир. Один event‑loop обычно не использует более одного ядра (можно масштабировать с помощью нескольких процессов/воркеров).
- Подходит: сетевые серверы, прокси, обработка большого числа соединений ($\sim 10^3$-$10^6$), GUI (для неблокирующего UI).
5) Практические рекомендации / примеры
- CPU‑bound (параллельные численные расчёты, ML‑обучение): предпочтительна многопроцессность или специализированный многопоточный код на C/C++/Fortran без GIL; можно распределять по $N$ ядрам. Пример: рендеринг кадров, матричные умножения.
- I/O‑bound с большим числом соединений (веб‑сервер высокой конкуренции, чат, прокси): async I/O выгоднее из‑за масштабируемости (Node.js, asyncio, Nginx). Пример: веб‑сервер, обслуживающий $10^4$ коротких соединений.
- Задачи с короткими блокирующими операциями, но небольшим числом потоков (потребитель‑производитель, параллельные обработчики запросов на Java): многопоточность удобна и проста.
- Гибридные сценарии: async I/O + пул воркеров (процессы или потоки) — асинхронный сервер направляет CPU‑тяжёлые задачи в пул. Пример: web‑API, где запросы обычно I/O‑bound, но иногда требуют тяжёлой обработки.
- Надёжность/изоляция (пенализация ошибок): процессы предпочтительнее (микросервисы, отдельные воркеры).
- Ограничения языков: в Python для CPU‑bound чаще используют multiprocessing из‑за GIL; в Java/C# потоки часто дают реальный параллелизм.
6) Теоретическое ограничение параллелизма
- Скорость параллельного ускорения ограничена долей параллелизуемого кода $P$ по закону Эмбола/Амдала: $S=\frac{1}{(1-P)+P/N}$, где $N$ — число процессоров.
Короткая шпаргалка выбора:
- CPU‑bound → процессы / нативные потоки без GIL.
- Массовый I/O → async I/O (event loop).
- Среднее число конкурирующих задач + простота → потоки.
- Надёжность и изоляция → процессы.
Если нужно — могу привести конкретные примеры кода или схемы архитектуры для каждого подхода.