Потоки и процессы: что выбрать для вычислений, а что — для ожидания

На чём проверено: CPython 3.11.15, 3.12.3, 3.13.7 и 3.14.7 — обычные сборки с GIL, linux/x86_64, os.cpu_count() = 2; время мерили на 3.13.7 и 3.14.7. Документация сверена 14.10.2026. На эту дату вышел и Python 3.15 (9 октября 2026) — урок на нём не запускался; сборку без GIL урок тоже не измерял.

База: поток и процесс

Фрагмент — как выглядят два пула; fetch, urls, compute и chunks в нём не определены:

from concurrent.futures import ThreadPoolExecutor, ProcessPoolExecutor
 
with ThreadPoolExecutor(4) as pool:      # четыре потока в этом процессе
    results = list(pool.map(fetch, urls))
 
with ProcessPoolExecutor(4) as pool:     # четыре отдельных процесса
    results = list(pool.map(compute, chunks))

Полный файл squares.py — тот же пул процессов в виде, который можно скопировать в пустую папку и запустить командой python3 squares.py. Запускать именно файлом — не в интерактивном интерпретаторе (REPL) и не через python -c:

from concurrent.futures import ProcessPoolExecutor
from multiprocessing import get_context
 
 
def compute(n):
    return sum(i * i for i in range(n))
 
 
def main():
    chunks = [10, 100, 1000, 10000]
    with ProcessPoolExecutor(4, mp_context=get_context("spawn")) as pool:
        print(list(pool.map(compute, chunks)))
 
 
if __name__ == "__main__":
    main()

Три правила этого шаблона: функция, которую выполняют процессы, объявлена на уровне модуля; данные и пул создаются внутри main(); main() вызывается под if __name__ == "__main__":. Способ запуска spawn задан явно: так дочерний процесс стартует новым интерпретатором и заново импортирует этот файл — как на Windows и macOS, где spawn — способ по умолчанию. Импорт файла при этом пул не создаёт. Как этот шаблон отработал на четырёх версиях и что бывает без проверки __name__ — в механизме 3.

Ответ уровня Junior на «чем поток отличается от процесса»: потоки работают в одном процессе и делят память, процессы изолированы; в обычной сборке CPython из-за GIL потоки не ускоряют вычисления на Python, поэтому их берут для ввода-вывода, а для вычислений — процессы. Это верно, и за этим ответом идут уточнения: насколько потоки не ускоряют, что значит «делят память» на деле, что можно передать процессу и зачем блокировки, если есть GIL. Механизмы ниже отвечают на них прогоном.

Механизм 1: вычисления и ожидание

Четыре одинаковые задачи — последовательно, в пуле из четырёх потоков и в пуле из четырёх процессов. Вывод bench/parallel/cost.py, разделы 1 и 2:

1) вычисления: 4 задачи «сумма квадратов», секунды, медианы 5 кругов
   последовательно     0.502   ускорение  1.0
   4 потока            0.478   ускорение  1.1
   4 процесса          0.262   ускорение  1.9

2) ожидание: 4 задачи time.sleep(0.2), секунды, медианы 5 кругов
   последовательно     0.801   ускорение  1.0
   4 потока            0.201   ускорение  4.0
   4 процесса          0.212   ускорение  3.8

• Вычисления. Потоки почти не помогли: пока поток выполняет Python-код, он держит GIL, и остальные ждут своей очереди. Процессы считали параллельно — у каждого свой интерпретатор и свой GIL: ускорение 1,9 на машине, где os.cpu_count() — 2. На 3.14.7 в той же задаче потоки оказались даже медленнее последовательного запуска (0,8), процессы — 1,4. Эти отношения — одного прогона на одной машине: они зависят от версии, числа ядер и цены запуска процессов.
• Ожидание. Потоки ускорили вчетверо: time.sleep отпускает GIL, и четыре ожидания идут одновременно. Здесь sleep — модель ожидания: при вводе-выводе GIL тоже отпускается, но настоящую сеть или базу этот замер не проверяет. Процессы дали почти то же, но дороже — об этом механизм 3.

Правило «вычисления — в процессы» относится к Python-коду в сборке с GIL. Расширения на C могут отпускать GIL сами — в глоссарии Python: some extension modules, either standard or third-party, are designed so as to release the GIL when doing computationally intensive tasks such as compression or hashing (некоторые модули расширения, стандартные и сторонние, отпускают GIL на тяжёлых вычислениях — например, при сжатии или хешировании). Такие вычисления потоки ускорить могут; урок это не измерял.

Как именно GIL переключается между потоками и почему его держат, разобрано в статье о GIL.

Механизм 2: общая память и pickle

Вывод bench/parallel/basics.py, разделы 1 и 2, CPython 3.13.7:

1) память: поток против процесса
   после потока  shared = [9]
   после процесса shared = [9] | exitcode процесса: 0

2) что можно отдать в пул
   потоки,   функция модуля -> 25
   потоки,   lambda         -> 25
   процессы, функция модуля -> 25
   процессы, lambda         -> AttributeError: Can't get local object 'main.<locals>.<lambda>'

