Утечка памяти¶

Утечка памяти — это вид ошибки программирования, при котором программа, работающая в операционной системе, не освобождает память, выделенную ей для временного хранения данных, после того как эти данные больше не нужны. В результате занятая память не возвращается в пул доступной памяти, и со временем объём используемой памяти программой (или системой в целом) неограниченно растёт, что может привести к замедлению работы, исчерпанию системных ресурсов и аварийному завершению программы или всей системы.

¶Причины возникновения

Утечка памяти возникает в языках программирования, где управление памятью возлагается на разработчика (например, C, C++, Objective-C, а также в ряде случаев в Rust при использовании «сырых» указателей). Основные причины:

Забытый вызов освобождения. Программа выделяет блок памяти (например, через malloc() в C или new в C++), но не вызывает соответствующую функцию освобождения (free() или delete) после использования.
Потеря указателя. Указатель на выделенный блок памяти перезаписывается или выходит за область видимости до того, как память была освобождена. В результате блок памяти становится недоступным для освобождения, но продолжает числиться занятым.
Ошибки в структурах данных. При удалении элемента из связного списка, дерева или хеш-таблицы программист может забыть освободить память, занимаемую самим элементом, или не обновить ссылки, что приводит к «висячим» узлам.
Циклические ссылки. В языках со сборкой мусора (например, Java, C#, Python, JavaScript) утечка может возникнуть, если объекты ссылаются друг на друга, образуя цикл, и при этом на них не остаётся внешних ссылок из корневого набора. В современных сборщиках мусора (с алгоритмами отслеживания достижимости) эта проблема в основном решена, но может проявляться в старых реализациях или при использовании слабых ссылок неправильно.
Утечки через глобальные или статические переменные. Если объект добавляется в глобальный список или коллекцию и никогда оттуда не удаляется, он будет оставаться в памяти до завершения программы, даже если фактически не нужен.

¶Последствия

Утечка памяти может проявляться по-разному в зависимости от масштаба и контекста:

Замедление работы программы. Операционная система вынуждена использовать файл подкачки (swap) для компенсации нехватки оперативной памяти, что приводит к резкому падению производительности.
Аварийное завершение. При исчерпании лимита памяти (например, в 32-битных системах — 2–4 ГБ на процесс, или при достижении лимита, установленного ОС) программа получает сигнал SIGSEGV или исключение OutOfMemoryError и завершается.
Нестабильность системы. Если утечка происходит в драйвере устройства или ядре операционной системы, это может привести к «зависанию» или краху всей системы. В операционных системах семейства Windows и Linux существуют механизмы (например, OOM Killer в Linux), которые принудительно завершают процесс, потребляющий слишком много памяти.
Снижение отзывчивости. Долго работающие серверные приложения (веб-серверы, базы данных) с утечкой памяти со временем начинают работать медленнее, увеличивается время отклика на запросы.

¶Примеры

¶Классический пример на C

```c

¶include <stdlib.h>

void leak() { int ptr = (int)malloc(sizeof(int) * 100); // выделение памяти // ptr не освобождён // после выхода из функции указатель потерян }

int main() { for (int i = 0; i < 1000000; i++) { leak(); // каждый вызов выделяет 400 байт, которые никогда не освободятся } return 0; } `` В этом примере каждый вызов leak()` выделяет 400 байт (100 целых чисел по 4 байта), которые не освобождаются. После миллиона вызовов программа будет занимать около 400 МБ памяти, которая не будет возвращена системе до завершения программы.

¶Пример на C++ (с использованием `new` без `delete`)

``cpp void createObject() { MyClass* obj = new MyClass(); // выделение памяти под объект // delete obj; // забыто } ` Каждый вызов createObject()` создаёт объект в куче, который никогда не будет удалён.

¶Утечка через событийную модель (JavaScript, C#, Java)

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

¶Обнаружение и диагностика

Для поиска утечек памяти используются специализированные инструменты:

Статические анализаторы кода. Инструменты (например, PVS-Studio, cppcheck, Clang Static Analyzer) анализируют исходный код на предмет потенциальных утечек без выполнения программы.
Динамические анализаторы. Работают во время выполнения программы:
Valgrind (Memcheck) — популярный инструмент для Linux, отслеживает выделение и освобождение памяти, выявляет утечки и ошибки доступа.
AddressSanitizer (ASan) — модуль компилятора (GCC, Clang), встраивающий проверки в скомпилированный код.
Dr. Memory — аналог Valgrind для Windows.
Встроенные профилировщики — Visual Studio Profiler, Intel Inspector, Xcode Instruments (Leaks instrument).
Сборщики мусора с отладкой. В языках с GC (Java, .NET) существуют инструменты для анализа кучи (heap dump) — jmap, jvisualvm, MAT (Memory Analyzer Tool), dotMemory, которые позволяют увидеть, какие объекты занимают память и почему они не удаляются.

¶Методы предотвращения

Использование языков со сборкой мусора. Java, C#, Python, Go, JavaScript, Ruby и другие автоматически освобождают память, когда объекты становятся недостижимыми. Однако, как отмечено выше, утечки возможны и в них при неправильном использовании глобальных ссылок или событий.
Применение умных указателей (smart pointers). В C++ (начиная с C++11) стандартная библиотека предоставляет std::unique_ptr и std::shared_ptr, которые автоматически удаляют объект при выходе из области видимости или при обнулении счётчика ссылок.
Следование принципу RAII (Resource Acquisition Is Initialization). В C++ и Rust ресурсы (память, файлы, сокеты) освобождаются в деструкторе объекта, что гарантирует освобождение при любом выходе из блока (в том числе при исключениях).
Регулярное использование инструментов анализа. Включение динамических анализаторов (ASan, Valgrind) в процесс тестирования и CI/CD.
Код-ревью. Проверка парой или командой может выявить забытые free/delete или неправильное управление ссылками.