[Перевод] Почему, зачем и когда нужно использовать ValueTask04.07.2019 20:49

Этот перевод появился благодаря хорошему комментарию 0×1000000.

В .NET Framework 4 появилось пространство System.Threading.Tasks, а с ним и класс Task. Этот тип и порождённый от него Task долго дожидались, пока их признают стандартами в .NET в роли ключевых аспектов модели асинхронного программирования, которая была представлена в C# 5 с его операторами async/await. В этой статье я расскажу о новых типах ValueTask/ValueTask, разработанных для улучшения производительности асинхронных методов в случаях, когда издержки на выделение памяти нужно принимать во внимание.

Task

Task выступает в разных ролях, но основная — это «обещание» (promise), объект, представляющий возможное завершение некоторой операции. Вы инициируете операцию и получаете для неё объект Task, который будет выполнен, когда операция завершится, что может произойти в синхронном режиме как составная часть инициализации операции (например, получение данных, которые уже в буфере), в асинхронном режиме с выполнением в момент, когда вы получаете Task (получение данных не из буфера, но очень быстро), или в асинхронном режиме, но после того, как Task уже у вас (получение данных по с удалённого ресурса). Так как операция может завершиться асинхронно, вы или блокируете поток выполнения, ожидая результата (что часто делает бессмысленным асинхронность вызова), или создаёте функцию обратного вызова (callback), которая будет активизирована после завершения операции. В .Net 4 создание callbackа реализовано методами ContinueWith объекта Task, которые явно демонстрируют эту модель, принимая функцию-делегат (delegate), чтобы запустить её после исполнения Task:

SomeOperationAsync().ContinueWith(task =>
{
    try
    {
        TResult result = task.Result;
        UseResult(result);
    }
    catch (Exception e)
    {
        HandleException(e);
    }
});

Но в .NET Framework 4.5 и C# 5 объекты Task могут быть просто вызваны оператором await, что делает простым получение результата асинхронной операции, и генерированным кодом, который оптимизирован для вышеупомянутых вариантов, правильно отработает во всех случаях завершения операции в синхронном режиме, быстром асинхронном или асинхронном с выполнением callbacka:

TResult result = await SomeOperationAsync();
UseResult(result);

Task является очень гибким классом и это даёт ряд преимуществ. Например, вы можете выполнить await несколько раз для любого количества потребителей одновременно. Вы можете положить его в коллекцию (dictionary) для повторных await в будущем, чтобы использовать его как кеш результатов асинхронных вызовов. Вы можете заблокировать выполнение, ожидая завершения Task, если такое понадобится. И вы можете написать и применить разнообразные операции над объектами Task (иногда их называют «комбинаторами»), например, «когда любая» («when any») для асинхронного ожидания первого завершения из нескольких Task.
Но эта гибкость становится лишней в наиболее часто встречающемся случае: просто вызвать асинхронную операцию и дождаться выполнения задачи:

TResult result = await SomeOperationAsync();
UseResult(result);

Здесь нам не понадобится ждать выполнения несколько раз. Нам не нужно обеспечить конкуррентность ожиданий. Нам не нужно выполнять синхронную блокировку. Мы не будем писать комбинаторы. Мы просто ждём выполнения promise асинхронной операции. В конце концов, это так, как мы пишем синхронный код (например, TResult result = SomeOperation ();), и это обычным образом переводится на язык async/await.

Более того, у Task есть потенциальная слабая сторона, особенно когда создаётся большое количество его экземпляров, а большая пропускная способность и производительность являются ключевыми требованиями — Task является классом. Это означает, что любая операция, которой понадобился Task, вынуждена создавать и размещать объект, а чем больше объектов создаётся, тем больше работы для сборщика мусора (GC), и на эту работу расходуются ресурсы, которые мы могли бы потратить на что-то более полезное.

Среда выполнения и системные библиотеки помогают смягчать эту проблему во многих ситуациях. Например, если мы напишем такой метод:

public async Task WriteAsync(byte value)
{
    if (_bufferedCount == _buffer.Length)
    {
        await FlushAsync();
    }
    _buffer[_bufferedCount++] = value;
}

как правило, в буфере будет достаточно свободного пространства, и операция выполнится синхронно. Когда это произойдёт, не нужно ничего делать с Task, который должен быть возвращён, так как возвращаемое значение отсутствует, это использование Task как эквивалент синхронного метода, возвращающего пустое значение (void). Поэтому среда может просто кешировать один необобщённый (non-generic) Task и использовать его снова и снова как результат выполнения для любого async метода, который завершается синхронно (этот кешированный синглтон можно получить через Task.CompletedTask). Или, например, вы пишете:

public async Task MoveNextAsync()
{
    if (_bufferedCount == 0)
    {
        await FillBuffer();
    }
    return _bufferedCount > 0;
}

и в общем случае ожидаете, что данные уже в буфере, так что метод просто проверит значение _bufferedCount, увидит, что оно больше 0, и вернёт true; и только если данных в буфере ещё нет, нужно выполнить асинхронную операцию. И так как есть только два возможных результата типа Boolean (true и false), существует только два возможных Task объекта, которые нужны для представления этих результатов, среда может кешировать эти объекты и возвращать их с соответствующим значением без выделения памяти. Только в случае асинхронного завершения методу понадобится создать новый Task, потому что его будет нужно вернуть до того, как станет известен результат операции.

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

