🚀 ASP.NET Core в 2026: если не знаешь это - ты отстал
Одна картинка закрывает почти весь стек, который реально нужен в проде. Без воды и устаревших практик.
Сейчас ASP.NET Core уже не про «сделать API», а про систему: от роутинга и DI до очередей, кешей и realtime. Если ты всё ещё пишешь просто контроллеры и думаешь, что этого достаточно - плохие новости.
Что важно:
• основа осталась той же, но усложнился прод
• логирование и мониторинг теперь обязательны
• кеш без стратегии уже не спасает
• без resilience и retry твой сервис падает при первой же проблеме
Отдельно бросается в глаза тренд:
минимум магии, максимум контроля
ручной mapping вместо AutoMapper
явная архитектура вместо «оно само работает»
И ещё момент, который многие игнорят:
• экосистема вокруг стала важнее самого фреймворка
• Redis, Kafka, OpenAPI, gRPC, SignalR - это уже не «дополнительно», это база
Если коротко:
ASP.NET Core сейчас это не про backend
это про сборку полноценной распределённой системы
И вопрос уже не в том, знаешь ли ты .NET
а в том, умеешь ли ты строить сервисы, которые живут под нагрузкой
Одна картинка закрывает почти весь стек, который реально нужен в проде. Без воды и устаревших практик.
Сейчас ASP.NET Core уже не про «сделать API», а про систему: от роутинга и DI до очередей, кешей и realtime. Если ты всё ещё пишешь просто контроллеры и думаешь, что этого достаточно - плохие новости.
Что важно:
• основа осталась той же, но усложнился прод
• логирование и мониторинг теперь обязательны
• кеш без стратегии уже не спасает
• без resilience и retry твой сервис падает при первой же проблеме
Отдельно бросается в глаза тренд:
минимум магии, максимум контроля
ручной mapping вместо AutoMapper
явная архитектура вместо «оно само работает»
И ещё момент, который многие игнорят:
• экосистема вокруг стала важнее самого фреймворка
• Redis, Kafka, OpenAPI, gRPC, SignalR - это уже не «дополнительно», это база
Если коротко:
ASP.NET Core сейчас это не про backend
это про сборку полноценной распределённой системы
И вопрос уже не в том, знаешь ли ты .NET
а в том, умеешь ли ты строить сервисы, которые живут под нагрузкой
Forwarded from C# (C Sharp) programming
Please open Telegram to view this post
VIEW IN TELEGRAM
Что выведет код?
Правильный ответ: 22
Почему: выражение считается слева направо. Сначала x++ возвращает 10, но потом увеличивает x до 11. Затем ++x сначала увеличивает x до 12, потом возвращает 12. В итоге 10 + 12 = 22.
using System;
class Program
{
static void Main()
{
int x = 10;
Console.WriteLine(x++ + ++x);
}
}
Правильный ответ: 22
Почему: выражение считается слева направо. Сначала x++ возвращает 10, но потом увеличивает x до 11. Затем ++x сначала увеличивает x до 12, потом возвращает 12. В итоге 10 + 12 = 22.
Раньше в .NET для идентификаторов чаще всего использовали обычный
Guid.NewGuid().Проблема в том, что классический UUID случайный. Для уникальности это удобно, но для базы данных - не всегда.
Когда значения генерируются хаотично, новые записи вставляются в разные части индекса. Отсюда:
- больше фрагментации
- дороже вставки
- чаще перестраиваются страницы индекса
- хуже поведение на больших таблицах
Поэтому многие разработчики начали использовать ULID.
ULID состоит из двух частей:
- timestamp
- random
За счет timestamp такие ID сортируются по времени, а значит база может вставлять новые записи более последовательно.
Но начиная с .NET 9 появился встроенный вариант:
Guid.CreateVersion7()UUID v7 тоже содержит временную часть, поэтому лучше подходит для индексируемых ключей, чем полностью случайный UUID.
Главное отличие:
ULID - отдельный формат и часто сторонняя библиотека.UUID v7 - обычный Guid, который уже поддерживается в .NET.Для новых проектов это выглядит как более разумный дефолт:
- не
Guid.NewGuid()- не отдельный ULID-пакет
- а
Guid.CreateVersion7()Особенно если
Guid используется как primary key в базе.Please open Telegram to view this post
VIEW IN TELEGRAM
Представьте: через четыре месяца вы открываете чужой .NET-проект и читаете его как книгу.
IServiceCollection не вызывает ступора.
async Task<IActionResult> пишется на автомате. Вы точно знаете, почему EF Core сгенерировал именно такой SQL - и как переписать запрос, чтобы он летал.Это не фантазия. Это результат после 16 модулей, в которых каждая концепция объясняется через код и закрепляется практикой.
ООП, SOLID, LINQ, async/await, DI, EF Core, ASP.NET Core, Docker, Kubernetes - всё, что казалось магией, станет рабочим инструментом.А бонусом - портфолио проектов: от CLI-утилит и REST API до собственного SaaS с multi-tenancy, JWT и деплоем в Kubernetes под TLS.
Скидка - 58% доступна 48 часов: https://stepik.org/a/282984/
Please open Telegram to view this post
VIEW IN TELEGRAM
⏱️ Ускоряем async-код в C#: не просто await, а нормальная параллельность
Одна из частых ошибок в C# - писать независимые асинхронные операции так, будто они зависят друг от друга:
Выглядит нормально, но по факту это последовательное выполнение.
Если каждый запрос занимает примерно 1 секунду, весь блок будет выполняться около 3 секунд. Не потому что async медленный, а потому что мы сами заставили код ждать каждый шаг по очереди.
Правильнее запускать независимые операции сразу:
Теперь все запросы стартуют одновременно, а общее время будет примерно равно самому долгому из них.
Но есть важный нюанс.
Task.WhenAll не делает CPU-код магически параллельным. Он особенно полезен для I/O-bound задач:
- запросы в базу
- HTTP-вызовы
- чтение файлов
- обращения к внешним API
- независимые операции с сетью
И ещё один момент: после WhenAll лучше доставать результаты уже из завершённых задач:
Так код остаётся читаемым, ошибки нормально пробрасываются, а логика не превращается в кашу.
Async/await сам по себе не ускоряет код. Он просто даёт возможность не блокировать поток. Ускорение появляется тогда, когда вы правильно запускаете независимые операции вместе, а не ждёте их по одной.
Одна из частых ошибок в C# - писать независимые асинхронные операции так, будто они зависят друг от друга:
await GetUserAsync();
await GetOrdersAsync();
await GetRecommendationsAsync();
Выглядит нормально, но по факту это последовательное выполнение.
Если каждый запрос занимает примерно 1 секунду, весь блок будет выполняться около 3 секунд. Не потому что async медленный, а потому что мы сами заставили код ждать каждый шаг по очереди.
Правильнее запускать независимые операции сразу:
var userTask = GetUserAsync();
var ordersTask = GetOrdersAsync();
var recsTask = GetRecommendationsAsync();
await Task.WhenAll(userTask, ordersTask, recsTask);
Теперь все запросы стартуют одновременно, а общее время будет примерно равно самому долгому из них.
Но есть важный нюанс.
Task.WhenAll не делает CPU-код магически параллельным. Он особенно полезен для I/O-bound задач:
- запросы в базу
- HTTP-вызовы
- чтение файлов
- обращения к внешним API
- независимые операции с сетью
И ещё один момент: после WhenAll лучше доставать результаты уже из завершённых задач:
var user = await userTask;
var orders = await ordersTask;
var recs = await recsTask;
Так код остаётся читаемым, ошибки нормально пробрасываются, а логика не превращается в кашу.
Async/await сам по себе не ускоряет код. Он просто даёт возможность не блокировать поток. Ускорение появляется тогда, когда вы правильно запускаете независимые операции вместе, а не ждёте их по одной.
Практическое руководство по росту в C#-разработке. Материал собран для тех, кто хочет получить инженерную глубину, а не просто накликать CRUD по туториалам.
Здесь последовательность изучения, лучшие практики, ресурсы и трезвый разбор того, как работать с ИИ-инструментами и оставаться востребованным.
https://github.com/Develp10/Csharp_Roadmap/
Please open Telegram to view this post
VIEW IN TELEGRAM
Форма логина и JWT-токен — ещё не безопасность приложения. На практике ошибки в аутентификации и авторизации становятся причиной утечек данных, проблем с доступом и уязвимостей, которые сложно обнаружить до выхода системы в production.
26 мая в 20:00 МСК приглашаем вас на открытый урок курса «C# ASP.NET Core-разработчик». На занятии разберём, как в ASP.NET Core устроены pipeline, middleware и схемы аутентификации. Покажем, как правильно использовать JWT, cookies, claims, роли и policy-based авторизацию для гибкого и безопасного контроля доступа.
Отдельно обсудим типичные ошибки, которые встречаются в production: небезопасное хранение токенов, ошибки настройки схем и проблемы в логике авторизации. Урок будет полезен .NET-разработчикам, которые хотят систематизировать знания по безопасности веб-приложений и увереннее работать с ASP.NET Core в реальных проектах.
Регистрация уже открыта: https://otus.pw/tDF66/?erid=2W5zFGbdS73
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
26 мая в 20:00 МСК приглашаем вас на открытый урок курса «C# ASP.NET Core-разработчик». На занятии разберём, как в ASP.NET Core устроены pipeline, middleware и схемы аутентификации. Покажем, как правильно использовать JWT, cookies, claims, роли и policy-based авторизацию для гибкого и безопасного контроля доступа.
Отдельно обсудим типичные ошибки, которые встречаются в production: небезопасное хранение токенов, ошибки настройки схем и проблемы в логике авторизации. Урок будет полезен .NET-разработчикам, которые хотят систематизировать знания по безопасности веб-приложений и увереннее работать с ASP.NET Core в реальных проектах.
Регистрация уже открыта: https://otus.pw/tDF66/?erid=2W5zFGbdS73
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
Большой русскоязычный roadmap по машинному обучению: от первого import numpy до LLM, RAG, fine-tuning, AI-агентов и MLOps и даже вабкодинга.
Внутри нормальная структура: что учить, в каком порядке, зачем это нужно и что должно получиться на практике после каждого этапа.
Roadmap разбит на 7 треков:
1. Фундамент: Python, математика, статистика, инструменты
2. Классический ML: scikit-learn, табличные данные, метрики, валидация
3. Deep Learning: PyTorch, CNN, RNN, training loop
4. LLM и трансформеры: attention, KV-cache, RAG, LoRA, агенты
5. Generative AI: изображения, видео, аудио, мультимодальность
6. MLOps и прод: Docker, Kubernetes, CI/CD, monitoring, serving
7. Специализация: CV, NLP, RecSys, RL, Safety
Roadmap не продаёт иллюзию “обучил модель - стал ML-инженером”.
В реальной работе много времени уходит на данные, метрики, деплой, мониторинг, воспроизводимость и разбор ошибок. Модель - только часть системы.
Хорошая мысль из roadmap: LLM не делает джуна сеньором. Она ускоряет того, кто уже понимает базу. Без базы человек просто становится оператором Copilot, который не может объяснить, почему всё сломалось.
По времени тоже без сказок:
1. 0-3 месяца: математика, классический ML
2. 3-6 месяцев: Deep Learning и PyTorch
3. 6-12 месяцев: LLM, RAG, fine-tuning, AI-агенты
4. 12+ месяцев: MLOps, прод, масштабирование, специализация
Тут же собрано 7 болших бесплатных курсов по машинному обучению, математике и вайбкодингу!
Если давно хотели зайти в ML системно, а не прыгать между роликами про ChatGPT, Stable Diffusion и “топ-10 библиотек”, это хороший ориентир.
https://github.com/justxor/MachineLearningRoadmap
Please open Telegram to view this post
VIEW IN TELEGRAM
TL;DR. Один foo.GetAsync().Result внутри middleware превращает ASP.NET Core, державший 50k RPS на p99 = 40 мс, в сервис на 12k RPS с p99 = 4 с при CPU 8 %. Виноват не блокирующий вызов сам по себе.
Виноват hill-climbing: фидбэк-луп в ThreadPool, внутри которого живёт дискретное преобразование Фурье.
Разбираемся по исходникам CoreCLR, как это работает, воспроизводим эффект на ~80 строках кода и показываем, почему SetMinThreads это не лечение, а анестезия.
https://habr.com/ru/articles/1040804/
Please open Telegram to view this post
VIEW IN TELEGRAM
🐳 «Используй Testcontainers вместо in-memory» - это только половина правды
Все уже выучили: EF Core InMemory provider - не интеграционный тест.
Он не ловит:
- баги в LINQ-трансляции
- ограничения БД
- коллации
- реальные типы колонок
- поведение конкретного SQL-провайдера
Окей, заменили на реальный PostgreSQL через Testcontainers. Победа? Не совсем.
Вот что начинается дальше.
1. Вы получили «медленное враньё» вместо «быстрого»
Поднимать контейнер на каждый тест-класс - быстрый способ превратить CI из 30 секунд в 8 минут.
Нормальный вариант:
- один контейнер на всю тестовую сессию
- изоляция данных между тестами через Respawn
- без пересоздания базы и контейнера каждый раз
Respawn чистит таблицы с учётом графа foreign keys за миллисекунды.
2. Транзакционный откат ≠ реальный сценарий
Трюк «обернули тест в транзакцию и откатили» красиво выглядит, но ломается, когда в коде есть:
- свои транзакции
- несколько SaveChanges
- фоновые операции
- поведение, завязанное на commit
В итоге тестируется сценарий, которого в проде нет.
3. Самая коварная ловушка - общий DbContext
Если тест и код используют один экземпляр DbContext, EF может вернуть данные из change tracker, а не из базы.
Тест зелёный, но он врёт: реальный SQL-запрос мог вообще не выполниться.
Между Act и Assert стоит чистить трекер:
4. Бонус, который теряют 90% команд - тест миграций
Реальная БД позволяет прогнать EF-миграции на чистой схеме.
Если миграция падает или схема разъехалась с моделью, вы узнаёте об этом в CI, а не в проде в пятницу вечером.
Пример базового подхода:
Testcontainers - это не галочка «best practice», а смена философии.
Без нормальной изоляции данных вы просто пересели с быстрого вранья на медленное.
А как вы изолируете состояние БД между интеграционными тестами - Respawn, транзакции или пересоздание контейнера?
#dotnet #csharp #testing #efcore
Все уже выучили: EF Core InMemory provider - не интеграционный тест.
Он не ловит:
- баги в LINQ-трансляции
- ограничения БД
- коллации
- реальные типы колонок
- поведение конкретного SQL-провайдера
Окей, заменили на реальный PostgreSQL через Testcontainers. Победа? Не совсем.
Вот что начинается дальше.
1. Вы получили «медленное враньё» вместо «быстрого»
Поднимать контейнер на каждый тест-класс - быстрый способ превратить CI из 30 секунд в 8 минут.
Нормальный вариант:
- один контейнер на всю тестовую сессию
- изоляция данных между тестами через Respawn
- без пересоздания базы и контейнера каждый раз
Respawn чистит таблицы с учётом графа foreign keys за миллисекунды.
2. Транзакционный откат ≠ реальный сценарий
Трюк «обернули тест в транзакцию и откатили» красиво выглядит, но ломается, когда в коде есть:
- свои транзакции
- несколько SaveChanges
- фоновые операции
- поведение, завязанное на commit
В итоге тестируется сценарий, которого в проде нет.
3. Самая коварная ловушка - общий DbContext
Если тест и код используют один экземпляр DbContext, EF может вернуть данные из change tracker, а не из базы.
Тест зелёный, но он врёт: реальный SQL-запрос мог вообще не выполниться.
Между Act и Assert стоит чистить трекер:
Db.ChangeTracker.Clear();
4. Бонус, который теряют 90% команд - тест миграций
Реальная БД позволяет прогнать EF-миграции на чистой схеме.
Если миграция падает или схема разъехалась с моделью, вы узнаёте об этом в CI, а не в проде в пятницу вечером.
Пример базового подхода:
public class IntegrationTestBase : IAsyncLifetime
{
private static readonly PostgreSqlContainer _db =
new PostgreSqlBuilder()
.WithImage("postgres:16-alpine")
.Build();
private Respawner _respawner = null!;
protected AppDbContext Db = null!;
public async Task InitializeAsync()
{
await _db.StartAsync();
var options = new DbContextOptionsBuilder<AppDbContext>()
.UseNpgsql(_db.GetConnectionString())
.Options;
Db = new AppDbContext(options);
// Реальные миграции - заодно проверяем, что они накатываются
await Db.Database.MigrateAsync();
await using var conn = new NpgsqlConnection(_db.GetConnectionString());
await conn.OpenAsync();
_respawner = await Respawner.CreateAsync(conn, new RespawnerOptions
{
DbAdapter = DbAdapter.Postgres,
SchemasToInclude = ["public"]
});
}
// Сброс данных перед каждым тестом - без пересоздания контейнера
protected async Task ResetAsync()
{
await using var conn = new NpgsqlConnection(_db.GetConnectionString());
await conn.OpenAsync();
await _respawner.ResetAsync(conn);
// Иначе тест может читать из кеша, а не из БД
Db.ChangeTracker.Clear();
}
public Task DisposeAsync() => Task.CompletedTask;
}
Testcontainers - это не галочка «best practice», а смена философии.
Без нормальной изоляции данных вы просто пересели с быстрого вранья на медленное.
А как вы изолируете состояние БД между интеграционными тестами - Respawn, транзакции или пересоздание контейнера?
#dotnet #csharp #testing #efcore
Если в приложении нужно обрабатывать поток данных от продюсеров к потребителям, первым делом вспоминают про очереди или ConcurrentQueue. Но в асинхронном мире этого мало. Поэтому в .NET есть каналы.
Канал устроен как пара из продюсера и потребителя. Когда продюсер пишет элемент в канал, он либо сразу уходит к потребителю, либо ждёт, если очередь переполнена. Потребитель, в свою очередь, может ждать новые элементы без блокировки потоков — всё работает на async/await.
Главная сила каналов — балансировка нагрузки.
Ограниченные каналы позволяют держать под контролем количество элементов. Это защищает приложение от перегрузки: если продюсер работает быстрее, чем потребитель, система сама притормозит поток данных.
Неограниченные каналы — вариант попроще, они всегда принимают новые элементы, но это может обернуться непредсказуемым ростом памяти.
Мини-пример:
var channel = Channel.CreateBounded<int>(5);
// producer
_ = Task.Run(async () =>
{
for (int i = 0; i < 10; i++)
{
await channel.Writer.WriteAsync(i);
Console.WriteLine($"Produced {i}");
}
channel.Writer.Complete();
});
// consumer
await foreach (var item in channel.Reader.ReadAllAsync())
{
Console.WriteLine($"Consumed {item}");
}
Почему это лучше, чем ConcurrentQueue? Потому что Channel создан сразу с учётом асинхронности. Вам не нужно городить блокировки и таймеры ожидания — достаточно написать
await reader.ReadAsync(), и код будет сам по себе масштабироваться без блокировки потоков.#sharp_view
Please open Telegram to view this post
VIEW IN TELEGRAM
Задача по .NET: зачем нужен IHttpClientFactory?
Есть сервис, который ходит во внешний API:
Регистрация:
Вопрос: почему это лучше, чем создавать
Потому что
А
Есть сервис, который ходит во внешний API:
public sealed class PaymentApiClient
{
private readonly HttpClient _http;
public PaymentApiClient(HttpClient http)
{
_http = http;
}
public async Task<string> GetStatusAsync(string id, CancellationToken ct)
{
using var response = await _http.GetAsync($"/payments/{id}", ct);
response.EnsureSuccessStatusCode();
return await response.Content.ReadAsStringAsync(ct);
}
}
Регистрация:
builder.Services.AddHttpClient<PaymentApiClient>(client =>
{
client.BaseAddress = new Uri("https://payments.example.com");
client.Timeout = TimeSpan.FromSeconds(10);
})
.ConfigurePrimaryHttpMessageHandler(() => new SocketsHttpHandler
{
PooledConnectionLifetime = TimeSpan.FromMinutes(5),
MaxConnectionsPerServer = 50
});
Вопрос: почему это лучше, чем создавать
new HttpClient() на каждый запрос?Потому что
IHttpClientFactory переиспользует HttpMessageHandler и соединения под капотом. Это снижает риск socket exhaustion, даёт централизованную настройку таймаутов, ретраев, логирования и авторизации.А
PooledConnectionLifetime нужен, чтобы соединения не жили вечно и приложение могло корректно подхватывать изменения DNS.Аллокации, которых нет в коде: охота на скрытый боксинг в .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/
Самая дорогая аллокация в вашем сервисе та, которой нет в исходниках. Вы написали 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/
Что выведет код?
А —
Б —
В —
Г —
Правильный ответ: В — A1AB2.
Почему: IEnumerable и LINQ выполняются лениво. First() запускает перебор один раз и доходит только до первого элемента: печатает A, потом 1. Count() запускает перебор заново: снова A, потом B, и в конце печатает 2.
using System;
using System.Collections.Generic;
using System.Linq;
static IEnumerable<int> GetNumbers()
{
Console.Write("A");
yield return 1;
Console.Write("B");
yield return 2;
}
var query = GetNumbers().Where(x => x > 0);
Console.Write(query.First());
Console.Write(query.Count());
А —
A12Б —
A1B2В —
A1AB2Г —
ErrorПочему: IEnumerable и LINQ выполняются лениво. First() запускает перебор один раз и доходит только до первого элемента: печатает A, потом 1. Count() запускает перебор заново: снова A, потом B, и в конце печатает 2.
🚀 DDD на C#: от теории к микросервису за 6 недель
Если ты пишешь на C# и в какой-то момент начал чувствовать, что вроде всё работает, но как-то костыльно — это тревожный сигнал.
Новая фича затрагивает десятки файлов. Тесты становятся сложнее самого кода. Любое изменение заставляет переживать, что сломается что-то ещё.
Обычно проблема не в разработчиках. Проблема в том, что проект растёт без понятной архитектурной модели.
На курсе по Domain-Driven Design и Clean Architecture на C# ты научишься:
— Отделять бизнес-логику от инфраструктуры
— Организовывать код так, чтобы новые требования не приводили к переписыванию половины сервиса
— Писать тесты, которые проверяют поведение системы, а не набор моков
— Подключать HTTP, gRPC и Kafka без изменений в доменной логике
— Строить сервисы, которые проще поддерживать и развивать
За 6 недель ты соберёшь полноценный микросервис на C# с DDD, Kafka, gRPC и Clean Architecture на реальном кейсе диспетчеризации заказов.
👨🏫 Автор курса — Кирилл Ветчинкин, архитектор Авито, ex Staff Engineer Купер, ex Head of Backend BCS Broker.
🎁 Первый модуль доступен бесплатно.
В нём разберём, почему кодовые базы со временем становятся хрупкими, откуда появляются сложные тесты и постоянный страх изменений, и как DDD и Clean Architecture помогают решить эти проблемы на практике.
Посмотри демо-модуль и оцени, насколько этот подход подходит для твоих проектов:
https://microarch.ru/courses/ddd/languages/csharp?utm_source=posev&utm_medium=erid:2VtzqwrtmqB&utm_campaign=4
Реклама. ИП Ветчинкин К.Е. ИНН: 773376451099 Erid: 2VtzqvzVXjP
Если ты пишешь на C# и в какой-то момент начал чувствовать, что вроде всё работает, но как-то костыльно — это тревожный сигнал.
Новая фича затрагивает десятки файлов. Тесты становятся сложнее самого кода. Любое изменение заставляет переживать, что сломается что-то ещё.
Обычно проблема не в разработчиках. Проблема в том, что проект растёт без понятной архитектурной модели.
На курсе по Domain-Driven Design и Clean Architecture на C# ты научишься:
— Отделять бизнес-логику от инфраструктуры
— Организовывать код так, чтобы новые требования не приводили к переписыванию половины сервиса
— Писать тесты, которые проверяют поведение системы, а не набор моков
— Подключать HTTP, gRPC и Kafka без изменений в доменной логике
— Строить сервисы, которые проще поддерживать и развивать
За 6 недель ты соберёшь полноценный микросервис на C# с DDD, Kafka, gRPC и Clean Architecture на реальном кейсе диспетчеризации заказов.
👨🏫 Автор курса — Кирилл Ветчинкин, архитектор Авито, ex Staff Engineer Купер, ex Head of Backend BCS Broker.
🎁 Первый модуль доступен бесплатно.
В нём разберём, почему кодовые базы со временем становятся хрупкими, откуда появляются сложные тесты и постоянный страх изменений, и как DDD и Clean Architecture помогают решить эти проблемы на практике.
Посмотри демо-модуль и оцени, насколько этот подход подходит для твоих проектов:
https://microarch.ru/courses/ddd/languages/csharp?utm_source=posev&utm_medium=erid:2VtzqwrtmqB&utm_campaign=4
Реклама. ИП Ветчинкин К.Е. ИНН: 773376451099 Erid: 2VtzqvzVXjP
Продвинутый C#-трюк: обновляй `Dictionary` без двойного поиска
Многие пишут так:
Проблема: ты сначала ищешь ключ через
В hot path это лишняя работа.
Есть более взрослый вариант:
Что происходит:
1. C# получает ссылку прямо на значение внутри
2. ключ ищется один раз
3. значение можно менять без повторного обращения
4. меньше лишних операций в tight loop
Где это полезно:
1. счётчики событий
2. парсеры
3. агрегации
4. обработка логов
5. high-performance backend code
Но есть важный нюанс:
не меняй структуру словаря, пока держишь
То есть не делай
Это не трюк для каждого CRUD-сервиса.
Это инструмент для мест, где C# уже упёрся в производительность, и ты начинаешь выжимать лишние аллокации и лишние lookup’и.
Многие пишут так:
if (dict.TryGetValue(key, out var value))
{
dict[key] = value + 1;
}
else
{
dict[key] = 1;
}
Проблема: ты сначала ищешь ключ через
TryGetValue, а потом снова лезешь в словарь через dict[key].В hot path это лишняя работа.
Есть более взрослый вариант:
using System.Runtime.InteropServices;
ref var count = ref CollectionsMarshal.GetValueRefOrAddDefault(
dict,
key,
out var exists
);
if (!exists)
{
count = 0;
}
count++;
Что происходит:
1. C# получает ссылку прямо на значение внутри
Dictionary2. ключ ищется один раз
3. значение можно менять без повторного обращения
4. меньше лишних операций в tight loop
Где это полезно:
1. счётчики событий
2. парсеры
3. агрегации
4. обработка логов
5. high-performance backend code
Но есть важный нюанс:
не меняй структуру словаря, пока держишь
ref.То есть не делай
Add, Remove, Clear рядом с этой ссылкой.Это не трюк для каждого CRUD-сервиса.
Это инструмент для мест, где C# уже упёрся в производительность, и ты начинаешь выжимать лишние аллокации и лишние lookup’и.
Методы, их перегрузка и расширения. Бесплатный урок специализации «C#-разработчик»
Методы — одна из базовых вещей в C#, без которой невозможно нормально писать, читать и поддерживать код. Но у начинающих разработчиков часто всё смешивается: где обычный метод, где перегрузка, как работает сигнатура, зачем нужны параметры по умолчанию и в каких случаях использовать params.
На открытом уроке 2 июля в 20:00 разберём, что такое метод в C#, как писать собственные методы и как использовать перегрузку без хаоса в коде. Поговорим о сигнатуре метода, параметрах по умолчанию, ключевом слове params и методах-расширениях. На примерах покажем, как эти механики помогают делать код понятнее, гибче и удобнее для повторного использования.
Урок не для тех, кто хочет просто «выучить синтаксис» без понимания, как методы влияют на структуру программы.
👉 Записаться: https://otus.pw/wkKs/?erid=2W5zFG7dRZ3
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
Методы — одна из базовых вещей в C#, без которой невозможно нормально писать, читать и поддерживать код. Но у начинающих разработчиков часто всё смешивается: где обычный метод, где перегрузка, как работает сигнатура, зачем нужны параметры по умолчанию и в каких случаях использовать params.
На открытом уроке 2 июля в 20:00 разберём, что такое метод в C#, как писать собственные методы и как использовать перегрузку без хаоса в коде. Поговорим о сигнатуре метода, параметрах по умолчанию, ключевом слове params и методах-расширениях. На примерах покажем, как эти механики помогают делать код понятнее, гибче и удобнее для повторного использования.
Урок не для тех, кто хочет просто «выучить синтаксис» без понимания, как методы влияют на структуру программы.
👉 Записаться: https://otus.pw/wkKs/?erid=2W5zFG7dRZ3
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
Record-типы в C#: когда модель данных не должна быть обычным class
Типичный пример:
Компилятор сам сгенерирует конструктор,
Обычный
Это делает
Ещё одна удобная вещь -
Но есть важный нюанс:
Такой
Но когда тип нужен как чистая модель данных,
record в C# удобен там, где объект описывает данные, а не поведение и идентичность.Типичный пример:
public record User(string Name, int Age);
Компилятор сам сгенерирует конструктор,
Equals, GetHashCode, ToString и деконструкцию. Но главное отличие не в сокращении кода, а в семантике.Обычный
class сравнивается по ссылке:
var a = new UserClass("Alice", 25);
var b = new UserClass("Alice", 25);
Console.WriteLine(a == b); // false
record сравнивается по значению:
var a = new User("Alice", 25);
var b = new User("Alice", 25);
Console.WriteLine(a == b); // true
Это делает
record хорошим выбором для DTO, read models, value objects, событий, результатов запросов и моделей, где важны значения полей.Ещё одна удобная вещь -
with. Можно создать копию объекта, изменив только нужные поля:
var user = new User("Alice", 25);
var updated = user with { Age = 26 };
Console.WriteLine(updated);
// User { Name = Alice, Age = 26 }
Но есть важный нюанс:
with делает поверхностную копию. Если внутри есть изменяемая коллекция, она не станет автоматически immutable.
public record Team(string Name, List<string> Members);
Такой
record всё ещё может меняться через Members.Add(...). Поэтому для реально неизменяемых моделей лучше использовать immutable-коллекции или аккуратно закрывать доступ к изменяемому состоянию.record не заменяет class везде. Если у объекта есть жизненный цикл, identity, состояние и бизнес-поведение, обычный класс часто будет честнее.Но когда тип нужен как чистая модель данных,
record убирает шум и делает намерение в коде очевидным.