19. Вопросы и ответы для собеседования¶

Метод превращается в «заглушку»: создаёт машину состояний (структуру в Release), AsyncTaskMethodBuilder, ставит состояние -1, вызывает builder.Start(ref machine) (синхронно запускает MoveNext) и возвращает builder.Task. Вся логика уходит в MoveNext вложенного типа <Имя>d__N, помеченного [AsyncStateMachine] на заглушке.

-1 выполняется или не начат, -2 завершён, 0..N приостановлен на await с таким номером, при возобновлении MoveNext переходит к коду после него.

Структура, чтобы синхронный путь не аллоцировал: пока ни один await не приостановился, машина живёт на стеке. При первой реальной приостановке builder упаковывает её в объект в куче (в современных версиях бокс сам является Task<T>). Отсюда: синхронное завершение дёшево, реальная приостановка стоит аллокации.

Локальная переменная, значение которой нужно после await, превращается в поле машины. Переменные, не живущие через await, остаются локальными в MoveNext. Видно в декомпиляции по полям вида <x>5__N. Чем больше таких переменных, тем больше машина.

Тип с методом GetAwaiter() (может быть методом расширения), awaiter с IsCompleted, GetResult() и INotifyCompletion.OnCompleted (обычно ещё ICriticalNotifyCompletion). int по умолчанию нельзя, но можно написать метод расширения GetAwaiter для любого типа (TimeSpan, например).

Оба регистрируют продолжение (MoveNext) на awaiter'е. AwaitOnCompleted идёт через делегат и вызывает OnCompleted awaiter'а, который сам захватывает и восстанавливает ExecutionContext, хотя бокс уже хранит свой, то есть работа делается дважды. AwaitUnsafeOnCompleted вызывает UnsafeOnCompleted и контекст не захватывает (это уже сделал бокс), быстрее. Компилятор берёт Unsafe-вариант, когда awaiter реализует ICriticalNotifyCompletion (глава 3).

Нет. async потоков не создаёт. Метод синхронно работает до первого незавершённого await. Потоки появляются потому, что операции под await (таймеры, I/O) завершаются на потоках пула, и продолжение исполняет какой-то из них.

Зависит от наличия контекста. С SynchronizationContext (UI, старый ASP.NET) продолжение возвращается в него. Без контекста (консоль, ASP.NET Core) продолжение выполняется на потоке, завершившем операцию (обычно пула), или inline. Если await попал на уже завершённую задачу, продолжение идёт синхронно в том же потоке.

Говорит: не захватывать контекст и планировщик для продолжения именно этого await. Не создаёт новый поток и не переключает его сам. Если задача уже завершена, продолжение идёт синхронно, как и без него. Не отключает ExecutionContext (AsyncLocal течёт). Относится только к одному await, поэтому в библиотеках его ставят на каждый.

Нет, там нет SynchronizationContext. Но в библиотечном коде, который могут вызвать из UI, ставят всегда (анализатор CA2007).

Код в контексте с одним потоком (UI) вызывает .Result/.Wait(), поток заблокирован. await внутри захватил контекст и хочет вернуть продолжение в тот же заблокированный поток, а задача ждёт этого продолжения. Взаимная блокировка. Воспроизведение: §6.1 с самодельным контекстом.

Голодание: все потоки пула заняты синхронным ожиданием, новая работа стоит в очереди, пул добавляет потоки медленно. Признаки: рост латентности при низком CPU, длинная очередь пула, таймауты. Не является классическим дедлоком (нет циклического ожидания контекста), но выглядит похоже. Лечение то же: убрать блокирующие вызовы. На стенде 32 задачи по 1 с с Thread.Sleep при MinThreads=4 заняли 6–8 с (глава 13).

SynchronizationContext определяет, где выполнится продолжение (в каком потоке или очереди). ExecutionContext определяет, какие данные текут за логическим потоком (AsyncLocal, Activity). ConfigureAwait(false) отключает первое, не второе.

Течёт вниз по цепочке await, Task.Run. Изменения внутри async-метода вызывающему не видны (builder восстанавливает контекст после первого MoveNext). Для данных запроса (корреляция, tenant) подходит; ThreadLocal для этого не годится.

