Armadilhas do async/await em C#: sync-over-async, async void e ConfigureAwait

O que é

await sobre uma Task ainda incompleta captura o SynchronizationContext atual (ou o TaskScheduler) e retoma o restante do método nesse contexto. O artigo de boas práticas de Stephen Cleary na MSDN Magazine explica a consequência: se um contexto de UI ou do ASP.NET clássico, que executa um trecho de código de cada vez, estiver bloqueado em Task.Wait() ou .Result à espera desse mesmo método, a continuação nunca consegue executar e o programa entra em deadlock. Uma aplicação de console não sofre deadlock porque, nas palavras do artigo, o seu contexto agenda a continuação no thread pool. ConfigureAwait(false) instrui o awaiter a não retomar no contexto capturado. Métodos async void não têm uma Task para transportar a exceção; por isso, uma exceção lançada vai diretamente para o contexto e não pode ser capturada por quem chamou. O artigo reserva async void para manipuladores de eventos.

Por que importa

O ASP.NET Core não publica nenhum SynchronizationContext, o que, segundo o FAQ do ConfigureAwait, reduz a necessidade de ConfigureAwait(false) nesse ambiente. Ainda assim, o sync-over-async continua a prejudicar os servidores: uma thread do thread pool bloqueada fica indisponível, e o tutorial de diagnóstico do .NET descreve o esgotamento do thread pool (thread-pool starvation) como a situação em que o pool adiciona threads lentamente, o trabalho se acumula na fila e a CPU permanece baixa. Tanto engenheiros vindos do JavaScript, onde bloquear numa promise é impossível, como do Go, onde bloquear é barato, avaliam mal esse custo.

Como aplicar

• Async de ponta a ponta: assim que um método usa await, os seus chamadores passam a ser async Task, até ao ponto de entrada (ação de controller, Main, handler). Não envolva uma chamada assíncrona num método síncrono com .Result.
• Retorne Task ou Task<T> em vez de void; mantenha async void apenas para manipuladores de eventos, e faça-os aguardar (await) um método que retorna Task e contém a lógica.
• Em código de biblioteca, use ConfigureAwait(false) em todos os awaits; em código de aplicação (controllers, handlers de UI, métodos de teste), mantenha o comportamento padrão. O FAQ afirma exatamente essa divisão.
• Use Task.Run para trabalho limitado pela CPU que você quer tirar da thread chamadora, não para I/O; a documentação de cenários assíncronos distingue os dois casos.
• Aguarde (await) toda tarefa que iniciar; uma Task descartada esconde a sua exceção. Propague um CancellationToken por todas as assinaturas assíncronas.

Armadilhas

Task.Wait e .Result encapsulam as exceções em AggregateException, ao passo que await relança diretamente a primeira exceção, como mostra o artigo da MSDN. ConfigureAwait(false) não resolve um deadlock se algum await da cadeia não o tiver, e o FAQ avisa que um contexto personalizado ainda pode aparecer mesmo no ASP.NET Core. Uma lambda async passada onde se espera uma Action torna-se async void. No .NET 9, o evento de rastreamento WaitHandleWait sinaliza esperas sync-over-async, conforme descreve o tutorial sobre starvation.