{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Quel est le rôle principal du mot-clé 'await' dans une méthode asynchrone ?","acceptedAnswer":{"@type":"Answer","text":"Le mot-clé await suspend l'exécution de la méthode asynchrone jusqu'à ce que la Task soit terminée, tout en libérant le thread appelant pour qu'il puisse traiter d'autres tâches. Cela permet d'éviter le blocage du thread et d'améliorer la scalabilité de l'application. Contrairement à Task.Wait() ou Task.Result qui bloquent le thread, await permet une utilisation efficace des ressources thread pool."}},{"@type":"Question","name":"Pourquoi faut-il éviter d'utiliser async void sauf pour les gestionnaires d'événements ?","acceptedAnswer":{"@type":"Answer","text":"Les méthodes async void ne peuvent pas être attendues (await) et les exceptions levées à l'intérieur ne peuvent pas être capturées par le code appelant, provoquant un crash de l'application. De plus, il est impossible de tester unitairement une méthode async void car il n'y a pas de Task à attendre. Les gestionnaires d'événements sont l'exception car ils sont appelés par le framework et ne peuvent pas retourner Task."}},{"@type":"Question","name":"Dans quel cas d'usage privilégier ValueTask plutôt que Task ?","acceptedAnswer":{"@type":"Answer","text":"ValueTask est un value type qui évite l'allocation heap lorsque le résultat est déjà disponible de manière synchrone, comme dans un cache. Cela réduit la pression sur le garbage collector dans les scénarios haute performance. Task est toujours alloué sur le heap même si le résultat est synchrone. Utiliser ValueTask uniquement quand les gains de performance sont mesurables, car son usage incorrect peut dégrader les performances."}},{"@type":"Question","name":"Quelle restriction importante s'applique à ValueTask comparé à Task ?","acceptedAnswer":{"@type":"Answer","text":"ValueTask ne doit être awaité qu'une seule fois car il peut être basé sur un objet poolé qui sera recyclé après utilisation. Awaiter plusieurs fois peut causer des bugs subtils. Task peut être awaité de manière illimitée car c'est un objet heap immutable. Si plusieurs awaits sont nécessaires, convertir ValueTask en Task avec AsTask(). Cette restriction rend ValueTask inadapté pour certains scénarios comme le caching de tasks."}},{"@type":"Question","name":"Quel est l'objectif principal de ConfigureAwait(false) dans une bibliothèque .NET ?","acceptedAnswer":{"@type":"Answer","text":"ConfigureAwait(false) évite de capturer et de restaurer le SynchronizationContext d'origine après un await, ce qui améliore les performances et évite les deadlocks dans les bibliothèques. Dans ASP.NET Core, il n'y a pas de SynchronizationContext donc l'impact est minimal, mais dans WinForms/WPF ou ASP.NET Framework, cela évite de retourner sur le thread UI ou le contexte HTTP. Les bibliothèques doivent toujours utiliser ConfigureAwait(false) pour éviter les coûts inutiles."}},{"@type":"Question","name":"Pourquoi ConfigureAwait(false) est-il moins critique dans ASP.NET Core comparé à ASP.NET Framework ?","acceptedAnswer":{"@type":"Answer","text":"ASP.NET Core n'utilise pas de SynchronizationContext par défaut, donc la continuation s'exécute déjà sur un thread pool arbitraire. ConfigureAwait(false) a donc un impact négligeable sur les performances. Dans ASP.NET Framework, il y a un SynchronizationContext qui capture le contexte HTTP, ce qui peut causer des deadlocks si une méthode async bloque avec Wait() ou Result. Néanmoins, les bibliothèques devraient toujours utiliser ConfigureAwait(false) pour rester compatibles avec tous les contextes."}},{"@type":"Question","name":"Quelle est la meilleure pratique pour propager un CancellationToken dans une méthode asynchrone ?","acceptedAnswer":{"@type":"Answer","text":"Le CancellationToken doit être passé comme dernier paramètre de méthode et propagé à tous les appels asynchrones internes. Cela permet une annulation coopérative en cascade. Ne jamais créer un nouveau CancellationTokenSource sauf pour créer un timeout lié. Vérifier régulièrement ThrowIfCancellationRequested() dans les boucles longues. Les API ASP.NET Core passent automatiquement HttpContext.RequestAborted comme CancellationToken."}},{"@type":"Question","name":"Comment implémenter correctement un timeout avec CancellationToken ?","acceptedAnswer":{"@type":"Answer","text":"Utiliser CancellationTokenSource.CreateLinkedTokenSource() pour combiner un token existant avec un nouveau CancellationTokenSource(timeout). Cela permet d'annuler soit manuellement via le token d'origine, soit automatiquement après le timeout. Depuis .NET 6, utiliser directement la méthode WaitAsync(TimeSpan) sur Task. Ne jamais utiliser Task.Delay avec CancellationToken comme timeout principal car cela ne libère pas les ressources de la Task d'origine."}},{"@type":"Question","name":"Quel est le cas d'usage principal de Task.WhenAll ?","acceptedAnswer":{"@type":"Answer","text":"Task.WhenAll permet d'attendre la complétion de plusieurs tasks indépendantes en parallèle et récupère tous les résultats dans un tableau. C'est optimal pour des opérations I/O indépendantes comme plusieurs appels HTTP. Si une Task échoue, WhenAll attend quand même toutes les autres avant de lever une AggregateException. Pour obtenir tous les résultats même en cas d'erreurs partielles, utiliser des techniques de gestion d'erreurs individuelles."}},{"@type":"Question","name":"Quel est le cas d'usage principal de Task.WhenAny ?","acceptedAnswer":{"@type":"Answer","text":"Task.WhenAny retourne dès que la première task se termine (succès ou échec), ce qui est utile pour implémenter des timeouts, retry avec la réponse la plus rapide, ou traiter des résultats au fur et à mesure. Contrairement à WhenAll, WhenAny ne récupère qu'une seule task complétée et les autres continuent à s'exécuter en arrière-plan sauf annulation explicite. Souvent combiné avec CancellationToken pour annuler les tasks restantes."}},{"@type":"Question","name":"Comment gérer les exceptions lorsque plusieurs tasks échouent dans Task.WhenAll ?","acceptedAnswer":{"@type":"Answer","text":"Task.WhenAll lève une AggregateException contenant toutes les exceptions des tasks échouées. Cependant, avec await, seule la première exception est relancée. Pour accéder à toutes les exceptions, ne pas utiliser await mais accéder à task.Exception.InnerExceptions. Alternativement, wrapper chaque task dans un try-catch pour gérer les erreurs individuellement. Depuis C# 10, utiliser le pattern matching pour traiter différents types d'exceptions."}},{"@type":"Question","name":"Que se passe-t-il si une exception dans une Task asynchrone n'est jamais observée (await, Wait, Result) ?","acceptedAnswer":{"@type":"Answer","text":"Dans .NET 4.5+, les exceptions non observées sont simplement ignorées et n'arrêtent plus l'application par défaut. Elles sont disponibles via TaskScheduler.UnobservedTaskException pour logging. C'est un changement par rapport à .NET 4.0 où cela causait un crash. Cependant, c'est une mauvaise pratique car les erreurs sont silencieuses. Toujours observer les tasks avec await ou accéder à task.Exception. Utiliser Task.Run uniquement avec await ou ContinueWith."}},{"@type":"Question","name":"Quel pattern classique provoque un deadlock avec async/await dans WinForms ou WPF ?","acceptedAnswer":{"@type":"Answer","text":"Appeler .Result ou .Wait() sur une Task asynchrone depuis le thread UI bloque le thread en attendant la complétion. Or, la continuation après await tente de retourner sur le thread UI (via SynchronizationContext), qui est bloqué, créant un deadlock. Solution : toujours utiliser await au lieu de .Result/.Wait(), ou utiliser ConfigureAwait(false) dans le code de bibliothèque. ASP.NET Core n'a pas ce problème car il n'a pas de SynchronizationContext."}},{"@type":"Question","name":"Comment détecter un potentiel deadlock dans du code async/await lors d'une code review ?","acceptedAnswer":{"@type":"Answer","text":"Rechercher les appels bloquants .Result, .Wait(), .GetAwaiter().GetResult() sur des Tasks asynchrones, surtout dans des contextes avec SynchronizationContext (UI, ASP.NET Framework). Vérifier l'absence de ConfigureAwait(false) dans le code de bibliothèque. Analyser les locks (lock, SemaphoreSlim) utilisés autour de code async. Utiliser des analyseurs Roslyn comme AsyncFixer pour détecter automatiquement ces patterns. Les outils de profiling comme dotTrace peuvent identifier les threads bloqués."}},{"@type":"Question","name":"Pourquoi utiliser SemaphoreSlim plutôt que lock (Monitor) dans du code async ?","acceptedAnswer":{"@type":"Answer","text":"Le mot-clé lock ne peut pas être utilisé avec await car il s'appuie sur Monitor qui n'est pas compatible avec les méthodes asynchrones (erreur de compilation). SemaphoreSlim offre WaitAsync() qui permet d'attendre de manière asynchrone sans bloquer le thread. Utiliser SemaphoreSlim(1,1) pour simuler un lock exclusif. Toujours utiliser try-finally pour garantir le Release() même en cas d'exception. Pour des scénarios simples, préférer lock avec du code synchrone."}},{"@type":"Question","name":"Quel est le principal avantage de IAsyncEnumerable introduit dans C# 8 ?","acceptedAnswer":{"@type":"Answer","text":"IAsyncEnumerable permet de streamer des données asynchrones au fur et à mesure sans charger toute la collection en mémoire. Utilise await foreach pour consommer les éléments. Idéal pour les grandes requêtes de base de données (EF Core), lecture de fichiers volumineux, ou streaming de données API. Combiné avec yield return, cela permet de produire des éléments de manière lazy. Supporte CancellationToken via ConfigureAwait. Plus efficace en mémoire que charger toute la liste avec ToListAsync()."}},{"@type":"Question","name":"Comment passer un CancellationToken à une méthode retournant IAsyncEnumerable ?","acceptedAnswer":{"@type":"Answer","text":"Utiliser l'attribut [EnumeratorCancellation] sur le paramètre CancellationToken de la méthode. Lors de l'appel avec await foreach, passer le token via .WithCancellation(token). Cela permet l'annulation pendant l'itération asynchrone. Sans cet attribut, le compilateur ne lie pas correctement le token au GetAsyncEnumerator. Toujours vérifier cancellationToken.ThrowIfCancellationRequested() dans les boucles. Depuis C# 9, cela fait partie du pattern async streams standard."}},{"@type":"Question","name":"Quel est l'avantage de Parallel.ForEachAsync introduit dans .NET 6 comparé à Task.WhenAll ?","acceptedAnswer":{"@type":"Answer","text":"Parallel.ForEachAsync permet de contrôler le degré de parallélisme maximal avec ParallelOptions.MaxDegreeOfParallelism, évitant de saturer les ressources ou les APIs externes. Task.WhenAll lance toutes les tasks immédiatement sans limite. Supporte CancellationToken nativement. Utile pour traiter des grandes collections avec un nombre limité de requêtes simultanées. Combine les avantages de Parallel.ForEach (contrôle du parallélisme) et async/await (non-blocage)."}},{"@type":"Question","name":"Dans quels cas ValueTask utilise-t-il le pooling d'objets pour optimiser les performances ?","acceptedAnswer":{"@type":"Answer","text":"ValueTask peut utiliser IValueTaskSource pour pooler des objets réutilisables dans des scénarios très haute performance comme les opérations I/O réseau avec SocketAsyncEventArgs. La plupart du temps, ValueTask est une structure wrappant soit un résultat synchrone (T), soit une Task. Le pooling via IValueTaskSource est un pattern avancé rarement nécessaire sauf dans des bibliothèques système bas niveau. Pour le code applicatif normal, utiliser ValueTask uniquement pour les chemins synchrones communs (cache hit)."}},{"@type":"Question","name":"Dans quel cas d'usage est-il approprié d'utiliser Task.Run dans une application ASP.NET Core ?","acceptedAnswer":{"@type":"Answer","text":"Task.Run est approprié uniquement pour décharger du CPU-bound work intensif (calculs, traitement d'images) vers le thread pool. Ne jamais utiliser Task.Run pour wrapper des appels I/O asynchrones (HttpClient, EF Core) car cela gaspille un thread. ASP.NET Core a déjà un thread pool pour gérer les requêtes HTTP. Pour du CPU-bound work lourd, considérer des workers en arrière-plan (BackgroundService) plutôt que bloquer une requête HTTP. Task.Run est plus courant dans les applications UI (WinForms/WPF)."}},{"@type":"Question","name":"Quel mode de thread safety utiliser pour Lazy dans une application async ASP.NET Core ?","acceptedAnswer":{"@type":"Answer","text":"Utiliser LazyThreadSafetyMode.ExecutionAndPublication qui garantit qu'une seule initialisation se produit même avec accès concurrent. C'est le mode par défaut. PublicationOnly permet plusieurs initialisations simultanées mais publie uniquement la première. None n'offre aucune protection et peut causer des initialisations multiples. Attention : Lazy n'est pas async-friendly et peut bloquer des threads si le delegate d'initialisation est long. Pour des scénarios async, considérer SemaphoreSlim avec lazy initialization manuelle."}},{"@type":"Question","name":"Quel est le rôle principal de AsyncLocal dans du code asynchrone ?","acceptedAnswer":{"@type":"Answer","text":"AsyncLocal permet de stocker des données qui sont propagées automatiquement à travers les appels async/await, même quand les continuations changent de thread. Contrairement à ThreadLocal qui est lié au thread physique, AsyncLocal suit le contexte d'exécution asynchrone. Utile pour la corrélation de logs (trace ID), le contexte utilisateur, ou les informations de culture. Les modifications dans un contexte enfant ne propagent pas au parent. Coût en performance à considérer pour des scénarios haute fréquence."}},{"@type":"Question","name":"Pourquoi est-il généralement recommandé d'utiliser async/await plutôt que ContinueWith ?","acceptedAnswer":{"@type":"Answer","text":"async/await offre une syntaxe plus simple et lisible, gère automatiquement les exceptions via try-catch standard, et propage correctement le SynchronizationContext. ContinueWith nécessite de gérer manuellement les TaskContinuationOptions, la gestion d'erreurs via task.Exception, et peut créer des bugs subtils avec les TaskScheduler. ContinueWith reste utile pour des scénarios avancés comme branching conditionnel basé sur TaskStatus ou exécution garantie avec TaskContinuationOptions.OnlyOnFaulted."}},{"@type":"Question","name":"Quel pattern async peut causer une fuite mémoire (memory leak) dans une application long-running ?","acceptedAnswer":{"@type":"Answer","text":"Créer des Tasks sans les awaiter ou les stocker dans une collection sans jamais les nettoyer crée une fuite mémoire. Les closures capturant de gros objets dans des lambdas async non terminées gardent ces objets en mémoire. Les CancellationTokenSource non disposés peuvent accumuler des callbacks. Les event handlers async qui ne se désinscrivent pas maintiennent des références. Toujours awaiter les tasks, disposer les CancellationTokenSource, et se désinscrire des événements dans Dispose/DisposeAsync."}},{"@type":"Question","name":"Comment implémenter correctement un pattern fire-and-forget dans ASP.NET Core ?","acceptedAnswer":{"@type":"Answer","text":"Utiliser IHostedService ou BackgroundService pour les tâches en arrière-plan plutôt que Task.Run non awaité. Si vraiment nécessaire dans une requête HTTP, utiliser IBackgroundTaskQueue pour queuer le travail et le traiter via un BackgroundService. Ne jamais lancer des Tasks sans await dans un controller car elles peuvent être tuées lors du shutdown de l'app. Toujours logger les exceptions des tasks fire-and-forget. Éviter ce pattern sauf nécessité absolue car il complique le debugging et les tests."}},{"@type":"Question","name":"Quelle convention de nommage est recommandée pour les méthodes asynchrones en .NET ?","acceptedAnswer":{"@type":"Answer","text":"Les méthodes asynchrones doivent avoir le suffixe 'Async' (ex: GetDataAsync, SaveAsync) selon les guidelines Microsoft. Cela permet d'identifier immédiatement qu'une méthode est asynchrone lors de la code review. Exception : les event handlers async (pas OnClickAsync mais simplement OnClick). Pour les interfaces, définir à la fois des surcharges sync et async si nécessaire (Read/ReadAsync). Cette convention améliore la lisibilité et évite les confusions entre versions sync et async d'une même méthode."}}]}