Оптимизация памяти в .NET Framework 4.5

Оптимизация памяти в .NET Framework 4.5 относится к использованию передовых практик и методов для минимизации использования памяти, предотвращения утечек памяти, оптимизации сборки мусора и максимального повышения эффективности использования памяти в приложении .NET. Эффективно управляя памятью приложений, разработчики могут повысить производительность и обеспечить оптимальное использование ресурсов в своих приложениях .NET 4.5.

Однако разобраться в проблемах управления памятью может быть непросто даже в такой управляемой платформе, как .NET. В этой статье обсуждаются некоторые основы работы с памятью в .NET 4.5, рассматриваются некоторые распространенные причины проблем с памятью в .NET 4.5 и объясняется, как можно обнаружить и устранить проблемы с памятью с помощью профиля памяти. NET.

Основы работы с памятью в .NET 4.5

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

Управляемая память

Управляемая память автоматически выделяется и управляется средой выполнения Common Language Runtime (CLR), которая обрабатывает выделение и освобождение памяти для объектов, созданных в приложении .NET. Среда CLR организует память, используя управляемые кучи и автоматическую сборку мусора, чтобы освободить память от объектов, на которые нет ссылок. Управляемая память устраняет необходимость выделять и освобождать память вручную, снижая риск утечек памяти и упрощая управление памятью для разработчиков при одновременном повышении производительности приложений.

Неуправляемая память

Неуправляемая память в .NET 4.5 часто используется при взаимодействии с собственными ресурсами. Неуправляемая память не подлежит сборке мусора и должна быть выделена вручную с помощью platform invoke (P/Invoke) или класса ‘Marshal’. Для поддержания стабильной и эффективной работы приложения крайне важно явно освобождать неуправляемую память, когда она больше не требуется. Пренебрежение этим может привести к таким проблемам, как чрезмерное использование памяти, утечки памяти и нестабильность работы приложения.

Фрагментация кучи

В .NET Framework 4.5 используется кучная память для динамического выделения памяти во время выполнения. Она разделена на кучу малых объектов (SOH) и кучу больших объектов (LOH). Фрагментация кучи происходит, когда свободная память разбрасывается на небольшие несмежные блоки, что затрудняет распределение объектов по смежным областям памяти. Повышенная фрагментация может снизить производительность приложения и ограничить масштабируемость.

Потоки и управление памятью

Потоки позволяют приложению выполнять несколько задач одновременно, повышая его оперативность и производительность. Каждый поток имеет отдельный программный счетчик и стек для вызовов методов, локальных переменных и параметров функций, что позволяет ему выполнять код независимо.

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

Распространенные причины проблем с памятью в .NET 4.5

При неправильном выполнении несколько распространенных условий могут привести к проблемам с памятью в .NET Framework 4.5.

Не удается отписаться от событий

События обеспечивают связь и координацию между компонентами или объектами в приложении .NET, позволяя объекту уведомлять другие объекты при выполнении определенного действия или изменении состояния. Они используют шаблон публикации-подписки, где объект, который вызывает (отправляет) событие, называется “издателем”, а объекты, которые получают и обрабатывают событие, называются “подписчиками”.

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

Переменные, захваченные анонимными методами

Анонимные методы позволяют создавать встроенные функции делегирования без явного объявления именованного метода. Однако они могут захватывать переменные из окружающего контекста, создавая скрытые ссылки. Пока анонимный метод активен, сборщик мусора не будет восстанавливать эти переменные. Это может привести к утечкам памяти, если анонимный метод продолжает ссылаться на большие или долгоживущие объекты, поддерживая их работоспособность дольше, чем необходимо.

Чрезмерное потребление памяти статическими переменными

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

Объекты хранятся в кэше неограниченное время

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

Неправильное освобождение памяти

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

Как обнаружить утечки памяти

Использование инструментов профилирования и отладки, таких как Visual Studio Performance Profiler и WinDbg, может дать вам представление о закономерностях потребления памяти и помочь в оптимизации ее использования.

В следующих разделах показано, как использовать оба инструмента для обнаружения утечек памяти в .NET.

Visual Studio Performance Profiler

Visual Studio Performance Profiler – это интегрированная функция Microsoft Visual Studio, которая предоставляет разработчикам подробную информацию о выполнении кода приложения, включая распределение памяти.

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

using System; 
using System.Collections.Generic; 

namespace MemoryLeakExampleDemo 
{ 
    public class EventPublisher 
    { 
        public event EventHandler? SomeEvent; 

        public void DoSomething() 
        { 
            Console.WriteLine("EventPublisher: Doing something..."); 
            SomeEvent?.Invoke(this, EventArgs.Empty); 
        } 
    } 

    public class EventSubscriber 
    { 
       public void HandleEvent(object? sender, EventArgs e) 
        { 
            Console.WriteLine("EventSubscriber: Event handled."); 
        } 
    } 

