Асинхронность в C#

Асинхронность в C# существует ради одного ресурса — потока. Пока синхронный вызов ждёт ответа от сети или диска, поток стоит на месте и ничего не делает, но продолжает занимать стек и место в пуле. await разрывает эту связь: он регистрирует продолжение, возвращает поток в пул, и тот обслуживает другие запросы, пока операция идёт своим ходом. Отсюда главный тезис, который проверяют на собеседованиях: асинхронность даёт пропускную способность и отзывчивость, но не скорость — сама операция быстрее не станет.

Специфика C# в том, что вся эта механика — работа компилятора, а не рантайма. Компилятор переписывает async-метод в машину состояний: локальные переменные становятся её полями, каждый await — точкой возобновления, а builder связывает машину с возвращаемой задачей. Отсюда и все ловушки темы, которые стоит назвать сразу: await не создаёт поток и не блокирует — но .Result блокирует и в UI-приложении даёт дедлок; ValueTask экономит выделение памяти, но ожидать его дважды нельзя; отмена кооперативна — CancellationToken не остановит ничего, пока вызываемый код сам его не проверит; async void не возвращает задачу, поэтому его исключение вызывающий поймать не может, и процесс падает. Разбор по слоям — ниже.

Карта темы

• async и await — что компилятор генерирует для async-метода, как await приостанавливает и возобновляет машину состояний и почему при этом не создаётся ни одного потока.
• Task и ValueTask — Task как дескриптор идущей операции, три терминальных состояния и когда структура ValueTask экономит выделение памяти.
• CPU-bound против I/O-bound — почему за вводом-выводом не стоит поток, что на самом деле делает Task.Run и как блокировка роняет пул потоков.
• Комбинаторы задач — Task.WhenAll и Task.WhenAny, чем они отличаются от блокирующих WaitAll/WaitAny и что происходит с проигравшими задачами.
• Отмена через CancellationToken — CancellationTokenSource как владелец сигнала, кооперативная проверка токена и состояние Canceled.
• Асинхронные потоки — IAsyncEnumerable<T>, await foreach и зачем итератору атрибут [EnumeratorCancellation].
• async void — почему метод без задачи нельзя ожидать, откуда берётся падение процесса и единственный законный сценарий.
• Исключения в async-коде — где живёт упавшее исключение, почему await бросает одно, а .Result — обёртку AggregateException, и как теряются сбои у неожидаемых задач.

Частые ошибки и ловушки

Значение для собеседований

Асинхронность — тема, на которой отсекают кандидатов на middle и senior. Проверяют не знание слов async и await, а модель исполнения: что происходит с потоком в момент приостановки, где живут локальные переменные после неё и кто вызывает продолжение. Кандидат, который говорит «await регистрирует продолжение и возвращает поток в пул, а машина состояний переезжает в кучу только при реальной приостановке», сразу отделяется от того, кто отвечает «await ждёт задачу».

Что обычно проверяют:

• Что делает компилятор с async-методом и как await возобновляет исполнение.
• Чем Task отличается от потока и в каких состояниях завершается.
• Когда ValueTask<T> уместен и почему его нельзя ожидать дважды.
• Почему await экономит поток на I/O и не экономит на вычислениях.
• Разницу WhenAll / WhenAny и что бросит await при нескольких сбоях.
• Кооперативную природу отмены и роль CancellationTokenSource.
• Почему async void — ловушка и где он всё же неизбежен.
• Как исключение попадает из async-метода в catch вызывающего.

Типичный неверный ответ: «await запускает операцию в фоновом потоке и ждёт его». Это сразу открывает разговор о том, что за асинхронным вводом-выводом вообще не стоит поток: запрос уходит устройству, а завершение приходит колбэком от ОС — поэтому тысяча одновременных запросов на сервере не стоит тысячи потоков. Второй классический провал — catch (AggregateException) вокруг await: он никогда не сработает, потому что обёртку разворачивает сам awaiter.