Thực hành tốt nhất để gọi ConfigureAwait cho tất cả mã phía máy chủ

Khi bạn có mã phía máy chủ (tức là một số ApiController) và các chức năng của bạn không đồng bộ - vì vậy chúng trả về Task<SomeObject>- đó có được coi là cách thực hành tốt nhất mà bất cứ khi nào bạn chờ đợi các chức năng mà bạn gọi ConfigureAwait(false)không?

Tôi đã đọc được rằng nó hiệu quả hơn vì nó không phải chuyển ngữ cảnh luồng trở lại bối cảnh luồng gốc. Tuy nhiên, với ASP.NET Web Api, nếu yêu cầu của bạn xuất hiện trên một luồng và bạn chờ đợi một số chức năng và cuộc gọi ConfigureAwait(false)có khả năng đưa bạn vào một luồng khác khi bạn trả về kết quả cuối cùng của ApiControllerchức năng.

Tôi đã gõ một ví dụ về những gì tôi đang nói dưới đây:

public class CustomerController : ApiController
{
    public async Task<Customer> Get(int id)
    {
        // you are on a particular thread here
        var customer = await SomeAsyncFunctionThatGetsCustomer(id).ConfigureAwait(false);

        // now you are on a different thread!  will that cause problems?
        return customer;
    }
}

Cập nhật: ASP.NET Core không có aSynchronizationContext . Nếu bạn đang sử dụng ASP.NET Core, việc bạn có sử dụng ConfigureAwait(false)hay không không quan trọng.

Đối với ASP.NET "Full" hoặc "Classic" hoặc bất cứ điều gì, phần còn lại của câu trả lời này vẫn được áp dụng.

Bài gốc (đối với ASP.NET không phải Core):

Video này của nhóm ASP.NET có thông tin tốt nhất về việc sử dụng asynctrên ASP.NET.

Tôi đã đọc được rằng nó hiệu quả hơn vì nó không phải chuyển ngữ cảnh luồng trở lại bối cảnh luồng gốc.

Điều này đúng với các ứng dụng UI, nơi chỉ có một luồng UI mà bạn phải "đồng bộ hóa" trở lại.

Trong ASP.NET, tình hình phức tạp hơn một chút. Khi một asyncphương thức tiếp tục thực thi, nó lấy một luồng từ nhóm luồng ASP.NET. Nếu bạn vô hiệu hóa việc chụp bối cảnh bằng cách sử dụng ConfigureAwait(false), thì luồng sẽ tiếp tục thực thi phương thức trực tiếp. Nếu bạn không tắt chức năng chụp ngữ cảnh, thì luồng sẽ nhập lại ngữ cảnh yêu cầu và sau đó tiếp tục thực thi phương thức.

Vì vậy, ConfigureAwait(false)không tiết kiệm cho bạn một bước nhảy trong ASP.NET; nó giúp bạn tiết kiệm nhập lại bối cảnh yêu cầu, nhưng điều này thường rất nhanh. ConfigureAwait(false) có thể hữu ích nếu bạn đang cố gắng thực hiện một lượng nhỏ xử lý song song một yêu cầu, nhưng thực sự TPL phù hợp hơn với hầu hết các kịch bản đó.

Tuy nhiên, với ASP.NET Web Api, nếu yêu cầu của bạn xuất hiện trên một luồng và bạn đang chờ một số chức năng và gọi ConfigureAwait (false) có khả năng đưa bạn vào một luồng khác khi bạn trả về kết quả cuối cùng của chức năng ApiControll của bạn .

Trên thực tế, chỉ cần làm một awaitcó thể làm điều đó. Khi asyncphương thức của bạn chạm một await, phương thức bị chặn nhưng luồng sẽ quay trở lại nhóm luồng. Khi phương thức đã sẵn sàng để tiếp tục, bất kỳ luồng nào được lấy từ nhóm luồng và được sử dụng để tiếp tục phương thức.

Sự khác biệt duy nhất ConfigureAwaitlàm cho ASP.NET là liệu luồng đó có vào ngữ cảnh yêu cầu khi tiếp tục phương thức hay không.

Tôi có thêm thông tin cơ bản trong bài viết MSDNSynchronizationContext của tôi trên và asyncbài đăng blog giới thiệu của tôi .

Trả lời ngắn gọn cho câu hỏi của bạn: Không. Bạn không nên gọi ConfigureAwait(false)ở cấp ứng dụng như thế.

Phiên bản TL; DR của câu trả lời dài: Nếu bạn đang viết thư viện nơi bạn không biết người tiêu dùng của mình và không cần bối cảnh đồng bộ hóa (mà bạn không nên có trong thư viện tôi tin), bạn nên luôn luôn sử dụng ConfigureAwait(false). Mặt khác, người tiêu dùng của thư viện của bạn có thể phải đối mặt với những bế tắc bằng cách sử dụng các phương thức không đồng bộ của bạn theo kiểu chặn. Điều này phụ thuộc vào tình hình.

Dưới đây là một lời giải thích chi tiết hơn về tầm quan trọng của ConfigureAwaitphương pháp (trích dẫn từ bài đăng trên blog của tôi):