    public static class MemoryLeakExample 
    { 
        private static EventPublisher? _publisher; 
        private static List<string>? _cache; 

        public static void Run() 
        { 
            // Создайте экземпляр EventPublisher 
        _publisher = new EventPublisher(); 

         // Создайте экземпляр EventSubscriber 
           for (int i = 0; i < 50; i++) 
            { 
                EventSubscriber subscriber = new EventSubscriber(); 
                _publisher.SomeEvent += subscriber.HandleEvent; 
            } 

            // Создаем статическую переменную
            _cache = new List<string>(); 

            // Выполните некоторые действия с publisher
            _publisher.DoSomething(); 

            // Имитировать неправильное выделение памяти
            for (int i = 0; i < 10000; i++) 
            { 
                string data = new string('A', 10000); 
                _cache.Add(data); 
            } 

            Console.WriteLine("MemoryLeakExample: Program completed."); 
        } 
    } 
}

В этом примере у класса EventPublisher вызывается событие SomeEvent которое  подписывает класс EventSubscriber. Обработчик события не отписан, что может вызвать утечку памяти. Переменная _cache объявлена как статический объект List<string>, но она не очищается и ей не присваивается значение null, что не позволяет сборщику мусора восстановить ее память. Объекты постоянно добавляются в кэш без надлежащей очистки, что приводит к бесконечному потреблению памяти. Приложение также непрерывно создает большие строки и добавляет их в кэш, что может привести к фрагментации памяти и чрезмерному использованию памяти.

Вы будете запускать этот код в профилировщике производительности в Visual Studio с установленным параметром Использование памяти. Эта опция позволяет анализировать определенные методы, объекты или типы для отслеживания объектов, которые хранятся дольше, чем необходимо, или которые не собираются должным образом. Он также предоставляет ценные показатели, такие как размер управляемых куч, количество выделенных объектов и объем памяти, потребляемой определенными компонентами, чтобы помочь вам расставить приоритеты в ваших усилиях по оптимизации.

Чтобы запустить код, перейдите в меню “Отладка” и выберите “ Профилировщик”, затем установите флажок “Использование памяти” в разделе “Доступные инструменты”:

Рис. 1: Меню отладки Visual Studio, показывающее профилировщик производительности

Обратите внимание, что вы можете запустить профилировщик производительности, если для конфигурации вашего решения установлено значение Debug, но параметр Release даст более точные результаты.

Теперь поместите точку останова в первую строку кода в циклах for для создания событий подписчика и имитации выделения памяти для отладки кода:

for (int i = 0; i < 50; i++) 
{ 
    EventSubscriber subscriber = new EventSubscriber(); 
    _publisher.SomeEvent += subscriber.HandleEvent; 
}

Затем следующий код будет имитировать неправильное выделение памяти:

for (int i = 0; i < 10000; i++) 
{ 
    string data = new string('A', 10000); 
    _cache.Add(data); 
}

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

Рис. 2: Окно инструментов диагностики Visual Studio, показывающее сводную вкладку

Если вы выполните циклы еще несколько раз, делая снимки памяти, вы увидите, что использование памяти увеличилось:

Рис. 3: Снимок использования памяти с помощью профилировщика производительности VS

Если щелкнуть значение кучи в столбце Размер кучи (разница), можно увидеть выделенные объекты в куче. На следующем скриншоте показаны экземпляры EventHandler, находящиеся в памяти:

Рис. 4. Экземпляры EventHandler в профилировщике производительности VS

На рисунке ниже показано количество строковых объектов в списке кэша:

Рис. 5: Экземпляры List в профилировщике производительности VS

WinDbg

Использование WinDbg с расширением отладки SOS (.loadby sos clr для .NET 4.0 или более поздней версии) позволяет проверять управляемую кучу на наличие экземпляров ссылочных типов с помощью команды !dumpheap -stat. Запустите ваше приложение, затем запустите WinDbg и присоедините его к процессу приложения, используя Файл> Присоединить к процессу.

WinDbg предоставляет полный список объектов в куче, который вы можете просмотреть, чтобы идентифицировать объекты с большим значением totalSize:

Рис. 6. Дамп-куча WinDbg

Если выполнить фильтрацию с помощью команды !dumpheap -type, то можно найти все объекты типа EventSubscriber:

!dumpheap -type EventSubscriber

Рис. 7: куча дампа WinDbg, отфильтрованная EventSubscriber

Для дальнейшего изучения взаимосвязей и отслеживания пути к корневому объекту вы можете использовать команду !gcroot вместе с адресом одного из объектов из отфильтрованного списка. Эта команда позволяет вам перемещаться по графу объектов и определять корневой объект в иерархии:

Рис. 8: Команда WinDbg GCRoot для просмотра пути к корневому объекту

Как решить проблемы с памятью в .NET 4.5

В .NET Framework 4.5 существуют различные методы решения проблем с памятью.

Выполняем очистку с помощью интерфейсов IDisposable

