ExecutionContext, AsyncLocal и SynchronizationContext: как контекст «течёт» через await?

#Два разных «контекста»

#Как течёт ExecutionContext

public static class Correlation
{
    private static readonly AsyncLocal<string?> _id = new();
    public static string? Id { get => _id.Value; set => _id.Value = value; }
}

[ThreadStatic] private static string? _threadId;

async Task HandleAsync()
{
    Correlation.Id = "abc";
    _threadId = "abc";

    await Task.Delay(10);                 // продолжение — возможно, на другом потоке

    Console.WriteLine(Correlation.Id);    // abc
    Console.WriteLine(_threadId);         // null (или чужое значение!) — привязано к потоку
}

#Семантика copy-on-write

static readonly AsyncLocal<int> Value = new();

async Task Parent()
{
    Value.Value = 1;
    await Child();
    Console.WriteLine(Value.Value);       // 1 — изменение в Child не видно родителю
}

async Task Child()
{
    Console.WriteLine(Value.Value);       // 1 — унаследовано
    Value.Value = 2;                      // создаётся НОВЫЙ ExecutionContext для этой ветки
    await Task.Yield();
    Console.WriteLine(Value.Value);       // 2
}

ExecutionContext неизменяем: запись в AsyncLocal создаёт новый объект контекста. Поэтому дочерние операции не могут «испортить» контекст родителя — и поэтому нельзя вернуть значение наверх через AsyncLocal. Если нужно передать данные вверх, храните в AsyncLocal изменяемый объект-держатель и меняйте его поля (так устроен HttpContextAccessor).

#Где это используется в .NET

#Подводные камни

• Производительность: каждая запись в AsyncLocal — выделение нового контекста; много AsyncLocal с частыми изменениями в горячем пути заметны в профиле. IAsyncLocalValueChangedHandler-уведомления (AsyncLocal с обработчиком) ещё дороже.
• Таймеры и кэши: System.Threading.Timer, созданный внутри запроса, захватывает контекст запроса и держит его объекты в памяти — используйте SuppressFlow при создании долгоживущих таймеров.
• ThreadLocal/[ThreadStatic] уместны для кэшей на поток (буферы, Random), но не для данных, связанных с логической операцией.

#Явная передача против неявного контекста

Неявный контекст удобен для сквозных аспектов (трассировка, логирование, корреляция), но скрывает зависимости: метод неявно требует, чтобы кто-то заранее установил значение. Для бизнес-данных (текущий пользователь, тенант) предпочтительнее Scoped-сервисы через DI или явные параметры — их видно в сигнатуре и легко подменить в тестах.

#Вопросы на засыпку

#Итог

ExecutionContext переносит «окружающие» данные (AsyncLocal, Activity, скоупы логирования, культуру) через await и границы потоков, тогда как SynchronizationContext определяет, где выполнится продолжение, и в ASP.NET Core отсутствует. AsyncLocal работает по принципу copy-on-write, [ThreadStatic] в асинхронном коде ненадёжен. Остерегайтесь утечки контекста запроса в фоновые задачи и таймеры, а бизнес-контекст передавайте явно через DI.