為什麼 File.ReadAllLinesAsync() 有時會阻塞 .NET 中的 UI 執行緒？

了解 .NET 中使用 File.ReadAllLinesAsync() 進行 UI 執行緒阻塞

雖然 .NET（版本 3.1 及更高版本）中的 File.ReadAllLinesAsync() 旨在實現非阻塞行為，但在特定條件下它可能會令人驚訝地阻塞 UI 執行緒。

問題

在 WPF 應用程式中，使用 File.ReadAllLinesAsync() 可能會凍結 UI。這是由於非同步文件存取 API 的實作方式不一致所造成的。 Microsoft 的指南建議非同步方法應在最少的同步工作後傳回 Task。 File.ReadAllLinesAsync() 偏離了這一點，導致在返回不完整的 Task 之前長時間阻塞。

解決方案

建議的解決方法是在 File.ReadAllLines() 中使用同步 Task.Run() 方法。這會將檔案讀取任務卸載到後台線程，從而防止 UI 凍結。

測試結果

使用 File.ReadAllLinesAsync() 讀取 6MB 檔案的測試顯示，UI 出現了大約 450 毫秒的嚴重阻塞 – 明顯偏離了預期的異步行為。

.NET 6 及更高版本

即使改進了 .NET 6 的非同步檔案 I/O，File.ReadAllLinesAsync() 仍然存在效能限制。 它比同步版本慢得多（大約是時間的兩倍），並且不是完全非同步的。 因此，在實現進一步的 API 最佳化之前，在 Task.Run() 中使用同步版本仍然是最佳實踐。

以上是為什麼 File.ReadAllLinesAsync() 有時會阻塞 .NET 中的 UI 執行緒？的詳細內容。更多資訊請關注PHP中文網其他相關文章！