Асинхронность Многопоточность Многопроцессорность #

1. Что такое асинхронность и как она устроена? #

Асинхронный код - это подход к написанию кода, который позволяет выполнять несколько задач одновременно в рамках одного потока. Это достигается за счет использования асинхронных функций и корутин. В отличие от синхронного кода, который выполняет каждую задачу последовательно, асинхронный код может запустить несколько задач конкурентно.

Ключевой механизм: когда одна задача выполняет операцию ввода-вывода (например, ожидает ответ от сети, чтение файла или запрос к базе данных) она освобождает управление, позволяя работать другой задаче. Таким образом, сокращается время, которое поток мог бы проводить в ожидании результатов операции ввода-вывода.

Основное отличие от многопоточности: хотя в один момент времени выполняется только одна задача (как и при работе с GIL), переключение между задачами происходит не произвольно по решению операционной системы, а предсказуемо — только в местах, помеченных await, то есть в точках ожидания результатов IO операций, специально отмечаемых программистом.

Это позволяет одному потоку обрабатывать тысячи одновременных соединений, делая программу чрезвычайно эффективной для I/O-bound операций (задач, связанных с операциями ввода-вывода).

Механизм возврата к выполнению задачи:

Задача встречает await и приостанавливается, сообщая event loop: “Я жду I/O-операцию, займись другими задачами” Event loop продолжает выполнять другие готовые задачи Когда I/O-операция завершается, система оповещает event loop, что результат готов Event loop помещает приостановленную задачу обратно в очередь готовых к выполнению Когда доходит очередь, задача возобновляется именно с того места, где остановилась, получая результат операции Ключевые особенности:

Запомнилось состояние стека и локальные переменные Возобновление происходит точно после await Не нужно заново запускать функцию с начала Аналогия: Как закладка в книге — закрыли на интересном месте, потом открыли и продолжили читать с того же момента.

Примером использования асинхронного кода является библиотека asyncio в Python. Например, вот простой пример кода, который использует asyncio для запуска нескольких задач одновременно и ожидания их завершения: import asyncio

async def hello(): await asyncio.sleep(1) print(“Hello”)

async def world(): await asyncio.sleep(2) print(“World”)

async def main(): await asyncio.gather(hello(), world())

if name == ‘main’: asyncio.run(main()) В этом примере мы определяем 3 асинхронные функции: hello(), world() и main(). Функции hello() и world() печатают соответствующие сообщения и ждут 1 и 2 секунды соответственно. Функция main() запускает эти две функции одновременно с помощью asyncio.gather() и ждет, пока они завершат свою работу. Затем мы запускаем функцию main() с помощью asyncio.run(). В результате мы получим сообщения “Hello” и “World”, каждое через 1 и 2 секунды соответственно, при этом результаты двух задач были получены почти одновременно.

Основные преимущества асинхронного программирования:

Улучшенная отзывчивость: Позволяет обрабатывать множество задач конкурентно без блокировки основного потока исполнения (для I/O-bound операций). Параллелизм — одновременное выполнение нескольких задач (на разных ядрах/процессорах). Конкурентность — управление несколькими задачами, которые выполняются в перекрывающиеся промежутки времени, но не обязательно одновременно (Asyncio). Эффективное использование ресурсов: Позволяет эффективно использовать процессорное время, так как задачи выполняются в моменты ожидания операций ввода/вывода или других блокирующих операций. Простота масштабирования: Позволяет легко создавать множество параллельных (конкурентных) задач без создания большого количества потоков или процессов.

2. Что такое конкурентность и параллельность? #

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

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

Конкурентность:
один исполнитель переключается между задачами

Задача A:  ███ wait ███ wait ███
Задача B:      ███ wait ███ wait ███
CPU:       A → B → A → B → A

Параллельность:
несколько исполнителей работают реально одновременно

CPU 1:     █████ Задача A █████
CPU 2:     █████ Задача B █████

Главное различие #

То есть:

параллельность ⊂ конкурентность

Любая параллельность — это конкурентность, но не всякая конкурентность — параллельность.

Пример из жизни #

Конкурентность:

Ты готовишь суп и жаришь мясо один.
Поставил суп вариться → пока ждёшь, жаришь мясо → вернулся к супу.

Ты один, но продвигаешь две задачи.

Параллельность:

Один человек готовит суп.
Другой человек жарит мясо.
Оба работают одновременно.

В Python #

В Python конкурентность часто делают через:

asyncio
threading
concurrent.futures.ThreadPoolExecutor

asyncio в официальной документации Python описан как библиотека для написания конкурентного кода через async/await; он особенно полезен, когда программа часто ждёт I/O: сеть, базу данных, файлы, HTTP-запросы. ( Python documentation)

Пример конкурентности через asyncio:

import asyncio


async def download_file(name: str):
    print(f"start {name}")
    await asyncio.sleep(2)  # имитация ожидания сети
    print(f"finish {name}")


async def main():
    await asyncio.gather(
        download_file("file1"),
        download_file("file2"),
        download_file("file3"),
    )


asyncio.run(main())

Здесь задачи не обязательно выполняются физически одновременно. Они переключаются в моменты ожидания.

Параллельность в Python #

Для настоящей параллельности в Python часто используют процессы:

from concurrent.futures import ProcessPoolExecutor


def heavy_calculation(n: int):
    return sum(i * i for i in range(n))


if __name__ == "__main__":
    with ProcessPoolExecutor() as executor:
        results = executor.map(heavy_calculation, [10_000_000, 10_000_000, 10_000_000])

    print(list(results))

concurrent.futures поддерживает запуск задач через потоки, процессы и интерпретаторы; ProcessPoolExecutor использует отдельные процессы, поэтому CPU-bound задачи могут реально выполняться параллельно на разных ядрах.

Важный момент про GIL #

В обычном CPython с включённым GIL несколько потоков не выполняют Python-байткод одновременно на разных ядрах. GIL ограничивает одновременное выполнение Python-кода потоками, хотя потоки всё равно полезны для I/O-задач.

Поэтому:

I/O-bound задачи:
asyncio / threads часто подходят

CPU-bound задачи:
processes / multiprocessing / ProcessPoolExecutor чаще подходят

CPU-bound и I/O-bound #

CPU-bound — задача грузит процессор:

математика
сжатие данных
обработка изображений
парсинг большого объёма данных

Для них нужна параллельность.

I/O-bound — задача ждёт внешние ресурсы:

запрос в БД
HTTP-запрос
чтение файла
ответ от API

Для них часто достаточно конкурентности.

Итог #

Конкурентность = уметь работать с несколькими задачами в один период времени.

Параллельность = реально выполнять несколько задач одновременно.

В Python:

asyncio       → конкурентность
threading     → конкурентность, хорошо для I/O
multiprocessing / ProcessPoolExecutor → параллельность

3. Чем отличаются асинхронность, многопроцессорность и многопоточность? | Виды конкурентности #

Асинхронность, многопоточность и многопроцессность — это разные способы организовать конкурентность, то есть выполнение нескольких задач в один период времени.

Конкурентность
├── Асинхронность
├── Многопоточность
└── Многопроцессность

Важно: правильнее говорить многопроцессность, если речь про multiprocessing.
Многопроцессорность — это скорее про железо: несколько процессоров/ядер.

1. Асинхронность #

Асинхронность — это когда один поток выполнения переключается между задачами в моменты ожидания.

Например:

Задача A делает HTTP-запрос и ждёт ответ
↓
Пока A ждёт, программа выполняет задачу B
↓
Потом возвращается к A

В Python это обычно:

async def func():
    await something()

asyncio в официальной документации Python описан как библиотека для написания конкурентного кода через async/await; он часто используется в сетевых серверах, клиентах, библиотеках для БД и других I/O-задачах.

Пример:

import asyncio


async def request(name: str):
    print(f"start {name}")
    await asyncio.sleep(2)  # имитация ожидания сети
    print(f"finish {name}")


async def main():
    await asyncio.gather(
        request("A"),
        request("B"),
        request("C"),
    )


asyncio.run(main())

Здесь задачи не выполняют Python-код одновременно. Они кооперативно уступают управление через await.

Асинхронность:
один поток
один event loop
много задач
переключение в await

Хорошо подходит для:

HTTP-запросов
запросов в БД
WebSocket
сетевых сервисов
очередей
ожидания файлов/сокетов

Плохо подходит для тяжёлых CPU-вычислений, потому что одна тяжёлая функция может заблокировать event loop.

2. Многопоточность #

Многопоточность — это когда внутри одного процесса создаётся несколько потоков.

Один процесс
├── Thread 1
├── Thread 2
└── Thread 3

Потоки имеют общую память процесса:

import threading


def worker():
    print("work")


t1 = threading.Thread(target=worker)
t2 = threading.Thread(target=worker)

t1.start()
t2.start()

t1.join()
t2.join()

В Python модуль threading используется для потокового выполнения, но в обычном CPython с GIL только один поток за раз выполняет Python-байткод, поэтому прирост на CPU-bound задачах ограничен.

То есть потоки полезны, когда задача часто ждёт:

поток 1 ждёт ответ от сети
поток 2 в это время может работать
поток 3 ждёт файл

Но для тяжёлой математики:

Thread 1 считает
Thread 2 считает
Thread 3 считает

в обычном CPython это часто не даёт настоящего ускорения из-за GIL.

Многопоточность:
один процесс
несколько потоков
общая память
переключение потоков делает ОС
в CPython GIL мешает CPU-параллелизму

Хорошо подходит для:

блокирующего I/O
работы с библиотеками без async API
фоновых задач
простого параллельного ожидания

Плохо подходит для:

тяжёлых CPU-вычислений в чистом Python

3. Многопроцессность #

Многопроцессность — это когда создаётся несколько отдельных процессов.

Process 1
Process 2
Process 3

У каждого процесса своя память и свой интерпретатор Python.

from multiprocessing import Process


def worker():
    print("work")


if __name__ == "__main__":
    p1 = Process(target=worker)
    p2 = Process(target=worker)

    p1.start()
    p2.start()

    p1.join()
    p2.join()

multiprocessing использует подпроцессы вместо потоков и тем самым обходит GIL, позволяя задействовать несколько процессоров/ядер.

Поэтому для CPU-bound задач обычно лучше:

from concurrent.futures import ProcessPoolExecutor


def heavy(n: int) -> int:
    return sum(i * i for i in range(n))


if __name__ == "__main__":
    with ProcessPoolExecutor() as executor:
        results = executor.map(heavy, [10_000_000, 10_000_000, 10_000_000])

    print(list(results))

concurrent.futures даёт единый интерфейс для асинхронного запуска задач через потоки, процессы или интерпретаторы: ThreadPoolExecutor, ProcessPoolExecutor, InterpreterPoolExecutor.

Многопроцессность:
несколько процессов
память изолирована
GIL не мешает между процессами
есть реальный CPU-параллелизм
обмен данными дороже

Хорошо подходит для:

математики
обработки изображений
сжатия данных
парсинга больших объёмов
ML/аналитики
CPU-bound задач

Минусы:

процессы тяжелее потоков
данные нужно передавать между процессами
сложнее общий state
больше расход памяти

Главное отличие #

CPU-bound и I/O-bound #

CPU-bound — задача упирается в процессор:

считать хэши
обрабатывать изображения
сжимать видео
делать тяжёлые вычисления
парсить огромный JSON

Для этого обычно нужна многопроцессность.

I/O-bound — задача в основном ждёт внешний ресурс:

запрос в БД
HTTP-запрос
чтение файла
ответ от API
сообщение из очереди

Для этого обычно хватает асинхронности или потоков.

Схема выбора #

Много сетевого ожидания?
↓
asyncio или threads

