Использование async и await в C# — лучшие практики

Ключевые слова async и await, введённые в C# 5.0, значительно упрощают асинхронное программирование. Они также скрывают за собой некоторые сложности, которые, если вы потеряете бдительность, могут добавить проблем в ваш код. Описанные ниже практики пригодятся вам, если вы создаёте асинхронный код для .NET приложений.


Используйте async /await только для тех мест, которые могут длиться «долго»

Здесь всё просто. Создание Task и других структур для управления асинхронными операциями добавляет некоторые накладные расходы. Если ваша операция действительно продолжительна, например выполнение IO запроса, тогда эти расходы в основном не будут заметны. А в том случае, если ваша операция коротка или займёт несколько циклов процессора, тогда возможно будет лучше выполнять эту операцию синхронно.

В целом, команда, работавшая над .NET Framework, проделала неплохую работу по выбору функциональсти, которая должна быть асинхронной. Так, если метод фреймворка заканчивается на Async и возвращает задачу, тогда, скорее всего вы должны использовать его асинхронно.

Предпочитайте async/await вместо Task

Написание асинхронного кода, используя async/await, намного упрощает и сам процесс создания кода, и его чтение, нежели использование задач Task.

public Task<Data> GetDataAsync()
{
    return MyWebService.FetchDataAsync()
        .ContinueWith(t => new Data (t.Result));
}

public async Task<Data> GetDataAsync()
{
    var result = await MyWebService.FetchDataAsync();
    return new Data (result);
}

В терминах производительности, оба метода, представленные выше, имеют небольшие накладные расходы, но они несколько по-разному масштабируются при увеличении количества задач в них:

• Task строит цепочку продолжений, которая увеличивается в соответствии с количеством задач, связанных последовательно, и состояние системы управляется через замыкания, найденные компилятором.
• Async/await строит машину состояний, которая не использует дополнительных ресурсов при добавлении новых шагов. Однако компилятор может определить больше переменных для сохранение в стеки машины состояний, в зависимости от вашего кода (и компилятора). В статье на MSDN отлично расписаны детали происходящего.

В большинстве сценариев async/await будет использовать меньше ресурсов и выполняться быстрее, чем задачи Task.

Используйте уже выполненную пустую статическую задачу для условного кода

Иногда вы хотите запустить задачу только при каком-то условии. К сожалению, await вызовет NullReferenceException, если получит null вместо задачи, а обработка этого сделает ваш код менее читабельным.

public async Task<Data> GetDataAsync(bool getLatestData)
{
    Task<WebData> task = null;
    if (getLatestData)
        task = MyWebService.FetchDataAsync();

    // здесь выполним другую работу

    // и не забудем проверить на null
    WebData result = null;
    if (task != null)
        result = await task;

    return new Data (result);
}

Один из способов немного упростить код – использовать пустую задачу, которая уже выполнена. Полученный код будет чище:

public async Task<Data> GetDataAsync(bool getLatestData)
{
    var task = getLatestData ? MyWebService.FetchDataAsync() : Empty<WebData>.Task;

    // здесь выполним другую работу

    // task всегда не null
    return new Data (await task);
}

Убедитесь, что задача является статической и создана как завершённая. Например:

public static class Empty<T>
{
    public static Task<T> Task { get { return _task; } }    

    private static readonly Task<T> _task = System.Threading.Tasks.Task.FromResult(default(T));
}

Производительность: предпочитайте кэшировать сами задачи, нежели их данные

Существую некоторые накладные расходы при создании задач. Если вы кэшируете ваши результаты, но потом конвертируете их обратно в задачи, вы, возможно, создаете дополнительные объекты задач.

