Потоки против процессов: выбор по нагрузке, гонки под GIL и дедлок fork+threads

Выбор по нагрузке: где какой пул действительно выигрывает

Когда тянетесь к concurrent.futures, первый вопрос — не «сколько воркеров?», а «что воркер делает, пока ждёт?». Ответ определяет, какой пул вас спасёт, а какой тихо сделает всё хуже.

concurrent.futures даёт обоим пулам один интерфейс, но физика разная. ThreadPoolExecutor делит память процесса: отправка задачи стоит микросекунды, передача воркеру DataFrame на 500 МБ не стоит ничего — это ссылка. Прошлый урок объяснил ограничение: потоки перекрываются только там, где GIL отпущен, поэтому пул потоков — для I/O-bound работы: HTTP-вызовы, запросы к БД, чтение из S3 — там, где воркеры живут заблокированными в ядре. Размер прощает ошибки (дефолт — min(32, cpu_count + 4)); для I/O можно держать десятки потоков на ядро. ProcessPoolExecutor покупает настоящий CPU-параллелизм, платя ренту сериализацией: каждый аргумент и каждый результат пересекают границу процесса через pickle. Этот налог — самая частая причина, по которой «распараллеленный» код становится медленнее. Честные числа: pickle ~100 МБ обычных объектов Python занимает порядка секунды в каждую сторону, так что отправка большого DataFrame воркеру с 200 мс вычислений — чистый проигрыш в секунды. Рабочий паттерн: посылать маленькие описания работы (путь к файлу, диапазон ID), позволять воркеру самому грузить данные, возвращать маленькие результаты. И батчевать — executor.map(fn, items, chunksize=100) амортизирует пер-задачные IPC-накладные, которые иначе доминируют, когда каждый элемент стоит микросекунды.

from concurrent.futures import ThreadPoolExecutor, ProcessPoolExecutor
import multiprocessing as mp

# I/O-bound: потоки. 32 воркера, большую часть времени заблокированных в ядре.
with ThreadPoolExecutor(max_workers=32) as pool:
    pages = list(pool.map(fetch_url, urls))          # реально перекрываются

# CPU-bound: процессы. Передавай пути, а не данные — аргументы идут через pickle.
ctx = mp.get_context("spawn")                        # explicit start method
with ProcessPoolExecutor(max_workers=8, mp_context=ctx) as pool:
    results = list(pool.map(render_pdf, paths, chunksize=4))

GIL не делает ваш код потокобезопасным

Опасная полуправда: «потоки в Python не могут гнаться из-за GIL». GIL гарантирует один байткод за раз — но count += 1 это три байткода (загрузить, сложить, сохранить), и 5-мс переключение может приземлиться между любыми двумя. Два потока читают одно значение, оба прибавляют единицу, оба записывают: инкремент потерян. В быстром тесте два потока с миллионом незащищённых += каждый на 3.9 и раньше заметно недобирают до 2 000 000 — современный CPython (3.10+) переключается только между целыми строками байткода, и именно этот демо-пример обычно проходит, что только хуже: гонка осталась, просто стала реже и невоспроизводимой в тестах. Главный убийца — check-then-act: if key not in cache: cache[key] = expensive() — два потока проходят проверку до того, как любой из них запишет, и дорогой вызов исполняется дважды (или хуже — наружу торчит полуинициализированное состояние). Отдельные операции dict и list в CPython атомарны, но любая последовательность операций, которая должна быть согласованной, требует threading.Lock. Дисциплина та же, что в любом языке: найдите инварианты, охватывающие больше одной операции, и охраняйте их; GIL меняет вероятность переплетения, но никогда — его возможность.

import threading

cache, lock = {}, threading.Lock()

def get_config(key):
    with lock:                      # guard the whole check-then-act
        if key not in cache:
            cache[key] = load_from_disk(key)   # runs exactly once per key
        return cache[key]

fork против spawn: как рождается дочерний процесс

Если вы когда-нибудь катили сервис, который работал на маке и молча дедлочился на Linux в проде, — метод запуска первое место, куда стоит смотреть. Разобраться в разнице занимает пять минут; отлаживать альтернативу без этого понимания команда из вступления потратила три дня.

multiprocessing создаёт воркеров через метод запуска, и этот выбор — вопрос корректности. fork (исторический дефолт Linux) клонирует родительский процесс в момент вызова: мгновенно, без реимпорта, все загруженные данные доступны copy-on-write. Его фатальное взаимодействие — баг из вступления: fork() копирует всё адресное пространство, включая каждый удерживаемый замок, но в ребёнка переживает только вызывающий поток. Любой замок, который в момент fork держал другой поток — замок logging, замок аллокатора внутри C-библиотеки, мьютекс пула соединений, — заперт в ребёнке навсегда, и первое касание дедлочится. Правило: fork и потоки несовместимы, а потоки за вашей спиной заводит почти всё (хендлеры logging, grpc, boto3, OpenBLAS). CPython 3.12 начал выдавать DeprecationWarning при fork в многопоточном процессе, и дефолтный метод уходит от голого fork (macOS перешёл на spawn ещё в 3.8; Linux переходит на forkserver в 3.14). spawn запускает свежий интерпретатор и импортирует ваш модуль — медленно (сотни мс на воркера), требует, чтобы всё отправляемое было picklable, а точка входа была под if __name__ == "__main__": (иначе каждый ребёнок заново исполняет создание пула: процессная бомба), — зато иммунен к дедлокам унаследованных замков. forkserver — средний путь: чистый однопоточный серверный процесс форкает воркеров по запросу. Продакшен-инструкция: задавайте метод запуска явно — mp.get_context("spawn") — и никогда не полагайтесь на платформенный дефолт, потому что именно он и поменялся между ноутбуком и контейнером.

Общее состояние между процессами: лучше никак

Процессы по умолчанию не делят ничего, а лазейки дороги или остры. multiprocessing.Queue и результаты пулов перемещают данные через pickle. Объекты Manager() проксируют каждое обращение через серверный процесс — удобно и примерно в 1000 раз медленнее локального dict. multiprocessing.shared_memory и Value/Array дают настоящие общие буферы, но возвращают все гонки из раздела про потоки — уже без случайной защиты GIL, — так что им нужен multiprocessing.Lock. Архитектура, переживающая продакшен: воркеры — функции без состояния над своими аргументами; общее состояние живёт в том, что для него построено (Redis, база), или сводится к финальному merge в родителе. Если на горячем пути рука тянется к Manager().dict() — дизайн сообщает, что хотел потоков. Или другой декомпозиции.