Maison >développement back-end >C++ >Pourquoi les opérations d'E/S de fichiers asynchrones bloquent-elles toujours le thread de l'interface utilisateur dans .NET (et comment y remédier) ?

Pourquoi les opérations d'E/S de fichiers asynchrones bloquent-elles toujours le thread de l'interface utilisateur dans .NET (et comment y remédier) ?

DDD
DDDoriginal
2025-01-20 15:15:09347parcourir

Why Do Async File I/O Operations Still Block the UI Thread in .NET (and How to Fix It)?

Résolution du blocage des threads de l'interface utilisateur dans les opérations d'E/S de fichiers asynchrones

L'objectif de la programmation asynchrone dans les applications GUI est d'empêcher le blocage des threads de l'interface utilisateur, garantissant ainsi une expérience utilisateur réactive. Cependant, dans .NET Core 3.1 et les versions antérieures, les API du système de fichiers asynchrones ne respectaient pas toujours les meilleures pratiques.

Plus précisément, File.ReadAllLinesAsync() pourrait bloquer le thread de l'interface utilisateur, malgré sa conception asynchrone. En effet, la méthode n'a pas entièrement respecté le modèle asynchrone recommandé : un travail synchrone minimal avant de renvoyer la tâche.

Pour contourner ce problème dans les anciennes versions de .NET, évitez d'utiliser les API du système de fichiers asynchrones directement dans les applications GUI. Au lieu de cela, encapsulez les API synchrones dans Task.Run(). Par exemple :

<code class="language-csharp">var lines = await Task.Run(() => File.ReadAllLines(@"D:\temp.txt"));</code>

Observations de performances :

Les tests révèlent le comportement bloquant de File.ReadAllLinesAsync(). Le traitement d'un fichier de 6 Mo sur un SSD entraînait un blocage du thread d'interface utilisateur de 450 millisecondes avant qu'une tâche incomplète ne soit renvoyée dans les anciennes versions de .NET.

Améliorations de .NET 6 :

.NET 6 a apporté des améliorations aux API du système de fichiers asynchrones, réduisant considérablement le temps de blocage à environ 19 millisecondes. Cependant, ces API asynchrones restent plus lentes (environ le double de la vitesse) que leurs homologues synchrones et ne sont pas entièrement asynchrones. Par conséquent, l’utilisation d’API synchrones intégrées dans Task.Run() reste une approche recommandée pour des performances et une réactivité optimales de l’interface utilisateur.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn