⚡️ Утечка памяти, которую не видно до прода Channel<T> — это стандартный выбор для producer-consumer в .NET. Быстрее ConcurrentQueue, дружит с cancellation, не аллоцирует лишнего. Документация рекомендует. Коллеги используют. Дефолтный способ создать канал выглядит так: var channel = Channel.CreateUnbounded<WorkItem>(); Канал принимает записи бесконечно. Никаких исключений, никаких предупреждений, никаких логов. Пока producer пишет быстрее, чем consumer успевает читать, очередь просто растёт в хипе. В разработке нагрузка маленькая, producer и consumer держат примерно одинаковый темп. На проде, при трафике чуть выше нормы, разрыв может быть огромным. Microsoft сделала такой дефолт намеренно: в некоторых сценариях потеря записи хуже, чем рост памяти. Логирование, например. Но для платёжных событий или команд это выбор, который стоит делать осознанно, а не получать по умолчанию. Переходим на CreateBounded и явно выбираем поведение при переполнении: var channel = Channel.CreateBounded<WorkItem>( new BoundedChannelOptions(capacity: 500) { FullMode = BoundedChannelFullMode.Wait, SingleReader = true SingleWriter = false } ); BoundedChannelFullMode это настоящее архитектурное решение. Четыре варианта с разным поведением по отношению к потере данных: Wait — блокирует producer до появления места DropNewest — выбрасывает только что записанное DropOldest — выбрасывает самое старое DropWrite — возвращает false на TryWrite Как считать capacity capacity = пик записи в секунду × P99 время обработки в секундах × 2 Пример: 500 записей в секунду, p99 обработки 200 мс: capacity = 500 × 0.2 × 2 = 200 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор