Кратко и по сути — сравнение семантик, сильных/слабых сторон и типичных применений.
1) Акторная модель (Erlang/Elixir)
- Идея: независимые лёгкие процессы (акторы) с собственной неразделяемой памятью, общение только сообщениями; отказоустойчивость (supervision).
- Плюсы:
- Отлично масштабируется по числу конкурирующих сущностей: BEAM держит сотни тысяч/миллионы процессов (типично $10^5$–$10^6$).
- Простая модель ума — нет гонок на общей памяти, легче reasoning и локализация ошибок ("let it crash").
- Встроенная поддержка распределённости и перезапуска при ошибках.
- Хорошо для долгоживущих stateful-сущностей (сессии, акторы-агенты).
- Минусы:
- Менее естественно для тяжёлых CPU-bound задач (нужно вынести в NIF/инструменты на C или в отдельные воркеры).
- Сообщения/серийность могут давать задержку при большом обмене данных.
- Где предпочтительна:
- Телефония, чаты, системы обмена сообщениями, IoT, распределённые контроллеры, потоковые обработчики событий, когда важна отказоустойчивость и много независимых stateful сущностей.
2) Потоки с общей памятью (Java — OS/VM threads, synchronized/locks, ForkJoinPool)
- Идея: несколько потоков выполнения, разделяют память; синхронизация через lock/atomic/ concurrent-collections.
- Плюсы:
- Подходит для CPU-bound задач и параллельных вычислений на нескольких ядрах; прямой доступ к многопоточности ОС/JVM.
- Высокая производительность в compute-intensive и низкоуровневых задачах (численные расчёты, обработка графики).
- Богатая экосистема: блокировки, пул потоков, concurrent структуры, JVM-профайлеры.
- Минусы:
- Сложность программирования: гонки, deadlock, тонкие ошибки синхронизации.
- Большой оверхед на поток (стек, контекст) — практический предел обычно $10^3$–$10^4$ потоков на процесс.
- Ошибка одного потока может коррумпировать общее состояние.
- Где предпочтительна:
- CPU-bound параллельные алгоритмы, realtime/latency-sensitive компоненты с жестким контролем потоков, внутренние сервисы с общей памятью и требованием низкой задержки, когда нужен прямой контроль над планированием.
3) Async/await с неблокирующим вводом (Node.js, Python asyncio)
- Идея: событийный цикл + корутины/фьючерсы; неблокирующий I/O, переключение при ожидании операций.
- Плюсы:
- Очень экономная модель для большого числа одновременных IO-bound задач (сеть, файлы): низкий память- и контекстный оверхед.
- Код с async/await чаще чище, чем колбэки; удобен для потоков управления асинхронностью.
- Хорош для высококонкурентных сетевых серверов (HTTP, прокси, WebSocket).
- Минусы:
- Однопоточный цикл: тяжёлые вычисления блокируют весь цикл — нужно выносить в пул воркеров/процессов.
- Требует неблокирующих библиотек; смешивание blocking-API чревато зависаниями.
- Модель не предотвращает гонки на общей памяти, если используется многопоточность/общее состояние.
- Где предпочтительна:
- Высококонкурентные IO-bound задачи: веб-серверы, прокси, краулеры, микросервисы, задачи с большим числом одновременных соединений и сравнительно лёгкой обработкой каждого запроса.
Сравнительная сводка (критерии выбора)
- Если домен — миллион лёгких независимых сущностей, требуется устойчивость и распределённость → акторы (Erlang/Elixir).
- Если задача — тяжелые вычисления, параллельные алгориты, низкоуровневый контроль над потоками и памятью → потоки/пул потоков (Java).
- Если задача — много одновременных сетевых/IO операций, небольшая CPU-работа на запрос → async/await (Node.js, Python asyncio).
Практические советы
- Для смешанных требований: комбинируйте — например, async/await + пул воркеров для CPU; в JVM можно использовать акторные библиотеки (Akka) поверх потоков.
- Следите за блокирующими вызовами: в async и акторах избегайте blocking-операций или выполняйте их в выделенных воркерах.
- Выбирайте модель исходя из характера нагрузки (IO-bound vs CPU-bound), требований к отказоустойчивости и числа конкурентных сущностей.