9. A Concorrência em Swift Delega a Gerenciamento de Threads ao Runtime
GCD oferece filas, mas os threads ainda são uma preocupação de fundo que eventualmente você terá que pensar sobre — uma fila concorrente cheia de trabalho bloqueante pode fazer com que o GCD crie mais e mais threads para continuar fazendo progresso, exatamente como você acaba com o problema clássico de “explosão de threads”.
A abordagem do runtime da Concorrência em Swift é diferente: uma pool cooperativa de threads, dimensionada aproximadamente ao número de núcleos de CPU no dispositivo, está por trás de cada Task, async let e ator por padrão. Você não cria threads e você não escolhe qual roda seu código — o runtime agendará tarefas nesta pool fixa, e o modelo de concorrência estruturada do Swift é construído na garantia de que uma tarefa em execução sempre pode fazer progresso em vez de ficar presa esperando e bloqueando um thread que GCD teria reutilizado. Isso é grande parte da razão pela qual a Concorrência em Swift evita o mesmo modo de falha de “explosão de threads” que as filas totalmente concorrentes do GCD podem entrar sob carga pesada.
É chamado cooperativo porque acontece em cada await: a tarefa suspende ali em vez de bloquear, o que libera imediatamente seu thread de trabalho e a pool pode passar esse thread para outra tarefa pronta para rodar — nenhum thread fica lá bloqueado, esperando por trabalho assíncrono.
Tarefas Não Estão Ligadas a Threads
Uma consequência desse modelo: uma Task não está permanentemente ligada a um único thread. Ela pode começar em um thread, atingir um await, e retomar em um completamente diferente thread assim que o trabalho aguardado estiver concluído — e isso é esperado, não um bug:
Task {
print(Thread.current) // por exemplo. <Thread: 0x600001234000>
await fetchUser()
print(Thread.current) // poderia facilmente ser um thread diferente
}Tenha isso como uma ilustração conceitual em vez de um snippet para rodar e verificar — Thread.current não faz parte do modelo da Concorrência em Swift, e dependendo da carga de trabalho, o runtime pode reutilizar o mesmo thread de qualquer maneira. O ponto não é que ele está garantido a mudar; é que seu código não pode assumir que isso não vai acontecer.
Isso é exatamente por que a mudança no modelo mental da Seção 6 importa: com GCD você poderia ao menos pensar vagamente sobre “em qual fila estou”, mas com a Concorrência em Swift, perguntar “em qual thread meu código está rodando” não é realmente a pergunta certa. A unidade para pensar em termos de é o Task, não o thread por baixo — o runtime é livre para mover a continuação de uma tarefa suspensa para qualquer thread na pool cooperativa disponível.
A lição prática sobre como você escreve código no dia a dia: com GCD, você pensa em filas e eventualmente tem que pensar em threads. Com a Concorrência em Swift, você pensa em tarefas e atores, e o gerenciamento de threads é problema do runtime, não seu.