В возвращаемый Task (Faulted); вызов не бросает, даже если исключение до первого await. Увидите при await/.Wait()/.Result/task.Exception. Поэтому проверку аргументов публичных методов делают в обычном методе с локальной async-функцией.

async void не возвращает Task; исключение публикуется в захваченный SynchronizationContext, а без него бросается на потоке пула и, как правило, роняет процесс. Допустим только для обработчиков событий.

await бросает только первое исключение. Все лежат в whenAllTask.Exception.InnerExceptions, поэтому держите ссылку на задачу WhenAll.

await перебрасывает исходное исключение с сохранением стека. .Result/.Wait() оборачивают его в AggregateException. GetAwaiter().GetResult() ведёт себя как await (без обёртки).

Task.Run использует пул (TaskScheduler.Default) и разворачивает async-лямбды. StartNew использует TaskScheduler.Current (ловушка с чужим планировщиком), для async-лямбды возвращает Task<Task>, нужен Unwrap. Берут Task.Run.

ContinueWith использует TaskScheduler.Current, не восстанавливает контекст, не раскручивает вложенные задачи без Unwrap, требует вручную обработки исключений и отмены. await проще и безопаснее.

TaskCompletionSource<T> создаёт Task, который завершается вручную (TrySetResult), мост от callback/событий к async. RunContinuationsAsynchronously заставляет продолжения выполняться в пуле, а не inline в потоке, вызвавшем SetResult, иначе чужой код выполнится внутри вашего вызова и возможны блокировки и дедлоки.

Когда метод часто завершается синхронно (кеш, буфер) и важны аллокации. Правила: await один раз, не ждать параллельно, не брать .Result до завершения, для повторного использования AsTask(). Нарушение читает чужие данные из переиспользованного источника. Структура 16 байт: _obj (null/Task/источник), результат, токен (глава 12).

Асинхронная последовательность: MoveNextAsync возвращает ValueTask<bool>. Метод с async и yield return компилируется в класс, реализующий IAsyncEnumerable/Enumerator, IAsyncStateMachine, IValueTaskSource. await foreach разворачивается в while (await e.MoveNextAsync()) с try/finally и await e.DisposeAsync(). Отмена: [EnumeratorCancellation] и WithCancellation.

Кооперативная: CancellationTokenSource выдаёт токен, код сам проверяет или передаёт токен API. OperationCanceledException с токеном операции переводит Task в Canceled, остальные исключения в Faulted. Принудительно прервать работу нельзя; уже сделанное не откатывается.

Токен: CancellationTokenSource(timeout) или CancelAfter, пробросить в операцию. Для чужой задачи без токена: task.WaitAsync(timeout) (перестаёт ждать, но не отменяет). Не WhenAny с Delay (таймер и задача остаются).

Асинхронная очередь «производитель — потребитель» с ограничением ёмкости и обратным давлением. В отличие от BlockingCollection<T> не блокирует потоки: WriteAsync/ReadAsync. Использование: фоновая обработка в BackgroundService.

Parallel.ForEachAsync с MaxDegreeOfParallelism, либо SemaphoreSlim с WaitAsync/Release в finally, либо Channel с фиксированным числом читателей.

lock (Monitor) привязан к потоку, а продолжение после await может выполняться на другом, поэтому компилятор запрещает (CS1996). Использовать SemaphoreSlim(1,1) с WaitAsync. Он не реентерабельный.

Глобальная очередь и локальные очереди потоков с кражей работы; число потоков адаптивное: до MinThreads создаются сразу, выше добавляются медленно. Нагрузка скачком (особенно с блокирующим кодом) упирается в медленное добавление потоков: голодание обнаруживается примерно раз в 500 мс, +1 поток. Свободный поток берёт сначала свою локальную очередь (с конца, LIFO), потом общую (FIFO), потом крадёт у соседей (глава 13).

Нет. Если драйвер внутри синхронный, «асинхронный» вызов занимает поток на всё время. Контрпример: Task.Run(() => File.ReadAllText(...)). Ещё тоньше: ожидание бесплатно, а завершение требует потока пула. При занятом пуле не завершились ни чтение из сокета, ни чтение файла с useAsync: true, и на Linux, и на Windows (глава 13). На Windows ядро читает честно (IOCP), но события завершения всё равно обрабатывает рабочий поток пула.

