C# C# · 30 вопросов · ~85 мин · ⏱ Таймер 25:00 · Сложный · 👥 1 прошёл

Управление памятью и Span

Посвящён управляемой памяти, поколениям, Span/Memory и пулам массивов. Задания требуют проследить время жизни буфера, владение арендованной памятью, причины аллокаций и момент, когда оптимизация без измерения становится опаснее обычного массива.

Отвечено: 0 из 30

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 30 вопросов отведено 85 минут. В заданиях с кодом учитывайте указанную конструкцию и не додумывайте отсутствующие условия. После завершения откроются общий результат, тематические шкалы и разбор каждого ответа.

Вопрос 1 из 30

Когда managed-объект становится кандидатом на сборку?

var customer = new Customer();
cache[customer.Id] = customer;
customer = null;
// Объект всё ещё достижим через cache.

Сразу после выхода из блока Через ровно минуту После вызова Dispose Когда он больше не достижим из корней GC Когда его поле обнулено одно

Вопрос 2 из 30

Почему Dispose не освобождает память объекта немедленно?

using (var stream = File.OpenRead(path))
{
    ReadHeader(stream);
} // handle закрыт; память объекта stream будет собрана позднее

Объект переносится на стек Dispose запрещён для классов Dispose запускает новый GC-процесс Dispose зануляет поля, после чего GC сразу считает объект недостижимым Dispose закрывает ресурс, память позже возвращает GC

Вопрос 3 из 30

Зачем типу с SafeHandle обычно не нужен собственный финализатор?

Пользовательские финализаторы запрещены в .NET для типов с полем SafeHandle SafeHandle делает владеющий тип неизменяемым, поэтому финализатор не может изменить состояние SafeHandle освобождается только финализатором внешнего типа SafeHandle уже реализует надёжную финализацию native handle и упрощает владельцу Dispose SafeHandle всегда размещается на стеке и освобождается при выходе из метода

Вопрос 4 из 30

Какой эффект у финализатора для объекта?

sealed class NativeOwner
{
    ~NativeOwner() => ReleaseNative();
}

Он запрещает Dispose Он освобождается при return Финализируемый объект удаляется в первой сборке Gen0 без задержки Объект обычно переживает ещё один цикл GC Он делает объект thread-static

Вопрос 5 из 30

Почему регулярный GC.Collect в обработчике запроса обычно вреден?

Он очищает только стек Принудительная сборка гарантированно освобождает весь рабочий набор Он собирает только поколение 0 и поэтому не затрагивает долгоживущие объекты Принудительная сборка создаёт паузы и не устраняет причину удержания Он не компилируется

Вопрос 6 из 30

Почему большинство новых небольших объектов начинается в Gen0?

for (var i = 0; i < 1_000_000; i++)
{
    var temporary = new byte[128];
    Consume(temporary);
}

Gen0 быстро собирает краткоживущие объекты Gen0 служит постоянным поколением для небольших объектов Чтобы отключить finalizer Только Gen0 поддерживает классы Gen0 хранится на диске

Вопрос 7 из 30

Что происходит с объектом, пережившим сборку поколения?

Он может быть продвинут в более старшее поколение Он теряет поля Он становится unmanaged Он копируется в файл подкачки Переживший сборку объект становится static и больше не участвует в GC

Вопрос 8 из 30

Как интерпретировать высокий Gen2 collection count?

var gen2 = GC.CollectionCount(2);
var heap = GC.GetGCMemoryInfo().HeapSizeBytes;
metrics.Record(gen2, heap);

Это прямой признак утечки, allocation rate можно не учитывать Только норму для любого сервиса Частые полные сборки; нужны метрики heap и пауз Поколение 2 содержит только объекты из LOH, поэтому остальные причины можно исключить Число потоков

Вопрос 9 из 30

Куда обычно попадает большой массив байтов?

В стек текущего потока независимо от размера массива В Large Object Heap при превышении установленного порога размера В unmanaged heap без участия GC Крупный массив сначала размещается в обычной области Gen0 В intern pool

Вопрос 10 из 30

Почему кэш может увеличивать стоимость Gen2?

private readonly MemoryCache _cache = new(new MemoryCacheOptions
{
    SizeLimit = 10_000
});
// Каждая запись задаёт Size и срок жизни.

Кэш хранит weak references и потому не влияет на старшие поколения Потому что ключи сортируются Кэш удерживает большой долгоживущий граф объектов Кэш отключает GC Dictionary хранится только в Gen0