Функция дописывает квадрат числа в глобальный список. Поток дописал 9 — и основная программа это видит: память у потоков общая. Процесс дописал 16 в свою копию списка и завершился успешно, но в родителе по-прежнему [9]: у процесса своя память. Результат из процесса возвращают явно — через pool.submit(...).result(), очередь или канал.

Чтобы передать задачу и аргументы в другой процесс, их сериализуют модулем pickle. Функцию модуля он передаёт по имени, а локальную функцию и лямбду — нет: пулу потоков лямбда подошла, пулу процессов — нет. Ошибка зависит от версии: на 3.11–3.13 это AttributeError (текст на 3.11 и 3.12 — Can't pickle local object, на 3.13 — Can't get local object), а на 3.14 — уже другой тип, PicklingError: Can't pickle local object. Код, который ловил except AttributeError, на 3.14 эту ошибку пропустит.

Механизм 3: цена процессов и способ запуска

Вывод bench/parallel/cost.py, раздел 3, CPython 3.13.7:

3) старт пула и одна пустая задача, мс, медианы 5 кругов
   пул потоков        0.15
   пул процессов      9.09

Поток создаётся внутри процесса за доли миллисекунды. Процесс надо запустить, а каждую задачу и результат — сериализовать и передать. Поэтому процессы окупаются на больших вычислительных задачах и проигрывают на мелких.

Как запускается процесс, зависит от системы и версии. Вывод bench/parallel/basics.py, раздел 3:

3) среда
   sys.platform                    -> linux
   os.cpu_count()                  -> 2
   sys._is_gil_enabled()           -> True
   multiprocessing.get_start_method() -> fork
   python -X gil=0                 -> Fatal Python error: config_read_gil: Disabling the GIL is not supported by this build
   запуск процесса без if __name__ == '__main__' -> exitcode 0
   fork при живом потоке           -> DeprecationWarning: This process (pid=…) is multi-threaded, use of fork() may lead to deadlocks in the child.

Это вывод 3.13. fork копирует память родителя, но из его потоков — только тот, что вызвал fork; если в родителе работают другие потоки, дочерний процесс может зависнуть на блокировке, которую держал несуществующий в нём поток. С 3.12 Python предупреждает об этом — последняя строка; на 3.11 предупреждения нет.

На 3.14 под Linux в строке get_start_method() — forkserver: способ по умолчанию сменили на более безопасный для потоков. spawn запускает дочерний процесс новым интерпретатором, forkserver ответвляет его от заранее запущенного чистого процесса-сервера, и в обоих случаях главный модуль импортируется заново. Поэтому код, запускающий процессы, ставят под if __name__ == "__main__":. На 3.13 скрипт без этой проверки отработал (exitcode 0), а на 3.14 тот же скрипт упал: RuntimeError: An attempt has been made to start a new process before the current process has finished its bootstrapping phase.

Шаблон squares.py из базы проверен тем же скриптом: файл записывается во временную папку, запускается, импортируется и отдаётся интерпретатору через python -c; для сравнения — тот же пул без проверки __name__, на уровне модуля. Вывод bench/parallel/basics.py, раздел 5, CPython 3.13.7:

5) полный файл squares.py: пул процессов, способ запуска spawn
   python squares.py               -> [285, 328350, 332833500, 333283335000]
   import squares: дочерних процессов -> 0 | stderr пуст: True
   тот же код через python -c      -> AttributeError: Can't get attribute 'compute' on <module '__main__' (<class '_frozen_importlib.BuiltinImporter'>)>
   без if __name__, пул на уровне модуля -> RuntimeError: An attempt has been made to start a new process before the current process has finished its bootstrapping phase.

Файлом шаблон отработал на всех четырёх версиях, а import squares не создал ни одного процесса: пул появляется только при вызове main(). Через python -c у главного модуля нет файла: дочерний процесс не может его импортировать и не находит compute (текст ошибки зависит от версии, на 3.14 — AttributeError: module '__main__' has no attribute 'compute'). Это ограничение из документации: The __main__ module must be importable by worker subprocesses. This means that ProcessPoolExecutor will not work in the interactive interpreter (модуль __main__ должен быть доступен рабочим процессам для импорта. Поэтому ProcessPoolExecutor не работает в интерактивном интерпретаторе). А пул на уровне модуля со spawn упал с той же RuntimeError на всех четырёх версиях — не только на 3.14, где её вызвал forkserver по умолчанию.

Пул процессов на 3.14 в замере стартовал за 18,86 мс. Напрямую с 9,09 на 3.13 это не сравнить: при разных способах запуска пул запускает рабочие процессы по-разному.

Глубже: GIL не защищает ваш код от гонок

GIL в обычной сборке гарантирует, что два потока не выполняют байт-код одновременно, но не то, что ваша операция «прочитать, изменить, записать» выполнится без перерыва. Четыре потока по тысяче раз читают общий счётчик, уступают очередь вызовом time.sleep(0) и записывают значение плюс один. Вывод bench/parallel/basics.py, раздел 4:

