Почему ручное управление памятью всё ещё важно

Аргументы Dayvi Schuster в пользу изучения ручного управления памятью, даже если основная работа - на JS/Python/Go: это углубляет понимание того, как устроены системы на самом деле, и открывает путь к современным низкоуровневым языкам - Zig, Odin, C3, - где ручная работа с памятью выступает основной возможностью, а не запасным вариантом. Статья построена так: сначала типичные ошибки, затем ментальная модель и разбор конкретных языков.

Типичные ошибки

Каждая иллюстрируется одной и той же аналогией с выдачей книг в библиотеке, и аналогия работает удивительно хорошо:

Dangling pointer - указатель на уже освобождённую память.
Double free - освобождение памяти, которая уже была освобождена.
Use after free - чтение или запись по адресу памяти после её освобождения.
Memory leak - выделение памяти без последующего освобождения.
Buffer overflow - запись за границы выделенной области.
Memory fragmentation - множество мелких аллокаций и освобождений оставляют фрагменты, непригодные для повторного использования под новое выделение.
Incorrect ownership - несколько указателей на один и тот же участок памяти, каждый из которых пытается его изменить.

Все они приводят к "падениям, повреждению данных и уязвимостям безопасности" - суть мысли Dayvi в том, что сценарии сбоев одинаковы и одинаково опасны.

Ментальная модель

Две области:

Stack - LIFO, фиксированный размер, быстрый доступ. Локальные переменные и фреймы вызовов функций.
Heap - динамическая, гибкая, более медленная. Неструктурированная масса.

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

Инструменты

Стандартный список: отладчики, санитайзеры (AddressSanitizer для OOB и UAF, LeakSanitizer для утечек), логирование и профилирование, статический анализ (статический анализатор Clang) и код-ревью. Dayvi предпочитает активно опираться на них, а не пытаться соблюдать предельную осторожность вручную.

Лучшие практики

Всегда освобождать то, что выделили.
Использовать умные указатели в языках, где они есть (C++).
Предпочитать очистку по границам областей видимости: RAII в C++, defer в Zig.
Тестировать небольшими частями и часто.
Документировать решения по управлению памятью - вы будущий уже не вспомните, почему было сделано именно так.

Разбор языков

C - malloc/free, ничего встроенного, пробел закрывают сторонние инструменты. Каноническая пара - Valgrind и AddressSanitizer.

Fil-C - модифицированный тулчейн LLVM/Clang, который добавляет безопасность памяти в C/C++ с минимальными накладными расходами и без переписывания кода. Инструментирует операции с указателями, линкуется с собственной runtime-библиотекой, использует модифицированную стандартную библиотеку и безопасный с точки зрения памяти ABI. Выражение int x = arr[i] компилируется во что-то вроде check_pointer_bounds(arr, i); load_value(arr + i). Полная модель подробно описана на странице simplified-model-of-fil-c.

C++ - умные указатели оборачивают сырые указатели и управляют временем жизни автоматически. Современный C++ настоятельно рекомендует контейнеры (std::vector, std::string, std::map) вместо прямого выделения памяти. Проблемы начинаются, когда пишут int* arr = new int[10] вместо std::vector<int> arr(10).

Zig - фаворит Dayvi. Ручное управление памятью здесь в основе всего. Аллокаторы передаются явно как обычные значения; defer планирует очистку в конце блока. Развёрнутые аргументы приведены на zig-functional-programmers, а основной механизм метапрограммирования в Zig - на comptime.

Odin - явная передача аллокаторов, как в Zig, плюс удобный context.allocator по умолчанию. Легко переключать стратегии - arena для короткоживущих данных, отдельный аллокатор для чувствительных к производительности подсистем - без переписывания половины программы. Предсказуемый код: понятно, где происходят аллокации и кто ими владеет.

C3 - опирается на аллокации в рамках области видимости и детерминированную очистку. Время жизни привязано к областям видимости; вспомогательные функции вроде mem::new_array избавляют от работы с примитивами прямого выделения памяти; для короткоживущих данных рекомендуются временные аллокаторы и arena-аллокаторы. Язык нацелен на устранение главной причины багов с памятью - путаницы со временем жизни. Контекст дизайна см. на c3-lang и unsigned-sizes-c3-mistake.

Rust - спорный тезис Dayvi: на самом деле это не язык с ручным управлением памятью, а система правил компилятора на этапе сборки, которая снимает ответственность с разработчика точно так же, как GC. В качестве доказательства того, что Rust не выполнил своих обещаний, он приводит формулировку "утечки памяти в Rust типобезопасны" и инцидент с падением сервисов Cloudflare на Rust. Заметка короткая и признаёт, что это тема для отдельной публикации. (Эта точка зрения оспаривается в других местах вики - рабочие паттерны на Rust см. на safe-gc и rust-async-trait-sync-bound.)

Когда стоит браться за ручное управление

Три категории:

Критичный к производительности код - игры, трейдинг, обработка звука в реальном времени, высокочастотная работа с сетью. Паузы GC и непредсказуемое выделение памяти становятся недопустимыми.
Встраиваемые системы - ограниченные ресурсы памяти и процессора, где GC может попросту не поместиться.
(В исходнике оборвано - неявно: везде, где предсказуемость важнее эргономики.)

Место в общей картине

Материал представляет собой вводное руководство для тех, кто пришёл из языков с GC, и дополняет страницы zig-functional-programmers (аргументы в пользу Zig с точки зрения хаскелиста), simplified-model-of-fil-c (добавление безопасности в C) и stroustrup-memory-leaks (FAQ по C++ о сокрытии аллокаций внутри контейнеров). Вместе они очерчивают текущее состояние дискуссии об "управлении памятью без GC" в новых и старых системных языках.