Тяжёлые вычисления на CPU?
↓
multiprocessing / ProcessPoolExecutor

Есть async-библиотеки?
↓
asyncio

Библиотека блокирующая и async API нет?
↓
ThreadPoolExecutor / threading

Нужно использовать несколько ядер CPU?
↓
multiprocessing / ProcessPoolExecutor

Итог #

Асинхронность — много задач в одном потоке, переключение через await.

Многопоточность — много потоков в одном процессе, общая память, удобно для I/O.

Многопроцессность — много процессов, отдельная память, хорошо для CPU и настоящего параллелизма.

В Python чаще всего:

asyncio              → конкурентность для I/O
threading           → конкурентность для I/O
multiprocessing     → параллельность для CPU
ProcessPoolExecutor → удобная обёртка над процессами
ThreadPoolExecutor  → удобная обёртка над потоками

4. Многопоточность vs Многопроцессорность | threading vs multiprocessing #

Главное различие #

threading — несколько потоков внутри одного процесса.
multiprocessing — несколько отдельных процессов.

Точнее: в Python чаще говорят не “многопроцессорность”, а “многопроцессность”. Многопроцессорность — это скорее про железо: несколько CPU/ядер. multiprocessing — про запуск нескольких процессов, которые могут использовать эти ядра.

Коротко #

threading #

threading создаёт потоки внутри одного процесса:

Process
 ├── Thread 1
 ├── Thread 2
 └── Thread 3

Потоки разделяют одну память:

import threading

counter = 0

def work():
    global counter
    for _ in range(100_000):
        counter += 1

threads = [threading.Thread(target=work) for _ in range(4)]

for t in threads:
    t.start()

for t in threads:
    t.join()

print(counter)

Проблема: потоки работают с общими объектами. Поэтому возможны race condition, и для защиты общих данных нужны Lock, RLock, Semaphore, Queue и другие механизмы синхронизации.

В обычной сборке CPython GIL ограничивает выполнение Python-байткода: в один момент времени только один поток выполняет Python-код. Поэтому threading обычно не даёт сильного ускорения для CPU-bound задач. Но он полезен для I/O-bound задач: сеть, файлы, ожидание ответа БД, HTTP-запросы и т.д. Документация Python прямо указывает, что GIL ограничивает выгоду от threading для CPU-bound задач, но потоки всё равно полезны для конкурентного выполнения, особенно когда поток часто ждёт I/O.

multiprocessing #

multiprocessing запускает отдельные процессы:

Main Process
 ├── Worker Process 1
 ├── Worker Process 2
 └── Worker Process 3

У каждого процесса своя память и свой интерпретатор Python:

from multiprocessing import Process

def work():
    total = 0
    for i in range(10_000_000):
        total += i
    print(total)

processes = [Process(target=work) for _ in range(4)]

for p in processes:
    p.start()

for p in processes:
    p.join()

Так как процессы отдельные, они обходят ограничение одного GIL на процесс. Поэтому multiprocessing позволяет реально задействовать несколько CPU-ядер для CPU-bound задач. В документации Python сказано, что multiprocessing использует subprocesses вместо threads и таким образом обходит GIL, позволяя использовать несколько процессоров/ядер.

Минус: процессы тяжелее потоков. У них отдельная память, дороже запуск, сложнее обмен данными. Чтобы передать данные между процессами, обычно используют Queue, Pipe, Manager, shared_memory или сериализацию через pickle.

CPU-bound vs I/O-bound #

CPU-bound — задача упирается в вычисления процессора:

# CPU-bound
for i in range(100_000_000):
    result += i * i

Для таких задач лучше:

multiprocessing
ProcessPoolExecutor

I/O-bound — задача большую часть времени ждёт внешний ресурс:

# I/O-bound
response = requests.get("https://example.com")
data = db.query(...)
file.read()

Для таких задач обычно подходят:

threading
ThreadPoolExecutor
asyncio

Python-документация по конкурентному выполнению прямо разделяет выбор инструмента по типу задачи: CPU-bound или I/O-bound.

Через concurrent.futures #

На практике часто используют не Thread и Process напрямую, а высокоуровневые пулы:

from concurrent.futures import ThreadPoolExecutor, ProcessPoolExecutor

Для I/O-bound:

from concurrent.futures import ThreadPoolExecutor
import requests

urls = [
    "https://example.com",
    "https://python.org",
]

def fetch(url):
    return requests.get(url).status_code

with ThreadPoolExecutor(max_workers=4) as executor:
    results = list(executor.map(fetch, urls))

print(results)

Для CPU-bound:

from concurrent.futures import ProcessPoolExecutor

def calc(n):
    return sum(i * i for i in range(n))

with ProcessPoolExecutor(max_workers=4) as executor:
    results = list(executor.map(calc, [10_000_000] * 4))

print(results)

concurrent.futures даёт единый интерфейс: ThreadPoolExecutor для потоков и ProcessPoolExecutor для процессов. ProcessPoolExecutor использует multiprocessing, что позволяет обходить GIL, но требует, чтобы передаваемые функции и данные могли сериализоваться.

Почему threading не ускоряет CPU-bound код в обычном CPython #

Пример:

def cpu_task():
    total = 0
    for i in range(50_000_000):
        total += i
    return total

Если запустить такую функцию в нескольких потоках, потоки будут конкурировать за GIL. Они могут переключаться между собой, но не будут одновременно выполнять Python-байткод на разных ядрах в рамках одного процесса.

То есть:

Thread 1: работает
Thread 2: ждёт GIL
Thread 3: ждёт GIL
Thread 4: ждёт GIL

А при multiprocessing:

Process 1: работает на CPU core 1
Process 2: работает на CPU core 2
Process 3: работает на CPU core 3
Process 4: работает на CPU core 4

Поэтому для тяжёлых вычислений чаще выбирают процессы.

Когда выбирать threading #

threading подходит, когда задача часто ждёт:

HTTP-запросы
работа с файлами
запросы к БД
сетевые операции
ожидание внешнего API

Пример:

# Много сетевых запросов
# Поток ждёт ответ сервера, в это время другой поток может работать

Плюсы:

+ меньше расход памяти
+ проще обмениваться объектами
+ быстрее запуск, чем у процессов
+ хорошо для I/O-bound

Минусы:

- GIL мешает CPU-bound ускорению
- общая память создаёт race condition
- нужны lock-и
- сложнее отлаживать ошибки конкуренции

Когда выбирать multiprocessing #

multiprocessing подходит, когда задача реально грузит CPU:

математические вычисления
обработка изображений
парсинг больших файлов
сжатие/шифрование
тяжёлая обработка данных
ML/численные расчёты, если код не уходит в C-библиотеки

Плюсы:

+ реальный параллелизм на нескольких ядрах
+ обход GIL
+ изоляция памяти
+ падение одного процесса меньше портит состояние других

Минусы:

- больше расход RAM
- дороже запуск
- сложнее обмен данными
- данные часто нужно сериализовать
- на Windows особенно важно использовать if __name__ == "__main__"

Пример для Windows и кроссплатформенного кода:

from multiprocessing import Process

def work():
    print("worker")

if __name__ == "__main__":
    p = Process(target=work)
    p.start()
    p.join()

Важный нюанс про новые версии Python #

Начиная с Python 3.13, в CPython появилась поддержка экспериментальной free-threaded сборки, где GIL может быть отключён. В такой сборке потоки могут использовать несколько CPU-ядер полноценнее. Но это не отменяет стандартное правило для обычного CPython: в типичной сборке GIL всё ещё важен, и для CPU-bound задач чаще используют процессы.

Итоговая формула #

Много ожидания I/O?
    threading / ThreadPoolExecutor / asyncio

Много чистых CPU-вычислений?
    multiprocessing / ProcessPoolExecutor

Нужно простое конкурентное выполнение с общей памятью?
    threading

Нужно реально загрузить несколько ядер CPU?
    multiprocessing

Главная мысль:

threading = конкурентность внутри одного процесса
multiprocessing = параллельность через несколько процессов

В Python threading чаще используют для I/O-bound задач, а multiprocessing — для CPU-bound задач.

5. Что такое многопроцессорность, процесс и зачем нужен multiprocessing #

multiprocessing нужен, чтобы запускать код Python в нескольких отдельных процессах, а не в нескольких потоках.

Главная причина: в обычном CPython есть GIL, из-за которого несколько потоков не могут одновременно выполнять Python-байткод в одном процессе. multiprocessing обходит это ограничение, потому что каждый процесс имеет свой интерпретатор Python и свой GIL. Официальная документация Python прямо описывает multiprocessing как process-based parallelism и указывает, что он использует subprocesses вместо threads, позволяя задействовать несколько процессоров/ядер.

Что такое многопроцессорность #

Строго говоря, есть два похожих термина:

Многопроцессорность / multicore / multiprocessor
= несколько CPU или ядер могут выполнять работу параллельно

Многопроцессность / multiprocessing
= программа запускает несколько отдельных процессов

В Python, когда говорят про multiprocessing, обычно имеют в виду именно многопроцессность:

одна программа
 ├── процесс 1
 ├── процесс 2
 ├── процесс 3
 └── процесс 4

Эти процессы операционная система может распределить по разным ядрам CPU.

Что такое процесс #

Процесс — это отдельный экземпляр выполняемой программы.

У процесса есть:

своё адресное пространство памяти
свои переменные
свой Python-интерпретатор
свой GIL
свои ресурсы ОС
один или несколько потоков внутри

Пример:

python main.py

Когда ты запускаешь этот файл, ОС создаёт процесс Python.

Упрощённо:

Process
 ├── память процесса
 ├── глобальные переменные
 ├── открытые файлы/сокеты
 ├── Python-интерпретатор
 └── main thread

Поток — это более мелкая единица выполнения внутри процесса. Документация Python описывает threading как способ запускать несколько потоков, то есть smaller units of a process, внутри одного процесса.

Что делает multiprocessing #

Модуль multiprocessing позволяет из Python-кода создавать и управлять отдельными процессами.

Пример:

from multiprocessing import Process

def work():
    print("Работаю в отдельном процессе")

if __name__ == "__main__":
    p = Process(target=work)
    p.start()
    p.join()

Что здесь происходит:

main process
 └── создаёт child process
      └── child process выполняет work()

p.start() запускает новый процесс.
p.join() заставляет главный процесс дождаться завершения дочернего процесса.

Зачем нужен multiprocessing #

Главная задача multiprocessing — выполнять CPU-bound задачи параллельно.

CPU-bound — это задачи, которые сильно грузят процессор:

математические вычисления
обработка больших файлов
обработка изображений
сжатие данных
криптографические вычисления
тяжёлый парсинг
расчёты

Пример CPU-bound задачи:

def calc(n):
    total = 0

    for i in range(n):
        total += i * i

    return total

Для такой задачи threading в обычном CPython обычно не даст нормального ускорения, потому что потоки будут конкурировать за GIL.

Один процесс + несколько потоков:

Process
 ├── Thread 1 ждёт GIL
 ├── Thread 2 выполняет Python-код
 ├── Thread 3 ждёт GIL
 └── Thread 4 ждёт GIL

А multiprocessing создаёт несколько процессов:

Process 1 → CPU core 1
Process 2 → CPU core 2
Process 3 → CPU core 3
Process 4 → CPU core 4

Поэтому процессы могут реально выполнять Python-код параллельно на разных ядрах.

Почему не всегда использовать multiprocessing #

Потому что процессы тяжелее потоков.

Минусы:

процессы занимают больше RAM
процесс создать дороже, чем поток
данные между процессами передавать сложнее
обычные Python-объекты не разделяются напрямую
часто нужна сериализация через pickle