4) гонка: 4 потока по 1000 увеличений общего счётчика
   без блокировки  итог == 4000: False
   с Lock          итог == 4000: True
   просто += 1     итог == 4000: True

Без блокировки два потока успевают прочитать одно и то же значение, и одно увеличение теряется. С threading.Lock чтение и запись выполняются одним куском, и итог точный. Последняя строка — обычный += 1 без уступки: в записанных прогонах итог совпал с 4000. Это наблюдение, а не гарантия: отсутствие потерь в одном запуске не доказывает, что их не будет в другом — в другой версии, сборке или под другой нагрузкой. Язык атомарность такой операции не обещает: FAQ Python относит D[x] = D[x] + 1 к неатомарным операциям и заканчивает советом When in doubt, use a mutex! (Сомневаетесь — берите мьютекс!). Правило: общее изменяемое состояние между потоками защищают блокировкой или не делят вовсе — передают данные через queue.Queue.

sys._is_gil_enabled() появилась в 3.13 — вместе с возможностью собрать CPython без GIL. В обычной сборке, на которой сделаны все замеры урока, она возвращает True, а попытка выключить GIL опцией -X gil=0 заканчивается ошибкой Disabling the GIL is not supported by this build — строка -X gil=0 раздела «среда» выше. На 3.11 и 3.12 этой опции ещё нет, и интерпретатор её просто не проверяет.

В 3.14 у сборки без GIL новый статус — в What's New 3.14: PEP 779: Free-threaded Python is officially supported (PEP 779: Python без GIL официально поддерживается). Это по-прежнему отдельная сборка: обычный интерпретатор 3.14.7 в прогоне — с GIL. В сборке без GIL потоки могут выполнять Python-код параллельно, поэтому правило «вычисления — в процессы» к ней напрямую не относится; урок её не измерял.

Ещё один вариант из 3.14 — concurrent.futures.InterpreterPoolExecutor: пул из нескольких изолированных интерпретаторов в одном процессе. По документации, Each interpreter has its own Global Interpreter Lock, which means code run with this executor has true multi-core parallelism (у каждого интерпретатора свой GIL, поэтому код в этом пуле выполняется по-настоящему параллельно на нескольких ядрах); изменяемые объекты интерпретаторы между собой не делят. Вывод bench/parallel/basics.py, раздел 6, CPython 3.14.7:

6) пул интерпретаторов в одном процессе
   concurrent.futures.InterpreterPoolExecutor -> есть, функция модуля -> 25

На 3.11–3.13 этого класса нет. Его время урок не мерил.

Как отвечать на собеседовании

Короткий ответ: потоки делят память процесса, процессы изолированы. В обычном CPython — сборке с GIL — потоки выполняют Python-код по очереди, поэтому для ожидания — сети, диска — берут потоки или asyncio, а для вычислений на Python — процессы; расширения на C могут отпускать GIL сами. Процессам задачи передают через pickle, запуск процессов дороже, а пул процессов создают в main() под if __name__ == "__main__":. GIL не избавляет от гонок: общее состояние защищают Lock.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

На «насколько потоки не ускоряют вычисления». «В моём замере на CPython 3.13.7, на машине с двумя ядрами, четыре задачи в четырёх потоках — 0,478 с против 0,502 последовательно, в процессах — 0,262. А четыре ожидания по 0,2 с в потоках заняли 0,201. На 3.14.7 отношения были другие, так что для своей задачи я бы мерил».

На «зачем Lock, если есть GIL». «GIL не делает атомарной мою операцию "прочитать — изменить — записать". Когда поток уступает ход между чтением и записью, четыре потока по тысяче увеличений не дали 4000, с Lock — дали. Обычный += в моих прогонах потерь не дал, но это не гарантия: в FAQ Python D[x] = D[x] + 1 — среди неатомарных операций».

На «почему лямбда не работает в ProcessPoolExecutor». «Задачу передают в другой процесс через pickle, а он передаёт функцию по имени, по которому её можно найти импортом. У лямбды и локальной функции такого имени нет. В пуле потоков лямбда работает».

На «что изменилось в последних версиях». «В 3.13 появилась сборка без GIL и sys._is_gil_enabled(); в 3.14 сборка без GIL получила статус официально поддерживаемой, но обычная сборка по-прежнему с GIL. В 3.14 же способ запуска процессов по умолчанию на Linux — forkserver вместо fork, и появился InterpreterPoolExecutor — пул интерпретаторов в одном процессе».

Дальше спросят

Частые заблуждения

История версий

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

t = threading.Thread(target=work, args=(3,))
t.start()
t.join()
p = multiprocessing.Process(target=work, args=(4,))
p.start()
p.join()
print(results)

[9]

[9, 16]

[]

[16]

Проверьте себя

Чем измерено

Числа и наблюдения этого урока получены этими скриптами. Каждый открывается прямо отсюда — вместе с записью прогона: на чём считали, что получилось и с каким разбросом.

• bench/parallel/basics.py
• bench/parallel/cost.py
• bench/parallel/practice.py