Вопрос 11 из 30

Что делает span.Slice(2, 3)?

var data = new[] { 0, 1, 2, 3, 4, 5 };
Span<int> part = data.AsSpan(2, 3);
part[0] = 99;
Console.WriteLine(data[2]); // 99

Удаляет элементы исходника Slice закрепляет исходный массив через pinned handle Slice копирует выбранные элементы в новый массив Сортирует подмассив Представление трёх элементов с индекса 2

Вопрос 12 из 30

Почему Span<T> нельзя хранить полем обычного класса?

public sealed class Holder
{
    private Span<byte> _buffer;
}

Обобщённый Span нельзя использовать ни в одном члене типа Запрет связан только с nullable-аннотациями поля ref struct нельзя хранить внутри объекта, размещаемого в управляемой куче Span<T> является необработанным указателем и требует только блока unsafe Обычные классы вообще не поддерживают поля структур

Вопрос 13 из 30

Какой тип использовать для буфера, который нужно передать через await?

async Task<int> ReadAsync(Memory<byte> buffer, CancellationToken token) =>
    await stream.ReadAsync(buffer, token);

ref byte stackalloc byte[] Span<byte> TypedReference Memory<byte> или ReadOnlyMemory<byte>

Вопрос 14 из 30

Что даёт ReadOnlySpan<char> параметру парсера?

Представление символов без права записи и часто без создания substring Выбор культуры по типу исходного символьного буфера Гарантию, что исходная string не изменится другим кодом Сериализацию Асинхронное выполнение

Вопрос 15 из 30

Почему нельзя вернуть Span<byte> на stackalloc из метода?

static Span<byte> CreateBuffer()
{
    Span<byte> buffer = stackalloc byte[16];
    return buffer;
}

Ограничение возникает только для буферов короче 256 байт Возврат разрешён только в 64-разрядной среде выполнения Методы не могут возвращать ref struct даже при безопасном времени жизни памяти При возврате Span<T> рантайм копирует stackalloc-буфер в управляемую кучу Стековая память метода исчезнет, и возвращённое представление стало бы висячим

Вопрос 16 из 30

Гарантирует ли ArrayPool<byte>.Rent(1000) массив длины ровно 1000?

var rented = ArrayPool<byte>.Shared.Rent(1000);
Console.WriteLine(rented.Length >= 1000);
ArrayPool<byte>.Shared.Return(rented);

Нет, длина может быть больше запрошенной Вернётся Span длины 1000 Может быть меньше Пул округляет запрос до степени двойки, значит вернёт ровно 1024 Да

Вопрос 17 из 30

Почему Return должен быть в finally?

var buffer = ArrayPool<byte>.Shared.Rent(size);
try { Process(buffer.AsSpan(0, size)); }
finally { ArrayPool<byte>.Shared.Return(buffer); }

Чтобы очистить стек Чтобы массив вернулся даже при исключении finally нужен, чтобы не запускался GC во время аренды Чтобы увеличить его длину Чтобы Rent стал async

Вопрос 18 из 30

Когда нужен clearArray: true или ручная очистка?

Очищать стоит любой int-буфер, иначе GC не освободит массив Чтобы изменить размер clearArray ускоряет Return, поскольку уменьшает длину массива Когда буфер содержал секреты или данные, которые нельзя увидеть следующему арендатору Только для zero-length

Вопрос 19 из 30

Что опасно в возврате массива до завершения SendAsync?

var rented = pool.Rent(length);
var sendTask = socket.SendAsync(rented.AsMemory(0, length), token);
pool.Return(rented); // слишком рано
await sendTask;

SendAsync копирует весь буфер до возврата Task, поэтому ранний возврат в пул безопасен Код не компилируется Массив станет null Return блокирует сеть Буфер могут переиспользовать до конца отправки

Вопрос 20 из 30

Когда ArrayPool не нужен?

Если освобождение уже оформлено через try/finally Когда буфер должен долго принадлежать объекту и храниться между вызовами При любом массиве byte независимо от частоты создания Только когда буфер содержит строки, а не байты Для редкого маленького буфера без подтверждённой проблемы аллокаций

Вопрос 21 из 30

Как найти типы, создающие больше всего мусора?

dotnet-trace collect --process-id 1234 \
  --providers Microsoft-Windows-DotNETRuntime:0x1C000080018:5 \
  --output allocations.nettrace
# Затем сгруппировать стеки аллокаций по типу и месту вызова.

