Перейти на PRO

Когда потоки могут быть быстрее asyncio для I/O-bound задач

Тип вопроса: Асинхронность Вероятность: 10% Категория: Python Разработчик

Ответ

Да, существуют ситуации, когда многопоточный подход может оказаться производительнее asyncio для I/O-bound задач.

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

Ключевые сценарии, где потоки выигрывают:

  1. Интеграция с блокирующим кодом: Если ваше приложение должно работать с библиотекой (например, старый драйвер БД или SDK), которая выполняет блокирующие сетевые или дисковые операции, запуск этих операций в отдельном потоке — единственный способ не блокировать event loop.

  2. GIL и I/O: Во время выполнения блокирующей I/O операции (например, requests.get()) Python освобождает Global Interpreter Lock (GIL). Это позволяет другим потокам выполняться, обеспечивая реальный параллелизм для I/O-задач.

  3. Простота для небольших скриптов: Иногда для простого скрипта, делающего несколько десятков запросов, проще и быстрее написать код с использованием ThreadPoolExecutor, чем перестраивать его под async/await синтаксис.

Практический пример: интеграция блокирующего вызова в asyncio

Современный подход — не выбирать между потоками и asyncio, а совмещать их. Блокирующий код выполняется в пуле потоков, не мешая основному циклу событий.

import asyncio
import requests
import time

def blocking_io_call(url):
    # Эта функция блокирует поток на время запроса
    print(f"Начинаю блокирующий запрос к {url}...")
    response = requests.get(url)
    print(f"Запрос к {url} завершен со статусом {response.status_code}")
    return response.status_code

async def main():
    loop = asyncio.get_running_loop()
    urls = ["https://google.com", "https://github.com"]
    start_time = time.time()

    # Запускаем блокирующие вызовы в отдельных потоках через executor
    # В Python 3.9+ можно использовать asyncio.to_thread()
    tasks = [
        loop.run_in_executor(None, blocking_io_call, url) 
        for url in urls
    ]

    results = await asyncio.gather(*tasks)
    print(f"Все запросы выполнены за {time.time() - start_time:.2f} секунд.")
    print(f"Результаты: {results}")

asyncio.run(main())

Вывод: asyncio предпочтителен для построения высоконагруженных систем с нативной асинхронной поддержкой. Потоки остаются незаменимым инструментом для работы с блокирующим I/O и могут быть эффективнее в специфических сценариях.

Ответ 18+ 🔞

Ага, вот это поворот, блядь! Ты думал, что asyncio — это панацея от всех I/O-проблем, как хуй с горы? А оказывается, бывают случаи, когда старые добрые потоки могут его нагнуть, и вот почему.

Основная причина — блокирующие библиотеки, у которых нет асинхронных аналогов. Если ты сунешь такую штуку в свой красивый event loop, он встанет колом, как будто ему в рот чих-пых, и все твои корутины просто застынут в ожидании. Пиздец и точка.

Когда потоки выручат твою задницу:

  1. Интеграция с легаси-кодом: Представь, что тебе надо работать со старой библиотекой для БД или каким-то SDK, который делает блокирующие сетевые вызовы. Тут вариантов нет — либо ты запускаешь эту хрень в отдельном потоке, либо твой event loop превращается в тыкву. Асинхронность тут не поможет, если под капотом всё равно блокировка.

  2. GIL и I/O — странная дружба: Когда поток выполняет блокирующую I/O операцию (типа requests.get()), Python отпускает этот самый Global Interpreter Lock (GIL). И это магия, ёпта! Другие потоки в этот момент могут работать, получая реальный параллелизм для I/O-задач. Не идеально, но работает.

  3. Простота для мелких задач: Если тебе надо на коленке накидать скрипт, который делает пару десятков запросов, то заморачиваться с async/await — это как из пушки по воробьям. Проще взять ThreadPoolExecutor и сделать всё за пять минут, без всей этой асинхронной мишуры.

Практический пример: как запихнуть блокирующий вызов в asyncio и не сойти с ума

Современный подход — не выбирать между потоками и asyncio, а грамотно их скрестить. Блокирующий код выполняется в пуле потоков, а основной цикл событий продолжает жить своей жизнью.

import asyncio
import requests
import time

def blocking_io_call(url):
    # Эта функция блокирует поток на время запроса
    print(f"Начинаю блокирующий запрос к {url}...")
    response = requests.get(url)
    print(f"Запрос к {url} завершен со статусом {response.status_code}")
    return response.status_code

async def main():
    loop = asyncio.get_running_loop()
    urls = ["https://google.com", "https://github.com"]
    start_time = time.time()

    # Запускаем блокирующие вызовы в отдельных потоках через executor
    # В Python 3.9+ можно использовать asyncio.to_thread()
    tasks = [
        loop.run_in_executor(None, blocking_io_call, url) 
        for url in urls
    ]

    results = await asyncio.gather(*tasks)
    print(f"Все запросы выполнены за {time.time() - start_time:.2f} секунд.")
    print(f"Результаты: {results}")

asyncio.run(main())

Итог, ёпта: asyncio — это овердохуища для высоконагруженных систем, где всё из коробки асинхронное. Но потоки — это как старый, проверенный лом: иногда только им можно вскрыть тот самый замок. Они остаются незаменимыми для работы с блокирующим I/O и в некоторых сценариях могут быть даже эффективнее.

© ХакСобесов, 2026
support@hacksobesov.com