Документация ProcessPoolExecutor отдельно указывает, что он использует multiprocessing, обходит GIL, но требует, чтобы вызываемые объекты и возвращаемые значения были picklable.

Почему у процессов отдельная память #

При threading потоки живут внутри одного процесса и видят общие объекты:

Process
 ├── Thread 1
 ├── Thread 2
 └── shared memory

При multiprocessing каждый процесс изолирован:

Process 1 → memory 1
Process 2 → memory 2
Process 3 → memory 3

Поэтому такой код не работает так, как может показаться:

from multiprocessing import Process

counter = 0

def increment():
    global counter
    counter += 1

if __name__ == "__main__":
    p1 = Process(target=increment)
    p2 = Process(target=increment)

    p1.start()
    p2.start()

    p1.join()
    p2.join()

    print(counter)

counter в главном процессе останется 0, потому что дочерние процессы меняли свои копии переменной, а не оригинальную переменную главного процесса.

Как процессы обмениваются данными #

Для обмена данными используют специальные механизмы:

Queue
Pipe
Manager
Value / Array
shared_memory

Пример с Queue:

from multiprocessing import Process, Queue

def worker(q):
    result = 10 + 20
    q.put(result)

if __name__ == "__main__":
    q = Queue()

    p = Process(target=worker, args=(q,))
    p.start()
    p.join()

    result = q.get()
    print(result)

Здесь дочерний процесс не меняет переменную главного процесса напрямую. Он кладёт результат в очередь.

Pool и ProcessPoolExecutor #

Обычно вручную создавать Process нужно не всегда. Часто удобнее использовать пул процессов.

Через multiprocessing.Pool:

from multiprocessing import Pool

def calc(n):
    return sum(i * i for i in range(n))

if __name__ == "__main__":
    with Pool(processes=4) as pool:
        results = pool.map(calc, [10_000_000, 10_000_000, 10_000_000, 10_000_000])

    print(results)

Через concurrent.futures.ProcessPoolExecutor:

from concurrent.futures import ProcessPoolExecutor

def calc(n):
    return sum(i * i for i in range(n))

if __name__ == "__main__":
    with ProcessPoolExecutor(max_workers=4) as executor:
        results = list(executor.map(calc, [10_000_000] * 4))

    print(results)

ProcessPoolExecutor — более высокоуровневый интерфейс для запуска задач в пуле процессов. Документация Python описывает его как executor, который использует пул процессов для асинхронного выполнения вызовов.

Когда использовать multiprocessing #

Используй multiprocessing, когда:

задача CPU-bound
нужно задействовать несколько ядер CPU
вычисления тяжёлые
потоки не дают ускорения из-за GIL
данные между задачами можно передавать относительно редко

Примеры:

обработать 10 000 изображений
посчитать тяжёлую математику
распарсить большой объём данных
запустить независимые CPU-задачи
обработать файлы параллельно

Когда лучше не использовать multiprocessing #

Не лучший выбор, когда задача I/O-bound:

HTTP-запросы
запросы в БД
ожидание Redis
чтение файлов
сетевые операции

Для такого чаще подходят:

threading
ThreadPoolExecutor
asyncio

Официальная документация Python по конкурентному выполнению указывает, что выбор инструмента зависит от типа задачи: CPU-bound или I/O-bound.

Итог #

Процесс
= отдельный запущенный экземпляр программы со своей памятью

Многопроцессность
= запуск нескольких процессов

Многопроцессорность
= возможность использовать несколько CPU/ядер

multiprocessing
= Python-модуль для запуска нескольких процессов

Главная польза multiprocessing:

обойти GIL
загрузить несколько ядер CPU
ускорить CPU-bound задачи
изолировать выполнение по процессам

Главная цена:

больше памяти
дороже запуск
сложнее обмен данными
нужна сериализация объектов

6. Что такое и чем отличается вытесняющая многозадачность от кооперативной? #

Вытесняющая и кооперативная многозадачность отличаются тем, кто решает, когда одна задача должна уступить выполнение другой.

Вытесняющая многозадачность
= задачу может остановить планировщик ОС/рантайма

Кооперативная многозадачность
= задача сама добровольно отдаёт управление

Вытесняющая многозадачность #

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

Например:

Thread 1 работает
↓
ОС решает: "хватит, теперь работает Thread 2"
↓
Thread 2 работает
↓
ОС снова переключает выполнение

То есть задача не обязана сама писать:

yield_control()

Её могут остановить извне.

Обычно так работают потоки ОС:

Process
 ├── Thread 1
 ├── Thread 2
 └── Thread 3

Операционная система выдаёт каждому потоку немного CPU-времени. Когда квант времени закончился или появилась более приоритетная задача, планировщик может переключить CPU на другой поток. В документации Linux это описывается как preemption: задача может быть вытеснена, когда планировщик считает, что она уже использовала свою долю CPU-времени.

Пример вытесняющей многозадачности #

import threading

def task(name):
    for i in range(5):
        print(name, i)

t1 = threading.Thread(target=task, args=("A",))
t2 = threading.Thread(target=task, args=("B",))

t1.start()
t2.start()

t1.join()
t2.join()

Ты не указываешь вручную, где именно поток A должен уступить место потоку B.

Переключение происходит неявно:

A 0
A 1
B 0
A 2
B 1
B 2
...

Порядок может быть разным при разных запусках.

Главный плюс вытесняющей модели #

Плюс в том, что одна задача не обязана быть “вежливой”.

Даже если поток выполняет долгий цикл:

while True:
    do_work()

ОС всё равно может переключить CPU на другие потоки или процессы.

То есть система остаётся более отзывчивой.

Главный минус вытесняющей модели #

Минус — задача может быть прервана почти в любой момент.

Например:

counter += 1

На уровне реального выполнения это не обязательно одна атомарная операция:

прочитать counter
увеличить значение
записать обратно

Если поток прервали между этими шагами, другой поток может изменить те же данные. Поэтому в вытесняющей модели часто нужны блокировки:

import threading

lock = threading.Lock()
counter = 0

def increment():
    global counter

    with lock:
        counter += 1

Иначе возможны race condition.

Кооперативная многозадачность #

Кооперативная многозадачность — это когда задача сама решает, когда отдать управление.

Например:

Task 1 работает
↓
Task 1 дошла до await
↓
event loop запускает Task 2
↓
Task 2 дошла до await
↓
event loop возвращается к Task 1

В Python это типичная модель asyncio.

Официальная документация Python прямо говорит, что event loop использует cooperative scheduling: event loop выполняет одну Task за раз, а когда задача делает await и ждёт Future, event loop запускает другие задачи.

Пример кооперативной многозадачности #

import asyncio

async def task(name):
    for i in range(3):
        print(name, i)
        await asyncio.sleep(1)

async def main():
    await asyncio.gather(
        task("A"),
        task("B"),
    )

asyncio.run(main())

Здесь переключение происходит на await:

A 0
await asyncio.sleep(1)
↓
B 0
await asyncio.sleep(1)
↓
A 1
...

await — это место, где корутина добровольно отдаёт управление event loop.

Важный пример проблемы #

import asyncio

async def bad_task():
    while True:
        pass

async def normal_task():
    while True:
        print("Я тоже хочу работать")
        await asyncio.sleep(1)

async def main():
    await asyncio.gather(
        bad_task(),
        normal_task(),
    )

asyncio.run(main())

normal_task() почти не получит управление, потому что bad_task() никогда не делает await.

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

async def better_task():
    while True:
        # какая-то работа
        await asyncio.sleep(0)

await asyncio.sleep(0) здесь означает: “отдай управление event loop, пусть другие задачи тоже выполнятся”.

Ключевое отличие #

Вытесняющая:
планировщик может остановить задачу сам

Кооперативная:
задача должна сама уступить управление

Сравнение:

Как это связано с threading #

threading в Python работает с потоками ОС. Потоки — это единицы выполнения внутри процесса. Документация Python описывает threading как модуль для запуска нескольких потоков внутри одного процесса.

Схема:

Process
 ├── Thread 1
 ├── Thread 2
 └── Thread 3

Потоки могут быть переключены планировщиком в неожиданный момент:

Thread 1 начал менять общий список
↓
его вытеснили
↓
Thread 2 тоже меняет этот список
↓
получили некорректное состояние

Поэтому для общего состояния нужны синхронизация и осторожность.

Как это связано с asyncio #

asyncio работает иначе:

Event loop
 ├── Task 1
 ├── Task 2
 └── Task 3

Но event loop выполняет только одну задачу в конкретный момент времени:

Task 1 работает до await
Task 2 работает до await
Task 3 работает до await

Поэтому в asyncio меньше неожиданных переключений между строками кода. Но есть другое правило: нельзя надолго занимать event loop синхронным кодом.

Плохой вариант:

async def handler():
    heavy_cpu_calculation()

Лучше:

async def handler():
    result = await asyncio.to_thread(heavy_cpu_calculation)

Или для тяжёлых CPU-bound задач — вынести работу в процессы.

Простая аналогия #

Вытесняющая модель:

Учитель сам забирает слово у ученика и передаёт другому.

Кооперативная модель:

Ученик сам должен сказать: "Я закончил, пусть говорит другой".

Если ученик в кооперативной модели никогда не замолчит, остальные не смогут говорить.

Главное для Python #

threading
= ближе к вытесняющей многозадачности

asyncio
= кооперативная многозадачность

multiprocessing
= отдельные процессы, которые ОС тоже планирует вытесняюще

Итог #

Вытесняющая многозадачность удобна тем, что планировщик сам распределяет CPU между задачами, но из-за неожиданных переключений появляются race condition и нужны lock-и.

Кооперативная многозадачность удобна тем, что переключения происходят в понятных местах — обычно на await, но задача может заблокировать весь event loop, если долго работает без отдачи управления.

7. Что такое Гринлеты (greenlet) и чем они отличаются от Асинхронности #

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

asyncio / асинхронность — это модель, где корутины переключаются через await, а их выполнением управляет event loop.

greenlet
= ручное переключение: g1.switch()

asyncio
= переключение через await под управлением event loop

Официальная документация greenlet описывает greenlets как lightweight coroutines для in-process concurrent programming. Документация asyncio описывает asyncio как библиотеку для concurrent code через синтаксис async/await.

Что такое greenlet #

greenlet — это объект, который хранит собственный стек выполнения и может быть приостановлен, а потом продолжен с того же места.

Пример:

from greenlet import greenlet

def task1():
    print("task1: start")
    g2.switch()
    print("task1: end")

def task2():
    print("task2: start")
    g1.switch()
    print("task2: end")

g1 = greenlet(task1)
g2 = greenlet(task2)

g1.switch()

Результат будет примерно такой:

task1: start
task2: start
task1: end

Что произошло:

g1 начал выполняться
↓
g1 вручную переключился на g2
↓
g2 начал выполняться
↓
g2 вручную переключился обратно на g1
↓
g1 продолжил выполнение

В greenlet переключение происходит через .switch(). Документация прямо говорит, что переключение между greenlet-ами происходит при вызове greenlet.switch() или greenlet.throw().

Главное свойство greenlet #

Greenlet может переключиться из глубоко вложенного вызова без await.

Например:

from greenlet import greenlet

def deep_function():
    print("inside deep function")
    main.switch()
    print("back inside deep function")

def worker():
    print("worker start")
    deep_function()
    print("worker end")

main = greenlet.getcurrent()
g = greenlet(worker)

g.switch()
print("main continues")
g.switch()

Здесь deep_function() может отдать управление наружу через main.switch(), хотя сама функция не объявлена как async def и внутри нет await.

Это важное отличие от asyncio.

Что такое асинхронность в Python #

В современном Python под асинхронностью обычно имеют в виду asyncio:

import asyncio