Классы, реализующие IDisposable интерфейс, могут указывать метод Dispose(), позволяющий явно удалять объекты, инкапсулирующие неуправляемые ресурсы. У вас есть возможность явного вызова Dispose() для освобождения дескрипторов файлов или подключений к базе данных, отмены подписки на события и выполнения необходимых операций очистки. Более того, IDisposable также предлагает метод Finalize(), используемый для очистки перед сборкой мусора. Однако важно отметить, что Finalize() недетерминирован и может задерживать освобождение ресурсов. Используйте Finalize() только при необходимости, например, для выполнения явной очистки от дескрипторов файлов или сетевых подключений.

В приведенном ниже блоке кода класс EventPublisher реализует интерфейс  IDisposable и удаляет событие, устанавливая SomeEvent значение null в методе Dispose():

public class EventPublisher : IDisposable 
    { 
        public event EventHandler SomeEvent; 

        public void DoSomething() 
        { 
            Console.WriteLine("EventPublisher: Doing something..."); 
            SomeEvent?.Invoke(this, EventArgs.Empty); 
        } 

        public void Dispose() 
        { 
            SomeEvent = null; 
        } 
    }

Выполняем очистку с помощью блоков using

Блоки using предоставляют удобный способ обеспечить надлежащее распоряжение ресурсами, которые реализуют интерфейс IDisposable. Когда вы помещаете код в блок using, все ресурсы, объявленные в этом блоке, автоматически удаляются, когда код выходит за пределы области видимости. Ключевое преимущество блока using заключается в том, что он гарантирует вызов метода Dispose(), даже если во время выполнения кода возникает исключение. Это гарантирует надлежащее высвобождение и очистку ресурсов, способствуя эффективному и надежному управлению ресурсами.

В отличие от исходного примера кода, этот код помещает создание экземпляра EventSubscriber и подписку на событие SomeEvent внутри блока using, чтобы гарантировать надлежащее удаление подписок на события:

using (_publisher = new EventPublisher()) 
{ 
    // Create an instance of EventSubscriber 
    for (int i = 0; i < 50; i++) 
    { 
        using (EventSubscriber subscriber = new EventSubscriber();) 
        { 
            _publisher.SomeEvent += subscriber.HandleEvent; 
        } 
    } 
}

Вызов GC.Collect()

Метод GC.Collect() позволяет разработчикам вручную запускать немедленный цикл сборки мусора. Хотя сборщик мусора автоматически управляет памятью, существуют сценарии, в которых явный вызов GC.Collect() может быть полезен (например, при работе с неуправляемыми ресурсами или в ситуациях, требующих немедленного восстановления памяти).

Чрезмерное или ненужное использование GC.Collect() может снизить производительность, поэтому его следует использовать только там, где это решает проблемы с памятью или повышает производительность приложения.

Выполнение вызовов GC.Collect() и GC.WaitForPendingFinalizers() явно запускает сборку мусора и ожидает завершения всех ожидающих завершения финализаторов, чтобы можно было освободить память, занятую удаляемыми объектами. Вы можете сделать это с помощью следующего кода:

GC.Collect(); 
GC.WaitForPendingFinalizers();

Использование пула объектов

Объединение объектов – это метод оптимизации памяти, который использует пул повторно используемых объектов вместо создания новых объектов. Это помогает предотвратить проблемы с памятью за счет повторного использования объектов вместо их повторного создания и удаления. Когда требуется новый объект, диспетчер пула выделяет один из пула существующих объектов. Это сводит к минимуму накладные расходы, связанные с созданием и уничтожением объектов, особенно для часто используемых или недолговечных объектов.

Чтобы решить проблемы с памятью в примере с использованием пула объектов, добавьте класс ObjectPool<T> в пул объектов EventSubscriber:

public class ObjectPool<T> : IEnumerable<T> where T : class, IDisposable, new() 
    { 
        private readonly Stack<T> _objects = new Stack<T>(); 

        public T GetObject() 
        { 
            if (_objects.Count > 0) 
                return _objects.Pop(); 

            return new T(); 
        } 

        public void ReturnObject(T obj) 
        { 
            obj.Dispose(); 
            _objects.Push(obj); 
        } 

        public IEnumerator GetEnumerator() 
        { 
            return _objects.GetEnumerator(); 
        } 

        IEnumerator IEnumerable.GetEnumerator() 
        { 
            return GetEnumerator(); 
        } 
    }

_subscriberPool = new ObjectPool<EventSubscriber>();

for (int i = 0; i < 50; i++) 
{ 
    EventSubscriber subscriber = _subscriberPool.GetObject(); 
    subscriber.HandleEvent += HandleEvent; 
    _publisher.SomeEvent += subscriber.OnHandleEvent; 
}

foreach (EventSubscriber subscriber in _subscriberPool) 
{ 
    subscriber.HandleEvent -= HandleEvent; 
    _subscriberPool.ReturnObject(subscriber); 
}