Стек и куча

2025-02-22 2192 11

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

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

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

Каждая область памяти служит своим специфическим целям. В Zig существует 3 основных типа памяти (или 3 различных пространства памяти):

Статическая область памяти
Стек
Куча

Давайте детально рассмотрим все три области памяти и как Zig размещает в них объекты.

Статическая область памяти

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

Одной из ключевых стратегий, которую использует Zig для определения места хранения объектов, является анализ их значений. В частности, компилятор проверяет, известно ли значение объекта во время компиляции (compile-time) или оно будет определено только во время выполнения программы (runtime).

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

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

Пример использования статической памяти:

const PI: f64 = 3.14159; // Значение известно на этапе компиляции
const y = "Hello, world!"; // Строка, известная на этапе компиляции
const DaysOfWeek = [7][]const u8{ "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday" }; // Массив строк, известный на этапе компиляции
const MaxValue: i32 = @max(10, 20); // Хоть выражение и вычисляется, результат известен на этапе компиляции

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

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

Преимущества использования статической области памяти:

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

Стек

Стек представляет собой область памяти, предназначенную для временного хранения данных функций и локальных переменных. В Zig стек работает по принципу “последним пришел - первым ушел” (LIFO - Last In, First Out).

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

Рассмотрим простой пример использования стека:

const std = @import("std");

pub fn main() void {
    var x: i32 = 10; // Переменная на стеке
    var y: f64 = 3.14; // Ещё одна переменная на стеке

    calculateSum(x, y); // Вызов функции создаст новый стековый кадр

    x += 1;
    y += 1;

    calculateSum(x, y); // Вызов функции создаст новый стековый кадр
}

fn calculateSum(a: i32, b: f64) void {
    const result = @as(f64, @floatFromInt(a)) + b; // Локальная переменная в новом стековом кадре
    std.debug.print("Сумма: {d}\n", .{result});
} // При выходе из функции стековый кадр очищается

В этом примере демонстрируется механизм работы стека при вызове функций. Когда выполняется main(), для неё создается стековый кадр, содержащий локальные переменные x и y. При вызове calculateSum(x, y) создается новый стековый кадр, куда копируются значения аргументов a и b, а также размещается локальная переменная result.

После выполнения std.debug.print() и завершения функции calculateSum, её стековый кадр автоматически освобождается. Это происходит очень быстро, так как компилятор просто сдвигает указатель вершины стека (обычно в сторону увеличения адресов памяти). Освобожденная память не возвращается операционной системе, а становится доступной для следующих вызовов функций.

Важно отметить, что размер всех переменных в стековом кадре (x, y, result) должен быть известен компилятору заранее. Это позволяет точно рассчитать необходимый размер стекового кадра и эффективно управлять памятью. Программисту не нужно заботиться об освобождении этой памяти - всё происходит автоматически при выходе из соответствующей области видимости функции.

После завершения работы main() её стековый кадр также освобождается, и вся использованная память становится доступной для повторного использования другими функциями программы. При этом физический размер области памяти, выделенной под стек процесса, остается неизменным на протяжении всего времени работы программы. Хотя чисто технически эту свободную память можно вообще отдать обратно в распоряжение ОС, но обычно область, выделенная под стек, никогда не уменьшается в размерах. Таким образом, память, использованная под стековый кадр функцией calculateSum, после завершения работы этой функции становится доступной для использования каким-то другим стековым кадром.

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

// Этот код не скомпилируется
const a = [_]u8{0, 1, 2, 3, 4};
for (0..a.len) |i| {
    const index = i;
    _ = index;
}
// Попытка использовать объект,
// который был объявлен в области видимости цикла for
// и больше не существует.
std.debug.print("{d}\n", .{index});

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

const std = @import("std");

fn createDangerousPointer() *i32 {
    var localVar: i32 = 42;
    return &localVar; // Опасно! Возвращаем указатель на переменную, которая будет уничтожена
}

fn someOtherFunction() void {
    var localVar: i32 = 42;
    localVar = 100;
    std.debug.print("{}\n", .{localVar});
}

pub fn main() void {
    const ptr = createDangerousPointer();
    // Использование ptr небезопасно, так как указывает на уже несуществующую память

    someOtherFunction();

    std.debug.print("Pointer value: {d}\n", .{ptr.*});
}

Если мы запустим этот код, то он выполнится и выведет:

100
Pointer value: 100

Хотя мы ожидали увидеть 42, но так как после вызова нашей функции createDangerousPointer мы еще вызвали функцию someOtherFunction, то кадр стека в котором была размещена наша переменная был перезатерт кадром стека от функции someOtherFunction. Когда стековый кадр “уничтожается”, всякие ссылки в ту область памяти, которую этот кадр занимал, становятся попросту бессмысленными. И что мы получим при обращении по таким указателям, совершенно не определено, может получиться всё что угодно - или мы получим какие-то абсурдные данные или, в совсем тяжких случаях, аварийное завершение программы (segfault).