async def task1():
    print("task1: start")
    await asyncio.sleep(1)
    print("task1: end")

async def task2():
    print("task2: start")
    await asyncio.sleep(1)
    print("task2: end")

async def main():
    await asyncio.gather(task1(), task2())

asyncio.run(main())

Здесь переключение происходит не через .switch(), а через await.

task1 работает до await
↓
event loop запускает task2
↓
task2 работает до await
↓
event loop возвращается к task1

Документация Python указывает, что event loop выполняет одну Task за раз; когда задача ждёт Future, event loop запускает другие задачи.

Основное отличие #

Greenlet — это не поток #

Greenlet не равен thread.

Thread
= поток ОС

Greenlet
= лёгкая корутина внутри процесса/потока

Обычно несколько greenlet-ов выполняются внутри одного OS thread:

Process
 └── Thread
      ├── greenlet 1
      ├── greenlet 2
      └── greenlet 3

Они не выполняют Python-код одновременно на разных ядрах. Они просто переключаются между собой.

Документация greenlet отдельно отмечает, что greenlet-ы можно сочетать с Python threads, но у каждого потока своё дерево greenlet-ов, и нельзя переключаться между greenlet-ами разных потоков.

Greenlet — это низкоуровневая корутина #

Можно сказать так:

greenlet
= низкоуровневый механизм переключения контекста

asyncio
= полноценная асинхронная модель с event loop, Task, Future, await

Сам по себе greenlet не делает сетевой код асинхронным.

Например:

import requests
from greenlet import greenlet

def task():
    requests.get("https://example.com")

Если requests.get() блокирует поток, то greenlet сам по себе не спасёт. Он не умеет автоматически превращать блокирующий I/O в неблокирующий.

Для этого нужны библиотеки поверх greenlet, например gevent. Документация gevent описывает его как coroutine-based networking library, которая использует greenlet и event loop на базе libev/libuv.

Зачем тогда greenlet нужен #

greenlet полезен как строительный блок для библиотек, которые хотят дать “синхронный на вид” код, но внутри выполнять его конкурентно.

Например, вместо такого async-кода:

async def handler():
    result = await db.fetch(...)

библиотека может дать более обычный стиль:

def handler():
    result = db.fetch(...)

А внутри библиотека сама переключает greenlet-ы, когда операция ждёт I/O.

Идея:

код выглядит синхронно
↓
но библиотека внутри переключает greenlet-ы
↓
другие задачи могут выполняться во время ожидания I/O

Такой подход используют, например, gevent и некоторые внутренние механизмы библиотек.

В чём отличие от async/await #

В asyncio точки переключения явно видны:

await something()

Ты сразу видишь: здесь функция может приостановиться.

В greenlet переключение может быть спрятано внутри обычного вызова:

result = db.fetch()

Снаружи это выглядит как обычная синхронная функция, но внутри она может переключить greenlet.

Сравнение:

asyncio:
явная асинхронность

greenlet:
скрытое переключение контекста

Пример на уровне идеи #

asyncio:

async def get_data():
    data = await fetch()
    return data

Точка переключения видна:

await fetch()

greenlet:

def get_data():
    data = fetch()
    return data

Точка переключения может быть внутри fetch():

fetch()
 └── внутри где-то вызван greenlet.switch()

Связь с кооперативной многозадачностью #

И greenlet, и asyncio относятся к кооперативной модели.

То есть задача сама должна уступить управление:

greenlet → через switch()
asyncio   → через await

Но разница в том, что asyncio встроен в язык и стандартную библиотеку как понятная модель async/await, а greenlet — сторонний низкоуровневый механизм переключения стеков.

Важное ограничение #

greenlet не решает проблему GIL.

greenlet ≠ multiprocessing
greenlet ≠ параллельное выполнение на нескольких ядрах
greenlet ≠ ускорение CPU-bound задач

Если задача CPU-bound:

def cpu_heavy():
    for i in range(100_000_000):
        ...

то greenlet не сделает её параллельной. Для CPU-bound обычно нужны:

multiprocessing
ProcessPoolExecutor
нативные расширения, которые отпускают GIL

Итог #

greenlet
= низкоуровневая лёгкая корутина
= ручное переключение через .switch()
= может прятать переключение внутри обычных функций
= часто используется библиотеками вроде gevent

asyncio
= стандартная async-модель Python
= event loop + Task + Future + async/await
= переключение явно через await
= основной современный способ писать асинхронный I/O в Python

Главная разница:

asyncio заставляет явно писать async/await

greenlet позволяет переключать выполнение без async/await,
но сам по себе не даёт полноценный асинхронный I/O

Практически: для обычного современного Python-кода чаще выбирают asyncio. greenlet чаще встречается внутри библиотек или фреймворков, которым нужно дать синхронный API поверх конкурентного выполнения.

8. Какой тип многозадачности используют greenlet? #

greenlet используют кооперативную многозадачность.

То есть greenlet не вытесняется планировщиком ОС сам по себе. Он продолжает выполняться, пока сам не отдаст управление другому greenlet через switch().

Официальная документация greenlet описывает greenlet-ы как лёгкие корутины для конкурентного выполнения внутри процесса. В разделе про переключение сказано, что переход между greenlet-ами выполняется через g.switch(...). То есть переключение не происходит автоматически, его явно инициирует сам код.

Почему это кооперативная модель #

В кооперативной многозадачности задача сама уступает управление:

Greenlet A работает
↓
Greenlet A вызывает g2.switch()
↓
Greenlet B продолжает выполнение
↓
Greenlet B вызывает g1.switch()
↓
Greenlet A продолжает выполнение

Пример:

from greenlet import greenlet

def task1():
    print("task1 start")
    g2.switch()
    print("task1 end")

def task2():
    print("task2 start")
    g1.switch()
    print("task2 end")

g1 = greenlet(task1)
g2 = greenlet(task2)

g1.switch()

Здесь task1 не вытесняется извне. Она сама вызывает:

g2.switch()

и добровольно передаёт управление task2.

Важный момент #

Сам greenlet — это низкоуровневый механизм переключения контекста. Он не является полноценным планировщиком задач.

То есть greenlet сам по себе не делает так:

каждому greenlet дать по 10 мс CPU-времени
потом автоматически переключить на следующий

Так работает вытесняющая многозадачность у потоков ОС.

У greenlet иначе:

нет switch() → нет переключения

Документация greenlet прямо формулирует это так: переходы между greenlet-ами не являются неявными; greenlet должен сам выбрать переход к другому greenlet-у.

Сравнение с потоками #

threading
= вытесняющая многозадачность на уровне потоков ОС

greenlet
= кооперативная многозадачность внутри процесса/потока

Схема:

Process
 └── OS Thread
      ├── greenlet 1
      ├── greenlet 2
      └── greenlet 3

Обычно greenlet-ы живут внутри одного потока ОС. Поэтому они не выполняют Python-код параллельно на разных ядрах. Они просто переключаются между собой.

Если использовать gevent #

gevent построен поверх greenlet и добавляет event loop. В документации gevent прямо сказано, что greenlet-ы выполняются в одном OS thread и планируются кооперативно: пока конкретный greenlet не отдаст управление, остальные не получают шанс выполниться.

То есть:

greenlet сам по себе
= ручное кооперативное переключение через switch()

gevent
= кооперативная многозадачность поверх greenlet + event loop

Итог #

greenlet используют кооперативную многозадачность

Главная причина:

greenlet не прерывается автоматически;
он сам должен передать управление другому greenlet-у

Ключевая формула:

threading → вытесняющая модель
asyncio   → кооперативная модель через await
greenlet  → кооперативная модель через switch()

9. Для каких типов задач целесообразно использовать асинхронность, многопоточность, мультипроцессность (I/O-bound vs CPU-bound)? #

I/O-bound задача
= программа в основном ждёт внешний ресурс:
  сеть, БД, файл, Redis, HTTP API

CPU-bound задача
= программа в основном грузит процессор:
  вычисления, парсинг, обработка изображений, сжатие, криптография

Выбор в Python обычно такой:

I/O-bound:
    asyncio
    threading
    ThreadPoolExecutor

CPU-bound:
    multiprocessing
    ProcessPoolExecutor

Основная таблица #

Асинхронность #

Асинхронность в Python обычно означает asyncio: async def, await, event loop, Task, Future.

asyncio хорошо подходит для I/O-bound и сетевого кода. В официальной документации Python сказано, что asyncio используется для конкурентного кода через async/await и часто хорошо подходит для I/O-bound и высокоуровневого сетевого кода.

Пример задачи:

import asyncio
import httpx

async def fetch(url):
    async with httpx.AsyncClient() as client:
        response = await client.get(url)
        return response.status_code

async def main():
    results = await asyncio.gather(
        fetch("https://example.com"),
        fetch("https://python.org"),
    )
    print(results)

asyncio.run(main())

Смысл:

одна корутина ждёт ответ от сети
↓
event loop переключается на другую корутину
↓
CPU не простаивает зря

Асинхронность не ускоряет тяжёлые вычисления сама по себе. Если внутри async def написать долгий CPU-bound цикл без await, он заблокирует event loop.

Плохой вариант:

async def handler():
    result = heavy_cpu_calculation()
    return result

Лучше вынести тяжёлую CPU-задачу в процесс, а блокирующую I/O-задачу — в поток.

Многопоточность #

threading подходит для I/O-bound задач, особенно когда используешь синхронные блокирующие библиотеки.

Например:

requests
psycopg2
обычный boto3
синхронный SDK внешнего сервиса

Официальная документация Python указывает, что threading полезен для I/O-bound задач, например файловых операций или сетевых запросов, где большая часть времени уходит на ожидание внешних ресурсов. Пример:

from concurrent.futures import ThreadPoolExecutor
import requests

def fetch(url):
    response = requests.get(url)
    return response.status_code

urls = [
    "https://example.com",
    "https://python.org",
]

with ThreadPoolExecutor(max_workers=10) as executor:
    results = list(executor.map(fetch, urls))

print(results)

Смысл:

Thread 1 ждёт HTTP-ответ
Thread 2 ждёт HTTP-ответ
Thread 3 ждёт HTTP-ответ
...

Пока один поток ждёт сеть, другой может тоже выполнять полезную работу или ждать свой I/O.

Но для CPU-bound задач обычный threading в CPython обычно не помогает: из-за GIL только один поток в процессе выполняет Python-байткод одновременно. Документация Python прямо указывает, что для лучшего использования многоядерных машин стоит использовать multiprocessing или ProcessPoolExecutor, а threading остаётся подходящей моделью для одновременного выполнения I/O-bound задач.

Мультипроцессность #

multiprocessing подходит для CPU-bound задач.

Пример:

from concurrent.futures import ProcessPoolExecutor

def calc(n):
    total = 0

    for i in range(n):
        total += i * i

    return total

if __name__ == "__main__":
    with ProcessPoolExecutor(max_workers=4) as executor:
        results = list(executor.map(calc, [10_000_000] * 4))

    print(results)

Смысл:

Process 1 → CPU core 1
Process 2 → CPU core 2
Process 3 → CPU core 3
Process 4 → CPU core 4

В Python с обычным GIL использование нескольких CPU-ядер обычно требует нескольких процессов или нативных расширений, которые отпускают GIL. Это указано в официальном глоссарии Python.

multiprocessing даёт реальный параллелизм для Python-кода, но цена выше:

больше расход RAM
дороже запуск процессов
сложнее обмен данными
нужна сериализация данных

Документация Python показывает, что multiprocessing.Pool используется для распределения работы по процессам, а ProcessPoolExecutor даёт более высокоуровневый интерфейс для выполнения задач в фоновых процессах.

Как выбирать на практике #