public async Task ReadNextByteAsync()
{
    if (_bufferedCount == 0)
    {
        await FillBuffer();
    }

    if (_bufferedCount == 0)
    {
        return -1;
    }

    _bufferedCount--;
    return _buffer[_position++];
}

также будет часто выполняться синхронно. Но в отличие от варианта с результатом типа Boolean этот метод возвращает Int32, который имеет порядка 4 миллиардов значений, и кеширование всех вариантов Task потребует сотни гигабайт памяти. Среда обеспечивает небольшой кеш для Task, но сильно ограниченного набора значений, например, если этот метод завершится синхронно (данные уже в буфере) с возвращаемым значением 4, это будет кешированный Task, но если возвращается значение 42, то нужно будет создать новый Task, подобно вызову Task.FromResult (42).

Многие методы библиотеки пытаются сгладить это путём обеспечения собственного кеша. Например, перегрузка в.NET Framework 4.5 метода MemoryStream.ReadAsync всегда завершается синхронно, так как читает данные из памяти. ReadAsync возвращаетTask, где результат типа Int32 показывает сколько байт было прочитано. Этот метод часто используется в цикле, часто с одним и тем же требуемым количеством байтов при каждом вызове, и часто эта потребность удовлетворяется в полном объёме. Так что для повторных вызовов ReadAsync обоснованно ожидать, что Task будет синхронно возвращаться с таким же значением, как и в прошлом вызове. Поэтому MemoryStream создаёт кеш для одного объекта, который вернулся в последнем успешном вызове. И в следующем вызове, если результат повторится, он вернёт кешированный объект, а если нет, создаст новый с Task.FromResult, сохранит в кеш и вернёт его.

И всё же есть множество других случаев, когда операция выполняется синхронно, но объект Task вынужденно создаётся.

ValueTask и синхронное выполнение

Всё это потребовало реализации в .NET Core 2.0 нового типа, который доступен в предыдущих версиях .NET в пакете NuGet System.Threading.Tasks.Extensions: ValueTask.
ValueTask создан в .NET Core 2.0 как структура, способная обернуть как TResult, так и Task. Это означает, что её можно возвращать из async метода, и, если этот метод выполнится синхронно и успешно, никакого объекта в куче размещать не надо: вы можете просто инициализировать эту структуру ValueTask значением TResult и вернуть. Только в случае асинхронного выполнения объект Task будет размещён, а ValueTask обернёт его (чтобы минимизировать размер структуры и оптимизировать случай успешного исполнения, async метод, который завершается с неподдерживаемым исключением, также будет размещать Task, так что ValueTask так же просто обернёт Task, а не будет таскать с собой дополнительное поле для хранения Exception).

Исходя из этого, метод наподобие MemoryStream.ReadAsync, но возвращающий ValueTask, не должен заниматься кешированием, а вместо этого может быть написан так:

public override ValueTask ReadAsync(byte[] buffer, int offset, int count)
{
    try
    {
        int bytesRead = Read(buffer, offset, count);
        return new ValueTask(bytesRead);
    }
    catch (Exception e)
    {
        return new ValueTask(Task.FromException(e));
    }
}

ValueTask и асинхронное выполнение

Возможность написать async метод, который способен завершиться синхронно без необходимости дополнительного размещения для результата, это большая победа. Вот почему ValueTask был добавлен в .NET Core 2.0, и новые методы, которые вероятно будут использоваться в приложениях, требующих производительности, теперь объявляются с возвращением ValueTask вместо Task. Например, когда мы добавили новую перегрузку ReadAsync класса Stream в .NET Core 2.1, для того чтобы иметь возможность передавать Memory вместо byte[], мы возвращаем в нём тип ValueTask. В таком виде объекты Stream (в которых очень часто метод ReadAsync исполняется синхронно, как в ранее приведённом примере для MemoryStream) могут использоваться со значительно меньшим выделением памяти.

Однако, когда мы работаем с сервисами с очень высокой пропускной способностью, мы по-прежнему хотим избежать выделения памяти насколько вообще это возможно, а это означает уменьшение и устранение выделения памяти также и по маршруту асинхронного исполнения.
В модели await для любой операции, завершающейся асинхронно, нам необходима способность вернуть объект, который представляет возможное завершение операции: вызывающему необходима переадресация callbackа, который будет инициирован по завершению операции, и это требует наличия уникального объекта в куче, который может послужить как канал передачи для этой конкретной операции. Это, в то же время, не означает ничего будет ли этот объект использован повторно после завершения операции. Если этот объект может быть использован повторно, API может организовать кеш для одного или нескольких таких объектов, и применять его для последовательных операций, в смысле не использовать один и тот же объект для нескольких промежуточных async операций, но использовать для неконкуррентного доступа.
В .NET Core 2.1 класс ValueTaskбыл доработан для поддержки подобной работы с пулами и повторного использования. Вместо того, чтобы просто оборачивать TResult или Task, доработанный класс может оборачивать новый интерфейс IValueTaskSource. Этот интерфейс обеспечивает основную функциональность, которая требуется для сопровождения асинхронной операции объектом ValueTask так же, как это делает Task:

public interface IValueTaskSource
{
    ValueTaskSourceStatus GetStatus(short token);
    void OnCompleted(Action