Khi bạn đang chờ đợi một phương thức với từ khóa đang chờ, trình biên dịch sẽ tạo ra một loạt mã thay cho bạn. Một trong những mục đích của hành động này là xử lý đồng bộ hóa với luồng UI (hoặc chính). Thành phần chính của tính năng này là SynchronizationContext.Currentbối cảnh đồng bộ hóa cho luồng hiện tại. SynchronizationContext.Currentđược điền tùy thuộc vào môi trường bạn đang ở. GetAwaiterPhương thức của Nhiệm vụ tìm kiếm SynchronizationContext.Current. Nếu bối cảnh đồng bộ hóa hiện tại không phải là null, việc tiếp tục được chuyển đến người phục vụ đó sẽ được đăng trở lại bối cảnh đồng bộ hóa đó.

Khi sử dụng một phương thức sử dụng các tính năng ngôn ngữ không đồng bộ mới, theo kiểu chặn, bạn sẽ kết thúc với một bế tắc nếu bạn có Đồng bộ hóa có sẵn. Khi bạn đang sử dụng các phương thức như vậy theo kiểu chặn (chờ trên phương thức Nhiệm vụ với Chờ hoặc lấy kết quả trực tiếp từ thuộc tính Kết quả của Tác vụ), bạn sẽ chặn luồng chính cùng một lúc. Cuối cùng, khi Nhiệm vụ hoàn thành bên trong phương thức đó trong luồng, nó sẽ gọi tiếp tục để gửi lại cho luồng chính vì SynchronizationContext.Currentcó sẵn và bị bắt. Nhưng có một vấn đề ở đây: luồng UI bị chặn và bạn gặp bế tắc!

Ngoài ra, đây là hai bài viết tuyệt vời cho bạn chính xác cho câu hỏi của bạn:

• Công thức hoàn hảo để tự bắn vào chân mình - Kết thúc với sự bế tắc bằng cách sử dụng các tính năng ngôn ngữ không đồng bộ C # 5.0
• Các thư viện máy khách .NET không đồng bộ cho API HTTP của bạn và nhận thức về các hiệu ứng xấu của async / await

Cuối cùng, có một đoạn video ngắn tuyệt vời từ Lucian Wischik chính xác về chủ đề này: Các phương pháp thư viện Async nên xem xét sử dụng Task.ConfigureAwait (false) .

Hi vọng điêu nay co ich.

Hạn chế lớn nhất mà tôi đã tìm thấy khi sử dụng ConfigureAwait (false) là văn hóa luồng được hoàn nguyên về mặc định của hệ thống. Nếu bạn đã cấu hình một nền văn hóa, ví dụ ...

<system.web>
    <globalization culture="en-AU" uiCulture="en-AU" />    
    ...

và bạn đang lưu trữ trên một máy chủ có văn hóa được đặt thành en-US, sau đó bạn sẽ tìm thấy trước khi ConfigureAwait (false) được gọi là CultureInfo.CiverseCARM sẽ trả lại en-AU và sau khi bạn sẽ nhận được en-US. I E

// CultureInfo.CurrentCulture ~ {en-AU}
await xxxx.ConfigureAwait(false);
// CultureInfo.CurrentCulture ~ {en-US}

Nếu ứng dụng của bạn đang làm bất cứ điều gì đòi hỏi định dạng dữ liệu cụ thể về văn hóa, thì bạn sẽ cần lưu ý điều này khi sử dụng ConfigureAwait (false).

Tôi có một số suy nghĩ chung về việc thực hiện Task:

1. Nhiệm vụ là dùng một lần nhưng chúng tôi không được phép sử dụng using.
2. ConfigureAwaitđã được giới thiệu trong 4.5. Taskđược giới thiệu vào 4.0.
3. Chủ đề .NET luôn được sử dụng để chuyển ngữ cảnh (xem C # qua sách CLR) nhưng trong quá trình triển khai mặc định, Task.ContinueWithchúng không nhận ra rằng chuyển đổi ngữ cảnh rất tốn kém và nó bị tắt theo mặc định.
4. Vấn đề là một nhà phát triển thư viện không nên quan tâm liệu khách hàng của mình có cần luồng ngữ cảnh hay không do đó không nên quyết định có chảy luồng ngữ cảnh hay không.
5. [Đã thêm sau] Thực tế là không có câu trả lời chính đáng và tài liệu tham khảo phù hợp và chúng tôi tiếp tục đấu tranh vì điều này có nghĩa là ai đó đã không thực hiện đúng công việc của họ.

Tôi đã có một vài bài viết về chủ đề này nhưng tôi thực hiện - ngoài câu trả lời hay của Tugberk - là bạn nên biến tất cả các API không đồng bộ và lý tưởng hóa luồng ngữ cảnh. Vì bạn đang thực hiện async, bạn chỉ có thể sử dụng các phần tiếp theo thay vì chờ đợi vì vậy sẽ không có bế tắc vì không có sự chờ đợi nào được thực hiện trong thư viện và bạn giữ dòng chảy để bối cảnh được giữ nguyên (chẳng hạn như httpContext).

Vấn đề là khi thư viện trưng ra API đồng bộ nhưng sử dụng API không đồng bộ khác - do đó bạn cần sử dụng Wait()/ Resulttrong mã của mình.