Задача ждёт сеть/БД/файл?
    Да → I/O-bound
        async-библиотеки есть?
            Да → asyncio
            Нет → threading / ThreadPoolExecutor

Задача грузит CPU?
    Да → CPU-bound
        multiprocessing / ProcessPoolExecutor

Задача смешанная?
    I/O часть → asyncio/threading
    CPU часть → вынести в процессы

Пример смешанной задачи #

Допустим, надо:

1. скачать 1000 страниц
2. распарсить HTML
3. посчитать тяжёлую статистику
4. сохранить результат в БД

Разделение:

скачать страницы        → asyncio
тяжёлый парсинг/расчёт  → ProcessPoolExecutor
сохранить в БД          → asyncio, если async-драйвер

Упрощённая схема:

asyncio event loop
 ├── скачивает данные
 ├── ждёт сеть/БД
 └── отправляет тяжёлую CPU-работу в process pool

Что выбрать для backend #

Для обычного backend на Python:

FastAPI + async DB driver + httpx.AsyncClient
    → asyncio

Django/DRF с синхронными ORM-вызовами
    → обычный sync-код + workers/threads на уровне сервера

Тяжёлая обработка файлов/изображений
    → отдельный worker/process pool/Celery workers

Много внешних API через синхронные SDK
    → ThreadPoolExecutor или отдельные workers

Ключевая формула #

asyncio
= много ожидания, мало CPU, async-библиотеки

threading
= много ожидания, но библиотеки синхронные/блокирующие

multiprocessing
= много CPU, нужно использовать несколько ядер

Самая частая ошибка:

CPU-bound задачу класть в asyncio

asyncio не делает вычисления параллельными. Оно эффективно тогда, когда задачи часто отдают управление на await, то есть ждут I/O.

10. Что такое и зачем нужны потоки в Python? #

Что такое поток #

Поток в Python — это отдельная линия выполнения внутри одного процесса.

Упрощённо:

Process
 ├── Main Thread
 ├── Thread 1
 ├── Thread 2
 └── Thread 3

Один процесс может иметь несколько потоков. Эти потоки выполняют разные функции, но живут внутри одного процесса и используют общую память.

Документация Python описывает threading как модуль для запуска нескольких потоков внутри одного процесса; потоки особенно полезны для I/O-bound задач — например, сетевых запросов и файловых операций.

Зачем нужны потоки #

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

Например, без потоков:

скачать файл 1
↓
дождаться завершения
↓
скачать файл 2
↓
дождаться завершения
↓
скачать файл 3

С потоками:

Thread 1 → скачивает файл 1
Thread 2 → скачивает файл 2
Thread 3 → скачивает файл 3

Пока один поток ждёт ответ от сети, другой поток тоже может выполнять работу или ждать свой ответ.

Пример #

import threading
import time

def task(name):
    print(f"{name}: start")
    time.sleep(2)
    print(f"{name}: end")

t1 = threading.Thread(target=task, args=("Thread 1",))
t2 = threading.Thread(target=task, args=("Thread 2",))

t1.start()
t2.start()

t1.join()
t2.join()

print("Done")

Что происходит:

t1.start() → запускает первый поток
t2.start() → запускает второй поток

t1.join()  → ждём завершения первого потока
t2.join()  → ждём завершения второго потока

Оба потока могут “спать” одновременно, поэтому программа завершится примерно за 2 секунды, а не за 4.

Где потоки полезны #

Потоки хорошо подходят для I/O-bound задач:

HTTP-запросы
запросы к БД
чтение/запись файлов
работа с сокетами
ожидание внешнего API
фоновые задачи в приложении

Пример с HTTP:

from concurrent.futures import ThreadPoolExecutor
import requests

def fetch(url):
    response = requests.get(url)
    return response.status_code

urls = [
    "https://example.com",
    "https://python.org",
]

with ThreadPoolExecutor(max_workers=4) as executor:
    results = list(executor.map(fetch, urls))

print(results)

ThreadPoolExecutor использует пул потоков для асинхронного выполнения вызовов, то есть позволяет отправлять задачи в фоновые потоки через более удобный интерфейс, чем ручное создание Thread.

Почему потоки не всегда ускоряют код #

В обычном CPython есть GIL — Global Interpreter Lock.

Из-за GIL в одном процессе только один поток одновременно выполняет Python-байткод. Поэтому потоки обычно не дают сильного ускорения для CPU-bound задач. Это прямо указано в документации Python: GIL ограничивает выгоду threading для CPU-bound задач, хотя потоки остаются полезными для I/O-bound сценариев.

CPU-bound пример:

def calc():
    total = 0

    for i in range(100_000_000):
        total += i * i

    return total

Для такой задачи threading обычно не лучший выбор.

Схема:

Thread 1 хочет выполнять Python-код
Thread 2 хочет выполнять Python-код
Thread 3 хочет выполнять Python-код

Но GIL разрешает выполнять Python-байткод только одному потоку за раз

Для CPU-bound задач чаще используют:

multiprocessing
ProcessPoolExecutor

Важное свойство потоков: общая память #

Потоки внутри одного процесса видят одни и те же объекты:

import threading

counter = 0

def increment():
    global counter

    for _ in range(100_000):
        counter += 1

threads = [
    threading.Thread(target=increment),
    threading.Thread(target=increment),
]

for thread in threads:
    thread.start()

for thread in threads:
    thread.join()

print(counter)

На первый взгляд кажется, что результат всегда должен быть:

200000

Но при работе с общими изменяемыми данными могут возникать race condition.

Проблема в том, что операция:

counter += 1

логически состоит из нескольких шагов:

прочитать counter
увеличить значение
записать обратно

Если потоки вмешаются друг в друга между этими шагами, результат может стать некорректным.

Для защиты используют Lock #

import threading

counter = 0
lock = threading.Lock()

def increment():
    global counter

    for _ in range(100_000):
        with lock:
            counter += 1

threads = [
    threading.Thread(target=increment),
    threading.Thread(target=increment),
]

for thread in threads:
    thread.start()

for thread in threads:
    thread.join()

print(counter)

Lock защищает критическую секцию:

один поток вошёл в with lock
↓
другие ждут
↓
первый поток закончил
↓
следующий поток входит

Потоки vs процессы #

threading
= несколько потоков внутри одного процесса
= общая память
= хорошо для I/O-bound
= хуже для CPU-bound из-за GIL

multiprocessing
= несколько отдельных процессов
= отдельная память
= лучше для CPU-bound
= дороже по памяти и запуску

Потоки vs asyncio #

threading
= вытесняющая многозадачность потоков ОС

asyncio
= кооперативная многозадачность через await

В потоках переключение может произойти неявно:

Thread 1 работает
↓
ОС/интерпретатор переключил выполнение
↓
Thread 2 работает

В asyncio переключение обычно видно явно:

await something()

Когда использовать потоки #

Потоки стоит использовать, когда:

задача часто ждёт внешний ресурс
используются синхронные библиотеки
нужно не блокировать основной поток
нужно выполнить несколько I/O-операций конкурентно

Примеры:

скачать много URL через requests
сделать много запросов к синхронной БД
работать с несколькими файлами
вынести блокирующую операцию из основного потока

Когда не стоит использовать потоки #

Потоки не лучший выбор, когда:

задача тяжёлая по CPU
много общего изменяемого состояния
нужен простой и предсказуемый порядок выполнения
можно использовать нормальные async-библиотеки

Для CPU-bound:

ProcessPoolExecutor / multiprocessing

Для async I/O:

asyncio

Итог #

Потоки в Python нужны для конкурентного выполнения задач внутри одного процесса.

Главная польза:

не простаивать во время ожидания I/O
выполнять блокирующие операции в фоне
обрабатывать несколько внешних операций одновременно

Главное ограничение:

из-за GIL потоки обычно не ускоряют CPU-bound Python-код

Формула выбора:

много ожидания I/O + синхронные библиотеки → threading

много ожидания I/O + async-библиотеки → asyncio

много CPU-вычислений → multiprocessing

11. Как реализована модель асинхронного выполнения? #

Асинхронное выполнение в Python обычно реализуется через asyncio: это модель конкурентного выполнения, где один поток может обслуживать много задач, переключаясь между ними в моменты ожидания I/O, например сети, БД, файловых операций через async-библиотеки. asyncio описывается в документации как библиотека для конкурентного кода с синтаксисом async / await.

Главная идея:

Одна задача ждёт I/O
↓
она отдаёт управление event loop
↓
event loop запускает другую готовую задачу
↓
когда I/O завершилось, первая задача продолжается

Это не означает, что Python-код внутри одного event loop выполняется параллельно на нескольких ядрах. Это кооперативная многозадачность: задача сама отдаёт управление через await.

Основные компоненты #

1. Coroutine #

Корутина — это объект, который получается при вызове async def функции:

async def get_data():
    return 123

coro = get_data()

Важный момент: сам вызов get_data() ещё не выполняет тело функции. Корутина начнёт выполняться только когда её await-нут или запланируют как задачу. В документации Python прямо указано, что корутины и задачи могут выполняться только при работающем event loop.

result = await get_data()

2. Event loop #

event loop — центральный механизм asyncio. Он запускает асинхронные задачи, callback-функции, выполняет сетевой I/O и работает с подпроцессами.

Упрощённо:

event loop:
  1. берёт готовую задачу
  2. выполняет её до ближайшего await
  3. если задача ждёт I/O — откладывает её
  4. запускает другую готовую задачу
  5. возвращается к первой, когда её ожидание завершилось

3. Task #

Task — это обёртка над корутиной, которая позволяет запланировать её выполнение в event loop. Например, asyncio.create_task() запускает корутину конкурентно с другими задачами.

task = asyncio.create_task(get_data())

То есть:

coroutine
↓ оборачивается в Task
Task попадает в event loop
↓
event loop решает, когда продолжить её выполнение

4. Future #

Future — объект, который представляет будущий результат асинхронной операции. Корутина может ждать Future, пока в нём не появится результат, исключение или отмена.

Примерно:

Future = "результат ещё не готов, но будет позже"

Когда результат готов, event loop возобновляет задачу, которая ждала этот Future.

Что делает await #

await — это точка добровольной остановки корутины.

async def main():
    data = await fetch_data()
    print(data)

Когда выполнение доходит до await fetch_data():

main() временно приостанавливается
↓
управление возвращается event loop
↓
event loop запускает другие задачи
↓
fetch_data() завершилась
↓
main() продолжается с места await

Важно: await не создаёт новый поток. Он только говорит:
«я сейчас жду, можешь пока выполнять другие задачи».

Пример #

import asyncio


async def task(name, delay):
    print(f"{name}: start")
    await asyncio.sleep(delay)
    print(f"{name}: end")


async def main():
    t1 = asyncio.create_task(task("A", 2))
    t2 = asyncio.create_task(task("B", 1))

    await t1
    await t2


asyncio.run(main())

Выполнение будет примерно таким:

A: start
B: start
B: end
A: end

Почему?

task A дошла до await sleep(2)
↓
отдала управление event loop

task B дошла до await sleep(1)
↓
отдала управление event loop

через 1 секунду B готова
↓
event loop продолжает B

через 2 секунды A готова
↓
event loop продолжает A

Важная деталь: внутри event loop задача выполняется одна за раз #

Обычно event loop работает в одном потоке. Документация Python указывает, что event loop выполняет callback-и и Tasks в своём потоке; пока одна Task выполняется, другие Tasks в этом же loop не выполняются.

То есть асинхронность в Python — это не так:

Task A реально выполняется на CPU
Task B реально выполняется на CPU
Task C реально выполняется на CPU

А так:

Task A выполняется до await
Task B выполняется до await
Task C выполняется до await
Task A продолжает после I/O
Task B продолжает после I/O

