Аллокации, которых нет в коде: охота на скрытый боксинг в .NET 10

Самая дорогая аллокация в вашем сервисе та, которой нет в исходниках. Вы написали struct ради zero-allocation, прошли code review, а в проде Gen0-коллекции все равно идут косяком. Потому что между вашим кодом и машинным кодом стоит компилятор, и он молча упаковывает ваш value-тип в кучу там, где вы этого не просили — а на код-ревью этого не видно.

TL;DR. Боксинг (boxing) в .NET - это не только object o = 42. Он прячется в вызовах интерфейсных методов на struct, в дефолтном ValueType.Equals, в params object[]-аргументах, в foreach по интерфейсу и в замыканиях. При этом часть “классических” примеров боксинга из старых гайдов на современном рантайме уже не аллоцирует — JIT научился их вырезать, и слепо копировать советы десятилетней давности вредно. Ниже — карта мест, где боксинг живёт и сейчас, отдельный разбор того, что рантайм уже оптимизировал, реальный мини-кейс, воспроизводимый бенчмарк на BenchmarkDotNet с MemoryDiagnoser, способ ловить упаковку через DOTNET_JitDisasm и dotnet-gcdump, и паттерны лечения без потери читаемости.

О версиях и числах. Всё прверялось на .NET 10 (текущий LTS) и C# 13/14-уровне компилятора, Release, без отладчика, BenchmarkDotNet с MemoryDiagnoser. На .NET 8/9 поведение в основном такое же, но отдельные оптимизации JIT отличаются между мажорными версиями — поэтому главный принцип статьи: не верьте на слово (в том числе мне), гоняйте MemoryDiagnoser на своей версии рантайма. Числа в таблицах ниже - иллюстративные, порядок величины, а не точные замеры с вашего железа.

Пролог: “у нас же всё на struct, откуда Gen0?”
Сервис на горячем пути считает метрики: миллионы маленьких readonly struct-значений в секунду, никакого new, никаких классов в hot path. По задумке — ноль аллокаций. На дашборде — стабильный поток Gen0-коллекций раз в несколько секунд под нагрузкой.

Профайлер показывает аллокации, но стек ведёт в метод, где в коде нет ни одного new. Там цикл по интерфейсу, пара вызовов .Equals(), передача значения в params-метод лога. Глазами — чисто. В машинном коде — box-инструкции на каждой итерации.

Это и есть скрытый боксинг: компилятор C# и JIT упаковывают ваш struct в объект на куче, потому что в конкретной точке кода value-тип нужно представить как ссылочный. Симптом — Gen0-коллекции “из ниоткуда”, и его не видно ни в code review, ни в дампе, пока не посмотришь на IL или дизасм.

Если тема близка - я регулярно разбираю такие штуки по C# и .NET (внутренности рантайма, перформанс, неочевидные грабли с замерами и дизасмом) в своём Telegram-канале: t.me/csharp_ci. Заходите, если интересно копаться глубже.

Что такое боксинг и почему он стоит дорого
Боксинг — это упаковка value-типа (struct, enum, примитив) в объект на управляемой куче. Рантайму нужно выделить заголовок объекта, скопировать туда значение и вернуть ссылку. Анбоксинг - обратная операция с проверкой типа.

Цена не в самой инструкции, а в последствиях: каждая упаковка - это аллокация в Gen0. Много мелких аллокаций на горячем пути означают частые Gen0-коллекции, паузы (пусть и короткие), вытеснение полезных данных из кэша и общий рост CPU на ровном месте. На сервисе с SLA по p99 это бьёт по хвосту латентности так же, как и любая другая лишняя аллокация.

В IL боксинг виден явно - инструкция box. Именно её мы и будем искать.

Читать дальше: https://habr.com/ru/articles/1049236/

Тест прошёл. А PostgreSQL вообще в курсе?

Интеграционные тесты часто выглядят надёжно ровно до того момента, пока приложение не встречается с настоящей базой.

На локалке всё зелёное. В CI всё зелёное. Моки довольны. In-memory база тоже не против. А потом в проде внезапно выясняется, что реальный PostgreSQL иначе обрабатывает запрос, constraint не даёт сохранить данные, транзакция ведёт себя не так, как ожидалось, а Redis показывает проблему, которую тесты вообще не могли поймать.

Именно поэтому Testcontainers в .NET так хорошо заходят для интеграционных тестов. Вместо имитации базы вы поднимаете настоящий PostgreSQL, Redis или другой сервис в Docker-контейнере, прогоняете приложение против реальной зависимости и удаляете контейнер после тестов.