Смотреть на самый большой размер экземпляра, не учитывая частоту создания объектов Снять allocation trace и сгруппировать по типу Ориентироваться на Task Manager: рост рабочего набора укажет конкретный создаваемый тип Отключить журналирование и считать исчезнувшую нагрузку доказательством источника мусора Сравнить общий размер кучи до и после принудительной GC без данных о местах аллокаций

Вопрос 22 из 30

Как проверить «парсер не выделяет память»?

[MemoryDiagnoser]
public class ParserBench
{
    private readonly string text = "12345";
    [Benchmark] public int Parse() => Parser.Parse(text.AsSpan());
}

Запустить finalizer Сравнить длину Span Измерить только время Stopwatch и считать отсутствие замедления доказательством нулевых аллокаций Assert на GC.GetTotalMemory до/после одного вызова Измерить аллокации после прогрева типичного цикла

Вопрос 23 из 30

Что показывает рост heap при стабильном allocation rate после полных GC?

Нормальное поведение, которое не требует сравнения снимков Вероятное удержание управляемых объектов; нужен снимок кучи и анализ корней Нехватку процессорного времени при обработке запросов Рост объясняется только временным пиком молодых объектов, даже если он сохраняется после полных сборок Однозначную утечку неуправляемой памяти вне кучи CLR

Вопрос 24 из 30

Как тестировать use-after-return для пула?

var pool = new PoisoningArrayPool<byte>();
await sut.ProcessAsync(pool);
Assert.Equal(pool.RentCount, pool.ReturnCount);
Assert.False(pool.HasOutstandingBuffers);

Увеличить массив Проверить лишь отсутствие исключения при Return Тестовый pool помечает возврат и двойной Return Надеяться, что память не изменится Сравнивать ссылки на выданный и возвращённый массив без состояния пула

Вопрос 25 из 30

Какие метрики памяти полезны в сервисе?

Скорость аллокаций, паузы GC, размеры поколений, LOH и рабочий набор Снимать private bytes раз в сутки без скорости аллокаций и временной связи с нагрузкой Считать места с using: их количество напрямую отражает давление управляемой памяти Считать объявления struct в кодовой базе независимо от упаковки и частоты использования Собирать только число полных GC без длительности пауз и размеров поколений

Вопрос 26 из 30

Когда Span-API оправдан в публичной библиотеке?

Когда нужно хранить Span в поле обычного класса между вызовами Когда публичный метод должен свободно пересекать await Когда работа с буферами — основной сценарий, а ограничения времени жизни понятны пользователю API Когда любой строковый параметр хочется заменить низкоуровневым типом Когда сокращение синтаксиса важнее совместимости и простоты

Вопрос 27 из 30

Как совместить удобство и производительность парсера?

public static Result Parse(string text) => Parse(text.AsSpan());
public static Result Parse(ReadOnlySpan<char> text) { /* общий алгоритм */ }

Возвращать char[] как универсальный zero-copy-контракт Оставить только unsafe pointer API Копировать string дважды Span-ядро и удобная перегрузка для string Использовать reflection

Вопрос 28 из 30

Почему безлимитный кэш быстрее только сначала?

После каждой сборки поколения 0 кэш автоматически удаляет неиспользованные записи Он удерживает всё больше памяти, усиливает полные сборки и в конце может привести к OOM Поиск в Dictionary становится линейным после фиксированного числа элементов Любой кэш сериализует чтения и потому не допускает параллельный доступ Ключи кэша со временем превращаются в null и ломают сравнение

Вопрос 29 из 30

Как backpressure связан с памятью?

var channel = Channel.CreateBounded<Job>(new BoundedChannelOptions(1_000)
{
    FullMode = BoundedChannelFullMode.Wait
});

Ограниченная очередь принудительно запускает сборку мусора после каждого элемента Ограничение очереди влияет лишь на порядок, а не на объём удерживаемых объектов Ограниченная очередь не даёт памяти расти без границ Очередь остаётся в Gen0, поэтому её рост не влияет на память Он требует stackalloc

Вопрос 30 из 30

Как оценить пользу ArrayPool в архитектуре?

Считать пул обязательным для любого массива крупнее одного килобайта Посмотреть только число сборок поколения 0 после одного вызова Сравнить число вызовов Rent без учёта возврата и размера буферов Оценить пользу только по уменьшению числа строк исходного кода Сравнить пропускную способность, хвост задержек, аллокации и риск ошибок владения под нагрузкой

Ответьте на все 30 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

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

Также доступна прямая ссылка на embed-страницу