Почему это эффективно для I/O-bound задач #

Асинхронность полезна, когда программа много ждёт:

запрос в БД
HTTP-запрос
чтение из сокета
ожидание Redis
ожидание ответа внешнего API

В синхронной модели поток часто простаивает:

отправил запрос → ждёт ответ → ничего не делает

В асинхронной модели:

отправил запрос → переключился на другую задачу → вернулся, когда ответ готов

Поэтому asyncio часто используется как основа для сетевых серверов, асинхронных web-фреймворков, клиентов БД и очередей. Это также указано в официальной документации Python.

Почему это плохо для CPU-bound задач #

Если задача долго считает на CPU и не делает await, она блокирует event loop:

async def bad():
    while True:
        pass

Пока такой код крутится, другие async-задачи не получают управление.

Плохой вариант:

async def handler():
    result = heavy_calculation()  # долго считает CPU
    return result

Лучше:

result = await asyncio.to_thread(heavy_calculation)

или использовать multiprocessing, если задача реально CPU-bound и нужно задействовать несколько ядер.

Общая схема #

async def
   ↓
coroutine object
   ↓
await / create_task()
   ↓
Task
   ↓
event loop
   ↓
выполнение до await
   ↓
ожидание Future / I/O
   ↓
другая Task выполняется
   ↓
I/O завершилось
   ↓
первая Task продолжается

Коротко по сути #

Асинхронная модель выполнения в Python устроена так:

1. async def создаёт корутину
2. корутина запускается через await или Task
3. event loop управляет задачами
4. await приостанавливает текущую задачу
5. пока одна задача ждёт I/O, выполняются другие
6. после завершения ожидания задача продолжается

Главное отличие от потоков: переключение происходит не принудительно ОС, а в контролируемых местах — на await. Поэтому это кооперативная конкурентность, а не автоматический параллелизм.

12. Что обозначают ключевые слова async и await в механизме корутин? #

async/await - это ключевые слова, представленные в Python 3.5 для определения асинхронных функций и вызовов. Они позволяют объявлять асинхронные функции и делать вызовы асинхронных функций в местах, где обычно используется блокирующий вызов.

Кратко:

• async — объявляет асинхронную функцию (корутину)
• await — приостанавливает выполнение корутины до завершения асинхронной операции
• event loop — управляет выполнением асинхронных задач

Корутина — это специальный тип функции, которая может приостанавливать свое выполнение и возобновлять его позже.

В Python корутины создаются с помощью ключевого слова async def

async def my_coroutine():
    print("Начало корутины")
    await asyncio.sleep(1)
    print("Корутина завершена")

Особенности корутин:

• При вызове возвращают объект корутины, а не результат
• Для выполнения требуют наличия event loop
• Могут содержать выражения await
• Не выполняются до тех пор, пока не будут запланированы в event loop

Event Loop (Цикл событий) — это ядро асинхронного программирования в Python.

Он отвечает за:

• Выполнение корутин и обратных вызовов
• Выполнение сетевых операций ввода-вывода
• Запуск подпроцессов

# Создание и управление event loop вручную
loop = asyncio.new_event_loop()
asyncio.set_event_loop(loop)
    
try:
	loop.run_until_complete(my_coroutine())
finally:
	loop.close()

Ключевое слово Await

Выражение await приостанавливает выполнение корутины до тех пор, пока ожидаемый объект (awaitable) не вернет результат. Во время этой паузы event loop может выполнять другие задачи.

Что можно использовать с await:

• Другие корутины
• Задачи (Tasks)
• Футуры (Futures)
• Объекты, реализующие метод await

🚀 Жизненный цикл асинхронной операции:

• Создание корутины — функция объявлена как async def
• Вызов корутины — создается объект корутины, но выполнение не начинается
• Планирование в event loop — корутина помещается в очередь выполнения
• Выполнение до первого await — выполняется код до первого выражения await
• Приостановка и переключение — при встрече await корутина приостанавливается
• Возобновление выполнения — когда ожидаемая операция завершена
• Завершение — возврат результата или исключение

Пример детального выполнения:

async def complex_operation():
    print("Шаг 1: Начало")
    await asyncio.sleep(1)  # Приостановка здесь
    print("Шаг 2: После сна")
    result = await fetch_data()  # Еще одна приостановка
    print("Шаг 3: Получены данные")
    return result

Объявление асинхронных функций:

async def my_async_function():
    # Асинхронная функция (корутина)
    return "Результат"

Вызов асинхронных функций:

async def main():
    # Правильно: используем await
    result = await my_async_function()

# Неправильно: my_async_function() без await вернет корутину, а не результат
wrong_result = my_async_function()  # Это объект корутины!

Запуск асинхронного кода:

# Python 3.7+
asyncio.run(main())

# Старые версии Python
loop = asyncio.get_event_loop()
loop.run_until_complete(main())

13. Какими способами реализовать конкурентность без async/await и как на это влияет GIL? | Можно ли реализовать асинхронный подход без asyncio? #

Да, конкурентность можно реализовать без async/await.

Основные варианты:

Конкурентность без async/await
├── threading
├── concurrent.futures.ThreadPoolExecutor
├── multiprocessing / ProcessPoolExecutor
├── InterpreterPoolExecutor
├── selectors / select / epoll / kqueue
├── callback-based event loop
├── generators / yield-based scheduler
└── greenlet / gevent

asyncio — это не единственный способ писать конкурентный код. Это стандартная библиотека для асинхронного I/O с async/await, но сама идея конкурентности шире.

1. Потоки: threading #

Самый прямой способ без async/await — создать несколько потоков:

import threading
import requests

def load_url(url):
    response = requests.get(url)
    print(url, response.status_code)

threads = [
    threading.Thread(target=load_url, args=("https://example.com",)),
    threading.Thread(target=load_url, args=("https://python.org",)),
]

for thread in threads:
    thread.start()

for thread in threads:
    thread.join()

Потоки хорошо подходят для I/O-bound задач: сетевые запросы, работа с файлами, ожидание БД, API, Redis и т.д. Документация Python прямо указывает, что threading полезен для задач, где много ожидания внешних ресурсов.

Но для CPU-bound задач в обычном CPython потоки часто не дают настоящего параллельного выполнения Python-кода из-за GIL.

2. ThreadPoolExecutor #

Более удобный способ — не создавать потоки вручную, а использовать пул потоков:

from concurrent.futures import ThreadPoolExecutor, as_completed
import requests

def load_url(url):
    response = requests.get(url)
    return url, response.status_code

urls = [
    "https://example.com",
    "https://python.org",
    "https://docs.python.org",
]

with ThreadPoolExecutor(max_workers=3) as executor:
    futures = [executor.submit(load_url, url) for url in urls]

    for future in as_completed(futures):
        print(future.result())

Здесь нет async def, await, asyncio, но выполнение всё равно асинхронное в широком смысле: ты отправляешь задачи в пул и забираешь результат позже через Future. В документации concurrent.futures прямо сказано, что модуль предоставляет высокоуровневый интерфейс для асинхронного выполнения callable-объектов через потоки, интерпретаторы или процессы.

3. multiprocessing / ProcessPoolExecutor #

Для CPU-bound задач лучше использовать процессы:

from concurrent.futures import ProcessPoolExecutor

def heavy_calculation(n):
    total = 0
    for i in range(n):
        total += i * i
    return total

with ProcessPoolExecutor() as executor:
    results = executor.map(heavy_calculation, [10_000_000, 20_000_000, 30_000_000])

print(list(results))

Процессы обходят GIL, потому что каждый процесс имеет свой интерпретатор Python и свою память. Документация multiprocessing прямо говорит, что модуль обходит GIL за счёт subprocesses и позволяет использовать несколько процессоров.

Минусы процессов:

+ настоящая параллельность для CPU-bound
- дороже создание процесса
- данные нужно сериализовать
- память не общая, как у потоков
- обмен данными сложнее

4. InterpreterPoolExecutor #

В Python 3.14 появился InterpreterPoolExecutor: это пул потоков, но каждый worker работает в своём интерпретаторе. У каждого такого интерпретатора свой GIL, поэтому код может выполняться на разных CPU-ядрах параллельно.

Упрощённо:

ThreadPoolExecutor
├── один процесс
├── один интерпретатор
└── один GIL

InterpreterPoolExecutor
├── один процесс
├── несколько интерпретаторов
└── у каждого интерпретатора свой GIL

Но есть ограничение: интерпретаторы изолированы. Нельзя просто так разделять между ними изменяемые объекты. Данные нужно копировать, сериализовать или передавать через специальные механизмы.

5. selectors / select: свой event loop без asyncio #

Можно реализовать асинхронный подход вообще без asyncio, используя неблокирующие сокеты и selectors.

Идея:

1. Сокеты переводятся в non-blocking режим
2. selectors ждёт готовности сокета к чтению/записи
3. Когда сокет готов — вызывается обработчик
4. Один поток обслуживает много соединений

selectors — это высокоуровневая обёртка над select, poll, epoll, kqueue и другими механизмами ожидания I/O-событий. Документация рекомендует использовать selectors, если не нужен точный контроль над низкоуровневыми OS-примитивами.

Схематично:

import selectors
import socket

selector = selectors.DefaultSelector()

server = socket.socket()
server.bind(("localhost", 8000))
server.listen()
server.setblocking(False)

selector.register(server, selectors.EVENT_READ)

while True:
    events = selector.select()

    for key, mask in events:
        sock = key.fileobj

        if sock is server:
            conn, addr = server.accept()
            conn.setblocking(False)
            selector.register(conn, selectors.EVENT_READ)
        else:
            data = sock.recv(1024)
            if data:
                sock.sendall(data)
            else:
                selector.unregister(sock)
                sock.close()

Это уже асинхронный I/O-подход, но без asyncio и без async/await.

6. Генераторы и yield-based scheduler #

До появления современного async/await корутины в Python можно было строить через генераторы. yield приостанавливает выполнение функции и сохраняет её состояние, а потом выполнение можно продолжить.

Простейшая идея:

def task(name):
    for i in range(3):
        print(name, i)
        yield

tasks = [task("A"), task("B")]

while tasks:
    current = tasks.pop(0)

    try:
        next(current)
        tasks.append(current)
    except StopIteration:
        pass

Вывод будет чередоваться:

A 0
B 0
A 1
B 1
A 2
B 2

Это кооперативная конкурентность:

Задача сама отдаёт управление через yield.
Пока она не отдаст управление — другая задача не выполняется.

Так можно написать собственный мини-планировщик. Но для реального сетевого I/O нужно связать генераторы с selectors, таймерами, очередями событий и обработкой ошибок.

7. greenlet / gevent #

greenlet — это легковесные корутины для конкурентного программирования внутри процесса. Они похожи на кооперативные потоки: переключение происходит явно или через библиотеку, а не вытесняется ОС. ( Greenlet)

gevent строится поверх greenlet и даёт синхронный на вид API поверх event loop libev или libuv.

Примерно так:

import gevent
from gevent import monkey

monkey.patch_all()

import requests

def load_url(url):
    response = requests.get(url)
    print(url, response.status_code)

jobs = [
    gevent.spawn(load_url, "https://example.com"),
    gevent.spawn(load_url, "https://python.org"),
]

gevent.joinall(jobs)

Код выглядит синхронным, но I/O может выполняться конкурентно. Минус: если где-то используется блокирующий код, который не был “пропатчен” или не умеет отдавать управление, он может заблокировать весь поток.

Как на всё это влияет GIL #

GIL — это глобальная блокировка интерпретатора CPython. В обычной сборке CPython поток должен владеть GIL, чтобы работать с Python-объектами и выполнять Python C API.