return task; вместо return await task; экономит машину состояний. Вредит, если внутри using/try: ресурс освободится раньше завершения задачи; исключения проходят иначе; меняется стек. Использовать только в простых «проводящих» методах.

Не _ = Task.Run с HttpContext/scoped-сервисами. Положить задание в Channel и обрабатывать в BackgroundService со своим scope, с логированием ошибок и токеном остановки. Для надёжности (должно пережить рестарт) отдельная очередь (брокер, outbox).

Смотреть на количество потоков пула во время ожидания (dotnet-counters), на стек (нет блокирующего вызова внутри), на нагрузочный тест: сколько одновременных операций выдерживает при малом числе потоков. Для чужой библиотеки: проверить документацию и исходники, нет ли Task.Run внутри.

Sync-over-async: блокировка на async (.Result) — дедлок или голодание пула. Async-over-sync: Task.Run(синхронный_вызов) для видимости асинхронности — тратит поток, нет выигрыша на сервере. Оба скрывают реальную стоимость.

В 10.0.12 всё перечисленное есть и использовано в лабораторных: ConfigureAwaitOptions, Task.WaitAsync, PeriodicTimer, Parallel.ForEachAsync, CancellationTokenSource.CancelAsync, Task.WhenEach, RendezvousChannel. LINQ для IAsyncEnumerable<T> входит в BCL (System.Linq.AsyncEnumerable, не нужен пакет; глава 11). Номера версий появления (.NET 6/8/9) взяты из документации и не проверялись. Runtime async: на .NET 10 превью, на .NET 11 RC1 доступен по флагу компилятора (вопрос 37). Span и ref-локали в async-методах разрешены, пока не живут через await (CS4007 иначе; глава 16).

Порядок (глава 15): dotnet-counters (очередь и число потоков пула, CPU), dotnet-stack report -p PID (у кого висят потоки: Wait, Result, Sleep), при простаивающем пуле и потоке в Wait снять дамп dotnet-dump collect и выполнить dumpasync --tasks --completed --fields. Признак дедлока на контексте: машина состояний ждёт уже завершённую задачу (продолжение запланировано, но контекст занят). Признак голодания: задержка пула растёт, threadpool показывает Idle: 0, в журнале Hill Climbing причина Starvation.

Компилятор не генерирует машину состояний, а помечает метод флагом Async и вместо await вызывает AsyncHelpers.Await. JIT при реальной приостановке сам сохраняет живые переменные в цепочку объектов Continuation. Синхронный путь заметно дешевле (в наших замерах в 3–6 раз на .NET 10), приостановка на .NET 10 была дороже, на .NET 11 RC1 дешевле (160 против ~286 байт). На .NET 10 нужны флаг компилятора и DOTNET_RuntimeAsync=1, библиотека с флагом без переменной не загружается, а трасса стека теряет промежуточные кадры; на .NET 11 RC1 нужен только флаг, трасса полная (глава 14).

Thread.Sleep пулу ничего не сообщает: добавление потоков идёт по одному примерно раз в 500 мс. Task.Wait()/.Result на потоке пула вызывает ThreadPool.NotifyThreadBlocked (кооперативная блокировка), и пул быстро добавляет потоки: в нашем опыте 32 ожидания по секунде — 5,3 с и 33 потока, а с выключенной кооперативной блокировкой — 25,5 с. Это смягчает sync-over-async, но не лечит: потоки дороги (глава 13).

Зависит от содержимого, которое снаружи не видно. Если внутри готовое значение или Task, второй await «работает». Если внутри переиспользуемый источник (в том числе PoolingAsyncValueTaskMethodBuilder), второй await бросает InvalidOperationException (токен устарел) или, для источника без проверки, вернёт чужой результат. Контракт: ждать один раз; для повторного ожидания один раз вызвать AsTask() (глава 12).

Очередь живёт в памяти процесса. В опыте главы 17: 40 заказов поставлены в очередь, хост остановлен сразу — отправлено 0 из 40. Плюс один воркер обрабатывает задания последовательно. Если нельзя терять работу, нужна внешняя очередь или outbox, а Channel служит буфером перед ней.