В языке Go компилятор выполняет так называемый “escape analysis” (анализ убегания) - процесс определения, может ли переменная “убежать” за пределы функции, где она была создана. Если компилятор обнаруживает, что на переменную может существовать ссылка после завершения функции, он автоматически размещает эту переменную в куче вместо стека.

Вот пример:

func createValue() *int {
    x := 42          			// Изначально x создается как локальная переменная
    return &x        			// Компилятор видит, что возвращается адрес x
                     			// и перемещает x в кучу
}

func main() {
    ptr := createValue()  // ptr указывает на значение в куче
    fmt.Println(*ptr)     // Безопасно, значение все еще существует
}

В этом случае происходит следующее:

Компилятор видит, что функция возвращает указатель на локальную переменную
Вместо размещения x на стеке, выделяется память в куче
Значение 42 записывается в эту область кучи
Возвращается указатель на область в куче

Это происходит автоматически и прозрачно для программиста. В Zig такого механизма нет - программист должен явно управлять размещением переменных, что дает больше контроля, но требует более внимательного отношения к управлению памятью.

Проблема Stack Overflow в Zig

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

Причины возникновения Stack Overflow в Zig

Глубокая рекурсия Zig не использует автоматическое выделение памяти в куче (heap) для рекурсивных вызовов, поэтому при чрезмерно глубоком рекурсивном вызове может произойти переполнение стека.

fn recursive(n: u32) void {
    if (n == 0) return;
    recursive(n - 1);
}

pub fn main() void {
    recursive(1_000_000); // Это приведет к Stack Overflow
}

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

pub fn main() void {
    var large_array: [1_000_000]u8 = undefined; // Потенциальное переполнение стека
}

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

Итак мы рассмотрели как в Zig использукется стек и как происходит выделение памяти в нем и освобождение. При работе со стеком важно помнить, что после заверешения текущей области видимости, все локальные переменные, которые были выделены в стеке, автоматически освобождаются.

Преимущества использования стека:

Быстрое выделение и освобождение памяти
Автоматическое управление памятью
Данные, распределенные по стеку, часто более удобны для кэширования из-за их локализованного характера и предсказуемых шаблонов доступа
Предсказуемое время жизни объектов

Куча

Управление памятью через глобальные переменные и стек, хотя и отличается простотой реализации и хорошей производительностью, имеет два существенных недостатка:

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

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

Эти ограничения создают потребность в более гибких механизмах управления памятью и в Zig эта проблема решается использованием кучи.

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

Еще одно ключевое различие между стеком и кучей заключается в том, что куча - это тип памяти, над которым вы, программист, имеете полный контроль. Это делает кучу более гибким типом памяти, но также затрудняет работу с ней. Потому что вы, программист, отвечаете за управление всем, что с этим связано. Включая, где выделяется память, сколько памяти выделяется и где эта память освобождается.

const std = @import("std");

pub fn main() !void {
    // Получаем аллокатор общего назначения
    var gpa = std.heap.GeneralPurposeAllocator(.{}).init;
    defer _ = gpa.deinit(); // Освобождаем ресурсы аллокатора при выходе
    const allocator = gpa.allocator();

    // Выделяем память в куче для массива из 100 чисел
    var numbers = try allocator.alloc(i32, 100);
    defer allocator.free(numbers); // Освобождаем память при выходе

    // Заполняем массив
    for (numbers, 0..) |*num, i| {
        num.* = @intCast(i);
    }

    // Можем изменять размер массива
    numbers = try allocator.realloc(numbers, 200);

    // Используем массив...
    std.debug.print("Первый элемент: {d}\n", .{numbers[0]});
}

В этом примере демонстрируются основные операции с памятью в куче:

Создание аллокатора
Выделение памяти через alloc()
Изменение размера выделенной памяти через realloc()
Освобождение памяти через free()

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

Важно отметить несколько ключевых моментов при работе с кучей:

Ответственность программиста: В отличие от стека, где память освобождается автоматически, при работе с кучей программист должен сам следить за освобождением памяти.
Фрагментация: При частом выделении и освобождении памяти в куче может возникать фрагментация - ситуация, когда свободная память разбита на множество мелких несмежных участков.
Производительность: Операции с кучей обычно медленнее, чем со стеком, так как требуют поиска подходящего блока памяти и управления списком свободных блоков.
Утечки памяти: Если забыть освободить выделенную память, это приведет к утечке памяти - ситуации, когда программа постепенно расходует всё больше и больше памяти.

Заключение

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

#heap #stack #zig #zigbook