Это даёт намного больше уверенности, чем тесты против подмены. При этом не нужен общий тестовый сервер, который кто-то сломал, не почистил или настроил иначе.

В хорошей схеме контейнеры запускаются через fixture, приложение получает connection string динамически, версии образов фиксируются, а настройка прячется за небольшими helper-классами. Сам тест при этом остаётся читаемым: он проверяет бизнес-сценарий, а не превращается в простыню из настройки базы и очистки состояния.

Есть важный нюанс. Общие fixtures ускоряют тесты, но требуют дисциплины со shared state. Когда изоляция важнее скорости, лучше использовать отдельные fixtures и не ловить фантомные падения из-за данных, оставшихся от соседнего теста.

Мне нравится этот подход именно за баланс. Вы тестируете не идеальную игрушечную модель приложения, а поведение, максимально близкое к реальному окружению. Но без боли ручной инфраструктуры.

Поэтому в следующий раз, когда интеграционный тест прошёл против in-memory базы, стоит задать неприятный вопрос: а настоящая база с ним согласится?

Совет по .NET Aspire: не воспринимайте его только как удобную локальную панель.

Самая полезная часть начинается, когда у приложения появляется инфраструктура: API, Postgres, Redis, фоновые сервисы, переменные окружения и connection strings.

Вместо того чтобы вручную собирать docker-compose.yml, опишите сервисы в AppHost. Aspire Docker publisher сможет сгенерировать Compose-артефакты из этой модели.

Но важно понимать границу: Aspire не деплоит приложение за вас.

Он не заменяет CI/CD, не управляет секретами и не переносит контейнеры на сервер. Вам всё равно нужно собрать image, задать реальные env-переменные, скопировать файлы и запустить Docker Compose.

Зато это хороший баланс: меньше ручной YAML-рутины, но без магии, которая скрывает реальную схему деплоя.

Задачка C#

Зачем указывать RunContinuationsAsynchronously у TaskCompletionSource?

A - Чтобы продолжения выполнялись синхронно при SetResult

B - Чтобы не исполнять продолжения синхронно в потоке SetResult, а планировать их асинхронно, избегая дедлоков и глубоких стеков

C- Чтобы запретить отмену задач

D- Чтобы обойти планировщик и ускорить завершение

Классическая задача на собеседовании: вывести бинарное дерево по уровням.

На входе дерево:

1
2 3
4 5 6

Нужно не просто пройти узлы, а напечатать каждый уровень с новой строки.

Первое, что вспоминается, это BFS. Для обхода в ширину идеально подходит Queue<T>: кладём корень, достаём узел, добавляем его детей, повторяем.

Так легко получить порядок:

1 2 3 4 5 6

Но настоящая часть задачи начинается дальше: как понять, где закончился уровень?

Есть два нормальных варианта:

• хранить вместе с узлом его уровень
• на каждой итерации брать queue.Count и обрабатывать ровно столько узлов текущего уровня

Второй способ часто чище: размер очереди в начале цикла и есть количество элементов на текущем уровне.

Такие задачи редко проверяют «знание деревьев ради деревьев».

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

Для C# это отличный мини-тест на мышление, работу с Queue<T> и понимание алгоритмов без магии фреймворков.

Globbing. - это удобный способ искать файлы по маскам, без ручного перебора папок и костылей со строками.

Например:

**/*.cs - все C# файлы во всех вложенных папках
wwwroot/**/*.js - все JS-файлы внутри wwwroot
!bin/** и !obj/** - исключить мусорные директории сборки

Где это полезно:

• генерация списков файлов
• поиск конфигов
• обработка шаблонов
• сборка ассетов
• утилиты для проектов
• backend/frontend tooling

Это не Regex. Globbing проще, читаемее и отлично подходит для файловой структуры.

Backend пример:
https://github.com/karenpayneoregon/vs2026-how-to/blob/f1c136c864b05ec9eec91e120997314d978b0966/CommonLibrary/GlobbingOperations.cs?plain=1#L6C15-L6C15

Frontend пример:
https://github.com/karenpayneoregon/vs2026-how-to/blob/f1c136c864b05ec9eec91e120997314d978b0966/ExperimentsApp/Classes/GlobbingCode.cs?plain=1#L20C37-L20C37

# C# record: что выведет код?

На собеседованиях record часто объясняют как «сравнение по значению». Но есть нюанс, который легко пропустить.

public record User(string Name, List<string> Roles);

var u1 = new User("Alice", new List<string> { "admin" });

var u2 = u1 with { };

u2.Roles.Add("owner");

Console.WriteLine(u1 == u2);
Console.WriteLine(string.Join(", ", u1.Roles));
Console.WriteLine(ReferenceEquals(u1.Roles, u2.Roles));

Что будет в консоли?

True
admin, owner
True

Почему так?

with для record делает не глубокую копию, а поверхностную. Сам объект User скопировался, но List<string> внутри остался тем же самым объектом в памяти.

Поэтому изменение u2.Roles меняет и u1.Roles.

И сравнение тоже остаётся True, потому что оба record указывают на один и тот же список.

Вот почему record не делает модель автоматически immutable. Он только упрощает синтаксис и даёт value-based equality. Если внутри лежат изменяемые reference-типы, их всё равно можно случайно протащить в состояние.

Более безопасный вариант:

public record User(string Name, IReadOnlyList<string> Roles);

А для строгой неизменяемости лучше смотреть в сторону immutable collections.

Godot фактически запрещает vibe coding в контрибуциях.

Причина простая: PR стало легче генерировать, но не легче проверять. Для open-source движка каждый патч всё равно должен разобрать мейнтейнер, который понимает архитектуру, риски и последствия изменений.

Теперь автономные агенты, крупные AI-сгенерированные куски кода и сгенерированный текст в issues, proposals и PR-дискуссиях запрещены. Разрешены только мелкие помощники вроде автодополнения, regex и find/replace. Помощь AI в коде нужно раскрывать.

На практике правило будет сложно применять: почти невозможно наверняка доказать, где был vibe coding, а где обычная работа разработчика.

Godot защищает не стиль разработки, а время ревьюеров. Код можно сгенерировать за минуты, но ответственность за него всё равно остаётся на людях.

godotengine.org/article/contribution-policy-2026/

Ты не твой стек

Зачем учиться новому, когда по самое колено в практике? Не страшно, что всё больше джунов работают наравне с сеньёрами?

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

Метафизика? Нет - математика.

Языки и фреймворки устаревают за 5–10 лет, стеки обновляются радикально. А способ мышления, которым ты пользуешься, чтобы разложить сложную задачу на части, остаётся с тобой навсегда.

Именно об этом курс: "Философия, математика и компьютерные науки"

Не про конкретный стек, а про то, как в принципе думать о сложных системах с опорой на философию, математику и системную инженерию.

Формат:
9 месяцев, 10 модулей, теория и практика, несколько очных сессий в Петербурге.

Кураторы:
- Андрей Родин — доктор философских наук, философ науки и математики
- Илья Егорычев — доктор философских наук, математик и логик, Soulmaths
- Вячеслав Шириков — системный архитектор, техдиректор ГК «Лартех»

До 21 июля действует скидка за раннюю регистрацию.
Программа и условия

G# — новый язык для .NET с синтаксисом ближе к Go, Kotlin и Swift.

Идея не в том, чтобы заменить C#, а в том, чтобы дать более компактный язык поверх той же CLR.

Что обещают:

• компиляция в обычные managed .NET assemblies

• совместимость с BCL, NuGet, MSBuild и dotnet tooling

• interop с C#-кодом

• null-safety через T?, nil, ?., ??, if let и guard let

• data classes со structural equality, copy-with и deconstruction

• async/await поверх Task и Task[T]

• опциональные Go-подобные go, chan, select

• REPL / script runner через gsi

• C# → G# мигратор через cs2gs

Самая интересная часть — G# не пытается строить новый рантайм. Он просто использует существующую .NET-экосистему и меняет язык входа: меньше исторического багажа C#, больше предсказуемой синтаксической поверхности.

Но важно: проект пока pre-1.0. Версия 0.3 — это скорее milestone по реализации и interop, а не гарантия стабильности языка.

Для продакшена рано. Для тех, кто следит за экспериментами вокруг .NET-языков, очень любопытно.

Статья: https://www.linkedin.com/pulse/meet-g-modern-net-language-go-kotlin-swift-ergonomics-david-obando-lwofc/

TIME_WAIT в Linux годами объясняют неправильно

Я полез в исходники Linux TCP и снова наткнулся на старый сетевой миф.

В коде TIME_WAIT фактически зафиксирован на 60 секунд:
#define TCP_TIMEWAIT_LEN (60 * HZ)
Его нельзя настроить отдельно для сокета.

И да, tcp_fin_timeout, который часто советуют крутить в блогах, не управляет TIME_WAIT.

Он относится к состоянию FIN_WAIT2.

TIME_WAIT задан в исходниках ядра и не вынесен в отдельный sysctl.

Вот так появляются мифы: один параметр звучит похоже, его копируют из статьи в статью, а потом годами лечат не то состояние TCP.

Vertical Slice Architecture хороша тем, что перестаёт заставлять код жить “по этажам”.

В классической слоистой архитектуре фича часто размазана по всему проекту: endpoint в одном месте, request/response в другом, validator где-то рядом, handler отдельно, репозиторий ещё ниже. Чтобы понять одну бизнес-операцию, приходится прыгать по папкам как по квесту.

В vertical slice подход другой: одна фича — один самостоятельный срез.

Например, CreateProduct может хранить рядом всё, что нужно именно для создания продукта:
request, response, validator, endpoint и handler с бизнес-логикой.

Не потому что “так модно”, а потому что это проще сопровождать.

Открыл срез - сразу видишь, что принимает API, что возвращает, как валидирует входные данные и что реально делает. Меньше магии, меньше лишней навигации, меньше риска случайно сломать соседнюю фичу.

Для больших проектов это очень удобно: код начинает группироваться не вокруг технических слоёв, а вокруг бизнес-сценариев.

И это, кажется, главный плюс VSA.

Архитектура становится ближе к тому, как продукт реально работает.

🔥 Вышел .NET 11 Preview 6.

Это уже шестой превью-релиз .NET 11, и он выглядит не как “пара мелких фиксов”, а как большой проход по всему стеку: Runtime, SDK, Libraries, ASP.NET Core, MAUI, C#, EF Core, F#, контейнеры. Microsoft прямо перечисляет улучшения во всех этих направлениях.

Самое интересное для backend-разработчиков:

* улучшения JIT и runtime async performance
* in-process crash report logging
* faster interface dispatch для NativeAOT
* новые SIMD API
* dotnet test получает новые опции и улучшенный вывод
* container publishing теперь поддерживает multi-arch builds с Podman

В C# продолжают двигать union types: System.Text.Json уже умеет сериализовать C# union types, а support types для unions теперь идут “из коробки”. Ещё появился пункт про extension indexers.

В ASP.NET Core тоже много практичных вещей: async validation для minimal APIs, автоматическая CSRF-защита для cross-origin сценариев, OpenAPI 3.2 по умолчанию, unions в ASP.NET Core, обновления SignalR и short-circuit endpoints через attribute.

EF Core получил улучшения LINQ query translation, migrations, Cosmos DB provider и поддержку ключей/индексов через complex-type properties.

Для меня главный сигнал Preview 6 такой: .NET 11 явно допиливают не только как runtime, а как цельную платформу для production-разработки: performance, NativeAOT, контейнеры, web API, тесты и tooling двигаются вместе.

Ставить в прод пока рано, но смотреть и пробовать уже есть что.

https://devblogs.microsoft.com/dotnet/dotnet-11-preview-6/

Microsoft показала Microsoft.UI.Reactor - экспериментальный open-source проект, который переосмысляет разработку WinUI 3-приложений.

Инструмент позволяет писать нативные Windows-приложения декларативно на C#, без привычной связки XAML + code-behind + view models. UI описывается как функция состояния, а Reactor сам синхронизирует экран с изменениями.

Что это даёт:

* меньше split между разметкой и логикой
* проще управлять state
* компоненты выглядят ближе к React-подходу
* вся структура приложения остаётся в C#
* можно быстрее собирать и менять UI

Проект пока экспериментальный. В README он описан как набор расширений для WinUI 3, а публичный preview-пакет уже доступен через NuGet; шаблон проекта пока ставится из исходников.

На фоне того, что WinUI 3 остаётся рекомендуемым нативным UI-фреймворком для новых Windows desktop-приложений, Reactor выглядит как попытка сделать Windows-разработку более современной и менее тяжёлой.

Это интересный эксперимент: каким мог бы быть WinUI, если бы его проектировали под декларативный C# и component-driven разработку.

build.microsoft.com/en-US/sessions/OD854?source=sessions

Unity представила Unity CLI - инструмент, который позволяет ИИ-агентам напрямую работать с игровыми проектами.

Агент может:

- изменять объекты и компоненты в сценах;
- искать причины ошибок;
- исправлять баги;
- запускать сборку проекта;
- проверять, действительно ли исправление сработало.

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

Получается почти полноценный ИИ-разработчик: получил задачу, изучил проект, внёс изменения и протестировал результат — всё через терминал.

Инструмент доступен бесплатно.

Подробнее: https://unity.com/blog/meet-the-unity-cli

#unity #gamedev #ai #vibecoding