.NET и Владимир: отличный повод совместить митап и выходные в городе с историей

Офлайн-мероприятий для .NET-разработчиков сейчас не так много, а тут получается приятное комбо: встреча с другими разработчиками вечером в пятницу и возможность остаться на выходные в городе с историей.

В программе доклады от разработчиков Altenar и Рови Тех (часть Т-Банка):
— Async/await — асинхронность, которую можно читать.
— Как не терять данные при асинхронной интеграции программных систем.
— EF Core + PostgreSQL: за рамками CRUD.

Кстати, ещё на митапе запланированы активности для программистов: адаптации известных игр ("Сапер", "Крестики-нолики", "Гонки"), где для победы понадобится понимание математики и вероятностей.

Участие бесплатное, а ещё можно сэкономить на проезде — организаторы разыграют несколько билетов на "Ласточку" среди участников.

Для участия в розыгрыше:
1. Зарегистрируйтесь на митап.
2. Напишите «Хочу на .NET-митап на Ласточке» на почту aleksei.korneev@altenar.com с почты, указанной при регистрации.

Итоги розыгрыша подведём 14 сентября.

Регистрируйтесь, планируйте поездку и до встречи во Владимире!

⚡️ Задачи с технических собеседований в одном репозитории

Tech-OA-Interview-Questions - подборка задач из онлайн-тестирований и интервью в технологических компаниях. Пригодится для подготовки к алгоритмическим этапам отбора.

OA, или Online Assessment, - тестирование, которое кандидат обычно проходит перед собеседованиями. В репозитории собраны материалы для подготовки к таким заданиям, в том числе к отбору в Amazon.

Можно использовать как список для практики: решать задачи с таймером, оценивать сложность решения и проверять граничные случаи.

https://github.com/perixtar/Tech-OA-Interview-Questions

Согласны ?

🔧 Как передать многострочный PEM через Aspire в ASP.NET Core

Сертификаты и ключи в PEM содержат переносы строк, которые могут создавать проблемы при передаче через параметры Aspire. Damien Bod показал обходной вариант для локальной разработки с User Secrets и развёртывания в Azure.

Схема простая:

* закодировать PEM в однострочный Base64
* сохранить значение в конфигурации AppHost под ключом Parameters:ИмяПараметра
* объявить приватный ключ через AddParameter(..., secret: true)
* передать параметр приложению через WithEnvironment
* в ASP.NET Core декодировать Base64 обратно в исходный PEM

В статье есть helper-класс для преобразования, настройка AppHost и пример создания сертификата через X509Certificate2.CreateFromPem.

Base64 сохраняет переносы строк при передаче. Приватный ключ после кодирования остаётся секретом: Base64 не обеспечивает шифрование.

https://damienbod.com/2026/09/01/using-multiline-parameters-for-aspire-and-asp-net-core-with-user-secrets-and-azure-default-deployments/

# C# 14: конкурентный кеш без race condition

Реализуйте потокобезопасный кеш:

public sealed class AsyncCache<TKey, TValue>
    where TKey : notnull
{
    public Task<TValue> GetOrCreateAsync(
        TKey key,
        Func<CancellationToken, Task<TValue>> factory,
        CancellationToken cancellationToken = default)
    {
        // TODO
    }
}

Условия: если 100 потоков одновременно запросят один key, factory должна выполниться только один раз. Остальные ждут тот же Task. Если вычисление завершилось ошибкой - запись удаляется из кеша. Отмена одного клиента не должна отменять работу для остальных. Глобальный lock использовать нельзя.

Вопрос: как избежать race condition между созданием общего Task и удалением упавшего значения из кеша?

# C# 14: хитрая задача на ArrayPool, IAsyncEnumerable и время жизни памяти

Есть поток данных, из которого нужно читать сообщения построчно без лишних аллокаций.

Наивная реализация:

static async IAsyncEnumerable<ReadOnlyMemory<byte>> ReadLinesAsync(
    Stream stream,
    [EnumeratorCancellation] CancellationToken cancellationToken = default)
{
    byte[] buffer = ArrayPool<byte>.Shared.Rent(4096);

    try
    {
        while (true)
        {
            int read = await stream.ReadAsync(buffer, cancellationToken);

            if (read == 0)
                yield break;

            yield return buffer.AsMemory(0, read);
        }
    }
    finally
    {
        ArrayPool<byte>.Shared.Return(buffer);
    }
}

Использование:

await foreach (var data in ReadLinesAsync(stream))
{
    queue.Add(data);
}

Код компилируется и выглядит эффективно.

Но в production данные внутри queue иногда внезапно меняются или повреждаются.

## Вопрос

Почему?

---

# Проблема

ReadOnlyMemory<byte> не владеет памятью.

Он всего лишь указывает на:

byte[] buffer

А этот массив взят из:

ArrayPool<byte>.Shared

