Async ou threads: como escolher

Async e threads lado a lado

Depois de dois módulos, a pergunta natural é: quando usar cada um? Comece pelo que os une. Async e threads atacam o mesmo problema, o I/O bound, aquele em que o programa espera muito por rede, disco ou banco. E os dois compartilham a mesma limitação: rodam efetivamente em um thread de trabalho no que toca ao Python, então nenhum quebra o GIL para acelerar cálculo. Para CPU bound, a resposta dos dois módulos é a mesma, processos. A escolha entre async e threads, portanto, só se coloca dentro do território do I/O, e aí entram as diferenças de escala e de estilo.

O perigo de bloquear o loop

Há uma armadilha que derruba quem começa com async: misturar código bloqueante dentro de uma corrotina. O modelo assíncrono só funciona porque cada tarefa cede o controle nos pontos de await. Se você chama, dentro de uma corrotina, uma operação que não cede o controle, como o time.sleep comum, uma leitura síncrona de arquivo ou uma chamada de rede de uma biblioteca bloqueante, o event loop fica preso naquela chamada. Durante todo esse tempo, nenhuma outra corrotina avança, mesmo que a espera delas já tivesse terminado. O async vira um código sequencial disfarçado, e você perde justamente o que foi buscar.

import asyncio
import time

async def certo(nome):
    await asyncio.sleep(1)     # cede o loop: outras corrotinas avancam
    return nome

async def errado(nome):
    time.sleep(1)              # BLOQUEIA o loop: tudo para durante 1s
    return nome

async def main():
    # com 'certo', gather termina em ~1s; com 'errado', em ~3s
    inicio = time.perf_counter()
    await asyncio.gather(certo("A"), certo("B"), certo("C"))
    print(f"certo: {time.perf_counter() - inicio:.1f}s")

asyncio.run(main())

asyncio.sleep cede o loop; time.sleep dentro de async bloqueia tudo e mata a concorrência.

Fechando o raciocínio de concorrência

Junte tudo e o mapa de decisão fica claro. Primeiro pergunte se a tarefa é I/O bound ou CPU bound. Se for CPU bound, cálculo pesado, nem async nem threads ajudam; use processos, com o ProcessPoolExecutor do módulo anterior. Se for I/O bound, você está no território de async e threads. Aí a segunda pergunta é sobre escala e código: para muitas conexões, servidores de rede e projetos novos com bibliotecas assíncronas, prefira async, que escala melhor e tem modelo previsível. Para encaixar concorrência em código já existente, com bibliotecas bloqueantes comuns e um volume moderado de tarefas, threads costumam ser o caminho mais simples.

Uma última recomendação, no espírito do curso: meça antes de escolher. Concorrência acrescenta complexidade, e nem todo programa precisa dela. Se uma tarefa roda rápido o bastante em código comum, deixe simples. Quando o volume de I/O crescer e o tempo de espera pesar, aí sim vale trazer async ou threads, guiado por medição, não por palpite. Com este módulo, você fecha a frente de concorrência do curso e segue para a orientação a objetos avançada, onde o foco volta ao projeto das suas próprias estruturas.