public Task<byte[]> GetContentsOfUrl(string url)
{
    byte[] bytes;

    if (_cache.TryGetValue(url, out bytes))
        // дополнительная задача создаётся здесь
        return Task<byte[]>.Factory.StartNew(() => bytes);

    bytes = MyWebService.GetContentsAsync(url)
        .ContinueWith(t => { _cache.Add(url, t.Result); return t.Result; );
}
// это не потокобезоспасно (не копируйте себе этот код как есть)
private static Dictionary<string, byte[]> _cache = new Dictionary<string, byte[]>();

Вместо этого будет лучше копировать в кэш сами задачи. В этом случае использующий их код может ждать уже выполненную задачу. В Task Parallel Library присутствуют оптимизации для того, чтобы код ожидающий выполнения уже завершённой задачи выполнялся быстрее.

public Task<byte[]> GetContentsOfUrl(string url)
{
    Task<byte[]> bytes;

    if (!_cache.TryGetValue(url, out bytes))
    {
        bytes = MyWebService.GetContentsAsync(url);
        _cache.Add(url, bytes);
    }

    return bytes;
}
//  это не потокобезоспасно (не копируйте себе этот код как есть)
private static Dictionary<string, Task<byte[]>> _cache = new Dictionary<string, Task<byte[]>>();

 
Производительность: понимайте, как await сохраняет состояние

Когда вы используете async/await, компилятор создаёт машину состояний, которая хранит переменные и стек. Например:

public static async Task FooAsync()
{
  var data = await MyWebService.GetDataAsync();
  var otherData = await MyWebService.GetOtherDataAsync();
  Console.WriteLine("{0} = "1", data, otherdata);
}

Это создаст объект состояния с несколькими переменными. Смотрите, как компилятор сохранит переменные метода:

[StructLayout(LayoutKind.Sequential), CompilerGenerated]
private struct <FooAsync>d__0 : <>t__IStateMachine {
  private int <>1__state;
  public AsyncTaskMethodBuilder <>t__builder;
  public Action <>t__MoveNextDelegate;
 
  public Data <data>5__1;
  public OtherData <otherData>5__2;
  private object <>t__stack;
  private object <>t__awaiter;
 
  public void MoveNext();
  [DebuggerHidden]
  public void <>t__SetMoveNextDelegate(Action param0);
}

Замечание 1. Если вы декларируете переменную, она сохранится в объекте, хранящем состояние. Это может привести к тому, что объекты будут оставаться в памяти дольше, чем вы бы могли ожидать.

Замечание 2. Но если вы не станете декларировать переменную, а использовать значение Async вызова вместе с await, переменная попадёт во внутренний стек:

public static async Task FooAsync()
{
  var data = MyWebService.GetDataAsync();
  var otherData = MyWebService.GetOtherDataAsync();

  // промежуточные результаты попадут во внутренний стек и 
  // добавятся дополнительные переключения контекстов между await-ами
  Console.WriteLine("{0} = "1", await data, await otherdata);
}

Вы не должны слишком сильно волноваться по этому поводу до тех пор, пока вы не видите проблем производительности. Если вы всё-таки решили углубиться в оптимизацию, на MSDN есть хорошая статья по этому поводу: Async Performance: Understanding the Costs of Async and Await.

Стабильность: async/await – это не Task.Wait

Машина состояний, генерируемая async/await – это не то же самое, что Task.ContinueWith/Wait. В общем случае вы можете заменить реализацию с Task на await, но могут возникнуть некоторые проблемы производительности и стабильности. Давайте посмотрим подробнее.

Стабильность: знайте свой контекст синхронизации

Код .NET всегда исполняется в некотором контексте. Этот контекст определяет текущего пользователя и другие значения, требуемые фреймворком. В некоторых контекстах выполнения, код работает в контексте синхронизации, который управляет выполнением задач и другой асинхронной работы.

По-умолчанию, после await код продолжит работать в контексте, в котором он был запущен. Это удобно, потому что в основном вы захотите, чтобы контекст безопасности был восстановлен, и вы хотите, чтобы ваш код после await имел доступ к объектам Windows UI, если он уже имел доступ к ним при старте. Заметим, что Task.Factory.StartNew – не осуществляет восстановление контекста.

Некоторые контексты синхронизации не поддерживают повторный вход в них и являются однопоточными. Это означает, что только одна единица работы может выполняться в этом контексте одновременно. Примером этого может быть поток Windows UI или контекст ASP.NET.

В таких однопоточных контекстах синхронизации довольно легко получить deadlock. Если вы создадите задачу в однопоточном контексте, и потом будете ждать в этом же контексте, ваш код, который ждёт, будет блокировать выполнение фоновой задачи.

public ActionResult ActionAsync()
{
    // DEADLOCK: это блокирует асинхронную задачу
    // которая ждёт, когда она сможет выполняться в этом контексте
    var data = GetDataAsync().Result;

    return View(data);
}

private async Task<string> GetDataAsync()
{
    // простой вызов асинхронного метода
    var result = await MyWebService.GetDataAsync();
    return result.ToString();
}

Стабильность: не используйте Wait, чтобы дождаться окончания задачи прямо здесь

Как основное правило – если вы создаёте асинхронный код, будьте осторожны c использованием Wait. (c await всё несколько лучше.)

Не используйте Wait для задач в однопоточных контекстах синхронизации, таких как:

• Потоки UI
• Контекст ASP.NET

Хорошая новость заключается в том, что фреймворк позволяет вам возвращать Task в определённых случаях, и сам фреймворк будет ожидать выполнения задачи. Доверье ему этот процесс:

public async Task<ActionResult> ActionAsync()
{
    // этот метод использует async/await и возвращает Task
    var data = await GetDataAsync();

    return View(data);
}

Если вы создаёте асинхронные библиотеки, ваши пользователи должны будут писать асинхронный код. Раньше это было проблемой, так как написание асинхронного кода было утомительным и уязвимым для ошибок, но с появлением async/await большая часть сложности теперь обрабатывается компилятором. А ваш код получает большую надёжность, и вы теперь с меньше вероятностью будете вынуждены бороться с нюансами ThreadPool.

Стабильность: рассмотрите использование ConfigureAwait, если вы создаёте библиотеку

Если вы обязаны ожидать выполнения задачи в одном из этих контекстов, вы можете использовать ConfigureAwait, чтобы сказать системе, что она не должна выполнять фоновую задачу в вашем контексте. Недостатком этого является то, что фоновая задача не будет иметь доступа к тому же самому контексту синхронизации, так что вы потеряете доступ к Windows UI или HttpContext (хотя ваш контекст безопасности всё равно будет у вас).

Если вы создаёте «библиотечную» функцию, которая возвращает Task, вы, скорее всего, не знаете, как она будет вызываться. Так что, возможно, будет безопаснее добавить ConfigureAwait(false) к вашей задаче перед тем как её вернуть.

private async Task<string> GetDataAsync()
{
    // ConfigureAwait(false) говорит системе, чтобы она
    // позволила оставшемуся коду выполняться в любом контексте
    var result = await MyWebService.GetDataAsync().ConfigureAwait(false);
    return result.ToString();
}

Стабильность: понимайте, как ведут себя исключения

Когда смотришь на асинхронный код, тяжело иногда сказать, что же случается с исключениями. Будет ли оно передано вызывающей функции, или тому коду, который ждёт выполнения задачи?

Правила в этом случае довольно прямолинейны, но всё равно иногда трудно ответить на вопрос, просто глядя на код.

Некоторые примеры:

• Исключения, вызванные из самого async/await метода, будут отправлены коду, ожидающему выполнения задачи (awaiter).
  

  public async Task<Data> GetContentsOfUrl(string url)
  {
      // это исключение будет вызвано на коде, ожидающем 
      // выполнения этой задачи
      if (url == null) throw new ArgumentNullException();
  
      var data = await MyWebService.GetContentsOfUrl();
      return data.DoStuffToIt();
  }
  

  
  
• Исключения, вызванные из делегата задачи Task, тоже будут отправлены коду, ожидающему выполнения задачи (awaiter).
  

  public Task<Data> GetContentsOfUrl(string url)
  {
      return Task<Data>.Factory.StartNew(() =>
      {
          // это исключение будет вызвано на коде, ожидающем 
          // выполнения этой задачи
          if (url == null) throw new ArgumentNullException();
  
          var data = await MyWebService.GetContentsOfUrl();
          return data.DoStuffToIt();
      }
  }
  

  
  
• Исключения, вызванные во время создания Task, будут отправлены коду, который вызывал этот метод (caller) (что, в общем, очевидно):
  

  public Task<Data> GetContentsOfUrl(string url)
  {
      // это исключение будет вызвано на вызывающем коде
      if (url == null) throw new ArgumentNullException();
  
      return Task<Data>.Factory.StartNew(() =>
      {
          var data = await MyWebService.GetContentsOfUrl();
          return data.DoStuffToIt();
      }
  }
  

  
  

Последний пример является одной из причин, почему я предпочитаю async/await вместо создания цепочек задач посредством Task.

Дополнительные ссылки (на английском)

• MSDN: Async/Await FAQ
• Об оптимизации await “быстрый путь”
• MSDN: Await, and UI, and deadlocks! Oh my!
• MSDN: Async Performance: Understanding the Costs of Async and Await