Главное:

I/O-bound + threads
→ обычно нормально

CPU-bound + threads
→ плохо масштабируется из-за GIL

CPU-bound + processes
→ хорошо, потому что процессы обходят GIL

CPU-bound + C extensions
→ может быть хорошо, если расширение отпускает GIL

asyncio / selectors / gevent
→ GIL не основная проблема, потому что одна задача ждёт I/O, пока другая работает

Документация Python отдельно указывает, что GIL ограничивает выигрыш от threading для CPU-bound задач, потому что только один поток может выполнять Python bytecode одновременно.

При этом GIL освобождается вокруг блокирующих I/O-операций, например чтения или записи файла. Поэтому потоки всё равно полезны для сетевых запросов, файлов, БД и других операций ожидания.

Важный момент: GIL не отменяет race condition #

Иногда ошибочно думают:

Есть GIL → значит потоки безопасны

Это неверно.

GIL не делает твою бизнес-логику потокобезопасной. Интерпретатор может переключать потоки между bytecode-инструкциями, поэтому для общего изменяемого состояния всё равно нужны Lock, RLock, Queue, Condition, Semaphore и другие примитивы синхронизации. Документация Python прямо отмечает, что переключения между bytecode-инструкциями — причина, по которой lock-и всё равно нужны для thread-safety в pure-Python коде.

Пример проблемы:

counter = 0

def increment():
    global counter
    for _ in range(100_000):
        counter += 1

Операция counter += 1 не должна восприниматься как одна неделимая операция на уровне логики.

Можно ли реализовать async-подход без asyncio? #

Да.

Есть несколько вариантов:

1. concurrent.futures
   Асинхронно отправлять задачи в пул и получать Future.

2. selectors
   Написать свой event loop на неблокирующих сокетах.

3. callbacks
   Строить код вокруг функций-обработчиков событий.

4. generators
   Сделать кооперативный scheduler через yield.

5. greenlet/gevent
   Использовать greenlet-based конкурентность.

6. Trio / Curio / AnyIO
   Это async-библиотеки не на asyncio или не только на asyncio,
   но обычно они всё равно используют async/await.

То есть:

async/await — синтаксис языка
asyncio      — стандартная библиотека/event loop
асинхронность — общий подход
конкурентность — ещё более широкое понятие

asyncio — не единственный способ. В документации asyncio event loop описан как ядро asyncio-приложения, которое запускает async tasks, callbacks, сетевой I/O и subprocesses. Но подобный event loop можно построить и самостоятельно на selectors, либо использовать сторонний loop вроде gevent.

Практический выбор #

Много HTTP/API/БД запросов, код уже синхронный
→ ThreadPoolExecutor

CPU-bound вычисления
→ ProcessPoolExecutor / multiprocessing

Нужно много соединений в одном потоке
→ asyncio / selectors / gevent

Нужен низкоуровневый контроль
→ selectors

Нужно писать современный async-код
→ asyncio / Trio / AnyIO

Нужна настоящая параллельность внутри одного процесса на новых версиях Python
→ InterpreterPoolExecutor, но с учётом изоляции интерпретаторов

Итог:

Конкурентность без async/await — да.
Асинхронный подход без asyncio — да.
Настоящий параллелизм CPU-bound в обычных потоках CPython — обычно нет из-за GIL.
Для CPU-bound лучше процессы, отдельные интерпретаторы или free-threaded Python.

Начиная с Python 3.13, CPython поддерживает отдельную free-threaded сборку, где GIL отключён. Но это не обычный режим по умолчанию для большинства окружений, и часть C-расширений может быть не готова к такому режиму или повторно включать GIL.

14. Какие примитивы синхронизации используются в многопоточном программировании? #

Основные примитивы синхронизации #

В многопоточном программировании примитивы синхронизации нужны, чтобы несколько потоков безопасно работали с общими данными: не портили состояние, не читали данные в промежуточном состоянии и не выполняли критические участки одновременно.

В Python основные примитивы находятся в модуле threading: Lock, RLock, Condition, Semaphore, BoundedSemaphore, Event, Barrier. Часть из них можно использовать через with, чтобы гарантированно освобождать ресурс после выхода из блока.

1. Lock #

Lock — обычная блокировка, или mutex.

Используется, когда только один поток должен иметь доступ к критической секции.

import threading

counter = 0
lock = threading.Lock()

def increment():
    global counter

    for _ in range(100_000):
        with lock:
            counter += 1

Смысл:

Поток A вошёл в with lock
→ остальные потоки ждут
→ поток A вышел
→ lock освободился
→ другой поток может войти

Типичные случаи:

- изменение общего счётчика
- запись в общий список/словарь
- работа с общим файлом
- изменение общего состояния объекта

Важно: GIL не заменяет Lock. В CPython GIL ограничивает одновременное выполнение Python bytecode, но не делает бизнес-операции потокобезопасными. Документация threading прямо указывает, что из-за GIL только один поток может выполнять Python-код одновременно, но для корректной синхронизации общего состояния всё равно нужны примитивы синхронизации.

2. RLock #

RLock — reentrant lock, то есть повторно-входимая блокировка.

Обычный Lock нельзя захватить повторно из того же потока. RLock — можно.

import threading

lock = threading.RLock()

def outer():
    with lock:
        inner()

def inner():
    with lock:
        print("inner")

С обычным Lock такой код мог бы зависнуть:

outer() захватил lock
→ вызвал inner()
→ inner() снова пытается захватить тот же lock
→ поток ждёт сам себя

RLock полезен, когда несколько методов одного объекта используют одну и ту же блокировку и могут вызывать друг друга.

3. Semaphore #

Semaphore ограничивает количество потоков, которые одновременно могут пройти в участок кода.

Например, максимум 3 потока могут одновременно обращаться к внешнему API:

import threading
import time

semaphore = threading.Semaphore(3)

def request_api(user_id):
    with semaphore:
        print(f"start {user_id}")
        time.sleep(1)
        print(f"end {user_id}")

Смысл:

Lock       → пускает 1 поток
Semaphore  → пускает N потоков

Типичные случаи:

- ограничить количество одновременных запросов
- ограничить доступ к пулу соединений
- ограничить работу с тяжёлым ресурсом

4. BoundedSemaphore #

BoundedSemaphore похож на Semaphore, но дополнительно защищает от ошибки лишнего release().

Обычный Semaphore можно случайно “освободить” больше раз, чем захватили. BoundedSemaphore обнаруживает такую ошибку.

import threading

sem = threading.BoundedSemaphore(2)

sem.acquire()
sem.release()

# sem.release()  # ошибка: release больше, чем acquire

Используется там, где важно не превысить исходный лимит ресурса.

5. Event #

Event — флаг-сигнал между потоками.

Один поток может ждать события, другой — установить его.

import threading
import time

event = threading.Event()

def worker():
    print("worker ждёт сигнал")
    event.wait()
    print("worker начал работу")

thread = threading.Thread(target=worker)
thread.start()

time.sleep(2)
event.set()

Смысл:

event.clear() → события нет
event.wait()  → поток ждёт
event.set()   → событие произошло, ожидающие потоки продолжают работу

Типичные случаи:

- сигнал завершения
- сигнал старта
- ожидание готовности ресурса
- остановка фонового потока

Пример остановки фонового потока:

import threading
import time

stop_event = threading.Event()

def worker():
    while not stop_event.is_set():
        print("working")
        time.sleep(1)

thread = threading.Thread(target=worker)
thread.start()

time.sleep(3)
stop_event.set()
thread.join()

6. Condition #

Condition используется, когда поток должен ждать не просто lock, а конкретное условие.

Например:

consumer ждёт, пока появятся данные
producer добавляет данные
producer уведомляет consumer

Пример:

import threading

condition = threading.Condition()
items = []

def producer():
    with condition:
        items.append("data")
        condition.notify()

def consumer():
    with condition:
        while not items:
            condition.wait()

        item = items.pop()
        print(item)

Важный момент:

while not items:
    condition.wait()

Обычно используют именно while, а не if, потому что поток после пробуждения должен заново проверить условие.

Condition часто лежит внутри более высокоуровневых структур, например очередей.

7. Barrier #

Barrier заставляет несколько потоков дождаться друг друга в одной точке.

import threading
import time

barrier = threading.Barrier(3)

def worker(name):
    print(f"{name}: подготовка")
    time.sleep(1)
    print(f"{name}: ждёт остальных")
    barrier.wait()
    print(f"{name}: продолжает работу")

for i in range(3):
    threading.Thread(target=worker, args=(f"thread-{i}",)).start()

Смысл:

Поток 1 дошёл до barrier.wait() → ждёт
Поток 2 дошёл до barrier.wait() → ждёт
Поток 3 дошёл до barrier.wait() → все продолжают

Типичные случаи:

- синхронный старт нескольких потоков
- этапная обработка данных
- тестирование конкурентного кода

8. Queue #

queue.Queue — потокобезопасная очередь.

Это один из самых практичных способов обмена данными между потоками. Модуль queue реализует очереди для схемы multi-producer / multi-consumer и уже содержит нужную locking-семантику.

Пример producer-consumer:

import queue
import threading

q = queue.Queue()

def producer():
    for i in range(5):
        q.put(i)

def consumer():
    while True:
        item = q.get()

        try:
            print("process", item)
        finally:
            q.task_done()

threading.Thread(target=producer).start()
threading.Thread(target=consumer, daemon=True).start()

q.join()

Смысл:

producer кладёт задачи в очередь
consumer забирает задачи из очереди
Queue сама синхронизирует доступ между потоками

Варианты:

queue.Queue         → FIFO
queue.LifoQueue     → LIFO, как стек
queue.PriorityQueue → очередь с приоритетом
queue.SimpleQueue   → простая неограниченная очередь

9. Future #

Future — не совсем низкоуровневый примитив синхронизации, но часто используется в многопоточном коде.

Он представляет результат задачи, который появится позже.

from concurrent.futures import ThreadPoolExecutor

def calculate():
    return 10 + 20

with ThreadPoolExecutor() as executor:
    future = executor.submit(calculate)

    result = future.result()
    print(result)

future.result() блокирует текущий поток до завершения задачи.

Модуль concurrent.futures предоставляет высокоуровневый интерфейс для асинхронного выполнения функций через потоки, процессы или отдельные интерпретаторы.

Что использовать чаще всего #

На практике чаще всего нужны:

Lock
→ защитить общий mutable state

RLock
→ если один и тот же поток может повторно входить в защищённый код

Semaphore
→ ограничить количество одновременных операций

Event
→ дать сигнал потоку

Condition
→ ждать конкретного состояния

Barrier
→ дождаться группы потоков

Queue
→ безопасно передавать задачи/данные между потоками

Краткая таблица #

Главное #

GIL ≠ синхронизация бизнес-логики

Даже в CPython с GIL нужно использовать Lock, Queue, Event, Condition и другие примитивы, если несколько потоков работают с общим изменяемым состоянием. Самый безопасный подход — минимизировать общее состояние и передавать данные между потоками через queue.Queue.

15. Какая стандартная библиотека отвечает за асинхронность (async/await) и событийный цикл? #

Стандартная библиотека — asyncio #

За асинхронность в стиле async/await и событийный цикл в Python отвечает стандартный модуль:

import asyncio

asyncio предоставляет инфраструктуру для:

- корутин
- задач Task
- Future
- event loop
- неблокирующего сетевого I/O
- таймеров
- async-примитивов синхронизации
- запуска subprocess

Официальная документация описывает asyncio как библиотеку для написания конкурентного кода с помощью синтаксиса async/await. Также в ней есть низкоуровневые API для создания и управления event loop.

Минимальный пример #

import asyncio