После следующего:

ReadAsync(buffer)

содержимое массива перезаписывается.

А после:

ArrayPool<byte>.Shared.Return(buffer);

массив вообще может получить другой поток.

Получается:

yield memory
    ↓
consumer сохраняет ссылку
    ↓
buffer переиспользуется
    ↓
старый ReadOnlyMemory показывает новые данные

Это логический аналог use-after-free, хотя runtime C# остаётся memory-safe.

---

# Задача

Исправьте API так, чтобы:

- использовался пул памяти;
- данные можно было безопасно хранить после yield;
- не происходило скрытого копирования каждого сообщения;
- consumer явно управлял временем жизни буфера;
- отмена работала через CancellationToken.

Подсказка: используйте

IMemoryOwner<byte>

---

# Один из вариантов решения

public sealed class Message : IDisposable
{
    private IMemoryOwner<byte>? _owner;

    public ReadOnlyMemory<byte> Data { get; }

    public Message(IMemoryOwner<byte> owner, int length)
    {
        _owner = owner;
        Data = owner.Memory[..length];
    }

    public void Dispose()
    {
        _owner?.Dispose();
        _owner = null;
    }
}

Чтение:

static async IAsyncEnumerable<Message> ReadAsync(
    Stream stream,
    [EnumeratorCancellation] CancellationToken cancellationToken = default)
{
    while (true)
    {
        IMemoryOwner<byte> owner =
            MemoryPool<byte>.Shared.Rent(4096);

        int read;

        try
        {
            read = await stream.ReadAsync(
                owner.Memory,
                cancellationToken);
        }
        catch
        {
            owner.Dispose();
            throw;
        }

        if (read == 0)
        {
            owner.Dispose();
            yield break;
        }

        yield return new Message(owner, read);
    }
}

Consumer:

await foreach (var message in ReadAsync(stream, ct))
{
    using (message)
    {
        Process(message.Data);
    }
}

Теперь память возвращается в pool только тогда, когда consumer закончил с сообщением.

---

# Главная ловушка

Даже такой код опасен:

ReadOnlyMemory<byte> saved;

await foreach (var message in ReadAsync(stream))
{
    using (message)
    {
        saved = message.Data;
    }
}

Console.WriteLine(saved.Length);

После Dispose() память больше не принадлежит consumer.

Сам ReadOnlyMemory<byte> технически существует, но использовать его содержимое уже нельзя.

---

# Вопрос уровня Senior

Как изменить API так, чтобы разработчику было сложнее случайно сохранить ReadOnlyMemory<byte> после Dispose()?

Дополнительно подумайте:

ArrayPool<T>
vs
MemoryPool<T>
vs
обычный byte[]

и ответьте, когда zero-copy действительно быстрее, а когда управление lifetime становится дороже простой копии.

Эта задача проверяет понимание Memory<T>, pooling, ownership, IAsyncEnumerable, cancellation и одной из самых неприятных категорий ошибок высокопроизводительного C# — когда GC защищает объект от удаления, но не защищает вас от повторного использования его содержимого.

🧩 C# Channels: сообщение попало в очередь. Почему обработчик его не получил?

Два воркера читают один ограниченный канал. Один из них отменяет ожидание. Продюсер успешно записывает сообщение — без исключений.

using System.Threading.Channels;

var queue = Channel.CreateBounded<int>(
    new BoundedChannelOptions(1)
    {
        FullMode = BoundedChannelFullMode.Wait
    });

using var cts = new CancellationTokenSource();

var firstRead = queue.Reader.ReadAsync().AsTask();

var firstWorker = Task.Run(async () =>
{
    try
    {
        var item = await firstRead.WaitAsync(cts.Token);
        Console.WriteLine($"A: {item}");
    }
    catch (OperationCanceledException)
    {
        Console.WriteLine("A: canceled");
    }
});

// Дожидаемся, чтобы первый воркер обработал отмену.
cts.Cancel();
await firstWorker;

var secondWorker = Task.Run(async () =>
{
    await foreach (var item in queue.Reader.ReadAllAsync())
        Console.WriteLine($"B: {item}");
});

await queue.Writer.WriteAsync(42);
queue.Writer.TryComplete();

await secondWorker;
await queue.Reader.Completion;

Console.WriteLine("Finished");

Разберите без запуска:

1. Что выведет программа? Возможны ли разные результаты?
2. Где окажется 42, если ни один воркер его не напечатает?
3. Почему Reader.Completion успешно завершится?
4. Чем отличаются эти две записи?

reader.ReadAsync().AsTask().WaitAsync(token)
reader.ReadAsync(token).AsTask()

Усложнение: отмена и запись происходят одновременно. Достаточно ли второй записи, чтобы гарантировать, что сообщение не потеряется?

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

👇 В какой момент ответственность за сообщение переходит от канала к воркеру?