async def main():
    print("start")
    await asyncio.sleep(1)
    print("end")

asyncio.run(main())

Что здесь происходит:

async def main()
→ создаёт coroutine function

main()
→ создаёт coroutine object

asyncio.run(main())
→ создаёт event loop
→ запускает корутину
→ закрывает event loop после завершения

asyncio.run() — основной высокоуровневый способ запустить async-программу. В документации указано, что он создаёт event loop, запускает корутину и закрывает цикл после выполнения.

Важно разделять #

async/await
→ синтаксис языка Python

asyncio
→ стандартная библиотека для работы с этим синтаксисом

event loop
→ механизм, который планирует и выполняет async-задачи

Сам async def — это часть синтаксиса Python. Функции, объявленные через async def, всегда являются coroutine functions.

А asyncio — библиотека, которая умеет эти корутины запускать, планировать, превращать в Task, ждать Future, обслуживать сетевой I/O и управлять событийным циклом.

16. Какие ключевые особенности asyncio как модели конкурентности (event loop, корутины, задачи)? #

asyncio как модель конкурентности #

asyncio — это модель кооперативной конкурентности: несколько задач могут продвигаться “как будто одновременно”, но в рамках одного event loop в один момент времени выполняется только одна задача Python-кода. Переключение происходит не принудительно, как у потоков ОС, а в местах, где корутина сама отдаёт управление через await. Официальная документация описывает asyncio как библиотеку для конкурентного кода с использованием async/await.

asyncio
├── event loop
├── coroutine
├── Task
├── Future
├── await
└── неблокирующий I/O

1. Event loop #

event loop — центральный механизм asyncio.

Он:

- запускает корутины
- планирует задачи
- выполняет callbacks
- следит за сетевым I/O
- обрабатывает таймеры
- запускает subprocess
- возобновляет задачи, когда их ожидание завершилось

Документация прямо называет event loop ядром каждого asyncio-приложения: он выполняет асинхронные задачи и callbacks, сетевые операции и subprocesses.

Упрощённо:

event loop
→ взял готовую задачу
→ выполняет её до await
→ задача ждёт I/O/таймер/Future
→ event loop переключается на другую готовую задачу
→ когда ожидание завершилось, задача продолжается

Пример:

import asyncio

async def main():
    print("start")
    await asyncio.sleep(1)
    print("end")

asyncio.run(main())

asyncio.run() запускает awaitable-объект в event loop, управляет циклом, финализирует async generators и закрывает executor после завершения.

2. Корутины #

Корутина — это функция, объявленная через async def.

async def fetch_data():
    await asyncio.sleep(1)
    return "data"

Важный момент:

coro = fetch_data()

Этот вызов не запускает код функции сразу. Он создаёт coroutine object. Чтобы корутина начала выполняться, её нужно либо await-нуть, либо обернуть в Task.

async def main():
    result = await fetch_data()
    print(result)

await означает:

эта корутина сейчас ждёт результат
event loop может пока выполнить другие задачи
потом выполнение этой корутины продолжится

То есть await — это точка добровольного переключения.

3. Task #

Task — это запланированная корутина.

Просто создать coroutine object недостаточно:

coro = fetch_data()

А вот так корутина планируется на выполнение:

task = asyncio.create_task(fetch_data())

Документация указывает, что Task используется для конкурентного планирования корутин; когда корутина оборачивается в Task через asyncio.create_task(), она автоматически планируется для выполнения.

Пример:

import asyncio

async def load(name, delay):
    print(f"{name}: start")
    await asyncio.sleep(delay)
    print(f"{name}: end")
    return name

async def main():
    task1 = asyncio.create_task(load("A", 2))
    task2 = asyncio.create_task(load("B", 1))

    result1 = await task1
    result2 = await task2

    print(result1, result2)

asyncio.run(main())

Здесь A и B выполняются конкурентно:

A стартует
B стартует
B заканчивает ожидание раньше
A заканчивает позже

Но это не значит, что Python-код A и B выполнялся параллельно на разных ядрах. Они по очереди выполнялись в одном event loop.

4. Future #

Future — низкоуровневый объект, который представляет результат, который появится позже.

Future
├── пока результата нет
├── потом будет result
├── или exception
└── или cancellation

Документация описывает asyncio.Future как awaitable-объект, представляющий eventual result асинхронной операции. Корутины могут ждать Future до появления результата, исключения или отмены.

Обычно напрямую Future в пользовательском коде создают редко. Чаще ты работаешь с корутинами и Task, а Future остаётся внутри библиотек, event loop и низкоуровневого I/O.

5. Кооперативное переключение #

Главная особенность asyncio — задачи переключаются только в точках ожидания.

Например:

async def good():
    await asyncio.sleep(1)

Здесь задача отдаёт управление event loop.

А вот так плохо:

async def bad():
    while True:
        pass

Эта корутина не содержит await, поэтому она заблокирует event loop.

Правильная модель мышления:

asyncio не прерывает задачу насильно
задача должна сама дойти до await
только тогда event loop сможет выполнить что-то другое

6. Неблокирующий I/O #

asyncio особенно полезен для I/O-bound задач:

- HTTP-запросы
- WebSocket
- работа с БД через async-драйвер
- сетевые серверы
- ожидание таймеров
- большое количество соединений

Смысл:

пока одна задача ждёт ответ от сети
event loop выполняет другую задачу

Это отличается от синхронного кода:

time.sleep(1)

time.sleep() блокирует поток.

А это не блокирует event loop:

await asyncio.sleep(1)

7. asyncio — не про CPU-bound параллелизм #

asyncio хорошо работает, когда задачи часто ждут I/O.

Но если задача активно грузит CPU:

async def cpu_bound():
    total = 0
    for i in range(100_000_000):
        total += i
    return total

Она будет занимать event loop и мешать другим задачам.

Для CPU-bound задач обычно используют:

- multiprocessing
- ProcessPoolExecutor
- run_in_executor
- asyncio.to_thread для выноса блокирующей функции в поток

Но сам asyncio не превращает CPU-bound код в параллельный код.

8. Один event loop — обычно один поток #

Обычно event loop работает в одном потоке.

один event loop
→ один поток
→ много задач
→ переключение через await

Поэтому в рамках одного loop не нужно думать о race condition так же, как в многопоточном коде, но проблемы общего состояния всё равно возможны, если несколько корутин изменяют одни и те же данные между await.

Пример потенциальной проблемы:

counter = 0

async def increment():
    global counter

    value = counter
    await asyncio.sleep(0)
    counter = value + 1

Здесь между чтением и записью есть await, значит другая корутина может вмешаться.

Для таких случаев есть async-примитивы:

lock = asyncio.Lock()

async with lock:
    # критическая секция
    ...

9. Task cancellation #

Задачи в asyncio можно отменять.

task = asyncio.create_task(fetch_data())
task.cancel()

Отмена обычно приводит к выбрасыванию asyncio.CancelledError внутри корутины. Это важно для таймаутов, graceful shutdown и отмены долгих операций.

Типичный шаблон:

async def worker():
    try:
        while True:
            await asyncio.sleep(1)
    except asyncio.CancelledError:
        # очистка ресурсов
        raise

10. asyncio.gather() и конкурентный запуск #

Для запуска нескольких awaitable-объектов часто используют asyncio.gather():

import asyncio

async def load_user():
    await asyncio.sleep(1)
    return "user"

async def load_orders():
    await asyncio.sleep(1)
    return "orders"

async def main():
    user, orders = await asyncio.gather(
        load_user(),
        load_orders(),
    )

    print(user, orders)

asyncio.run(main())

Без конкурентности это заняло бы примерно 2 секунды:

load_user    → 1 секунда
load_orders  → 1 секунда
итого        → 2 секунды

С gather() обе операции ожидания идут конкурентно:

load_user и load_orders ждут одновременно
итого примерно 1 секунда

Главная схема #

async def
→ создаёт корутинную функцию

coroutine object
→ результат вызова async-функции

Task
→ корутина, запланированная в event loop

await
→ точка ожидания и передачи управления event loop

event loop
→ планировщик, который переключает задачи

Future
→ объект будущего результата

Главное отличие от потоков #

threading
→ переключение контролирует ОС
→ вытесняющая многозадачность
→ возможны параллельные потоки, но в CPython мешает GIL

asyncio
→ переключение происходит через await
→ кооперативная многозадачность
→ один event loop обычно выполняет одну задачу Python-кода за раз

Итог:

asyncio — это модель конкурентности для I/O-bound задач.

event loop — планировщик.
coroutine — приостанавливаемая функция.
Task — корутина, поставленная на выполнение.
await — точка, где задача отдаёт управление.
Future — низкоуровневый контейнер будущего результата.

Использовать asyncio целесообразно, когда программа много ждёт внешние ресурсы и нужно эффективно обслуживать много таких ожиданий в одном потоке.

17. В какие моменты event loop переключается между задачами в асинхронном выполнении? #

Когда event loop переключается между задачами #

В asyncio переключение задач происходит не принудительно, а кооперативно: задача сама отдаёт управление event loop, обычно на await. Event loop в один момент выполняет только одну задачу; пока одна задача ждёт завершения Future/I/O/таймера, loop может выполнять другую задачу.

Главные моменты переключения:

1. На await, если ожидаемый объект ещё не готов #

Например:

async def task_1():
    print("A")
    await some_io()
    print("B")

Когда выполнение доходит до:

await some_io()

если some_io() ещё не завершился, текущая задача приостанавливается, а event loop берёт другую готовую задачу.

Схематично:

task_1 выполняется
↓
доходит до await some_io()
↓
some_io ещё не готов
↓
task_1 приостанавливается
↓
event loop запускает другую готовую task

2. На await asyncio.sleep(...) #

asyncio.sleep() всегда приостанавливает текущую задачу и даёт возможность выполниться другим задачам. Даже await asyncio.sleep(0) используется как явная добровольная передача управления event loop.

import asyncio

async def worker(name):
    for i in range(3):
        print(name, i)
        await asyncio.sleep(0)

asyncio.run(asyncio.gather(
    worker("A"),
    worker("B"),
))

Логика:

A 0
await sleep(0) → отдал управление
B 0
await sleep(0) → отдал управление
A 1
...

3. Когда задача ждёт сетевой ввод/вывод #

Типичный пример:

data = await reader.read(1024)

Пока данные из сокета не пришли, задача не занимает поток выполнения. Event loop следит за готовностью I/O и в это время выполняет другие задачи. asyncio как раз хорошо подходит для I/O-bound задач и сетевого кода.

4. Когда задача ждёт другую задачу #

result = await other_task

Если other_task ещё не завершилась, текущая задача приостанавливается.

task_1 ждёт task_2
↓
task_1 suspended
↓
event loop выполняет task_2 или другие готовые задачи
↓
task_2 завершилась
↓
task_1 продолжает выполнение

5. Когда задача ждёт Future #

Внутри asyncio многие операции сводятся к ожиданию Future.

result = await future

Если future ещё не готов, задача отдаёт управление. Когда future получает результат или исключение, event loop снова ставит задачу в очередь готовых к продолжению.

Важный момент: обычный код не переключается #

Вот здесь переключения не будет:

async def bad_task():
    while True:
        pass

Несмотря на async def, внутри нет await. Такая задача заблокирует event loop.

То же самое с тяжёлым CPU-кодом:

async def cpu_task():
    for i in range(10**9):
        ...

Пока код не дойдёт до await, event loop не сможет переключиться на другие задачи.

Правильная короткая формулировка #

Event loop переключается между задачами только в точках ожидания, когда текущая coroutine делает await и ожидаемый объект не готов: I/O, sleep, Future, другая Task, блокировка asyncio.Lock, очередь asyncio.Queue и т.д.