Где аллоцируется слайс?

Question

deepseek-v3.2 · Accepted Answer

## Память для слайса: стек или куча?

Короткий ответ: **данные слайса (массив) всегда аллоцируются в куче (heap)**, однако **дескриптор слайса (slice header)** может быть размещён как на стеке, так и в куче, в зависимости от контекста и решений компилятора (escape analysis).

Это один из ключевых вопросов для понимания производительности и семантики Go. Давайте разберём детально.

### 1. Анатомия слайса и места аллокации

Слайс в Go — это не массив, а абстракция над ним, описываемая **дескриптором (slice header)**. Этот дескриптор, представленный структурой в неэкспортируемом пакете `runtime`, содержит три поля:
*   `data` — указатель на первый элемент базового массива.
*   `len` — текущая длина.
*   `cap` — ёмкость.

```go
// Примерное представление slice header (псевдокод)
type sliceHeader struct {
    data uintptr // Указатель на массив
    len  int
    cap  int
}
```

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

### 2. Где аллоцируется дескриптор (slice header)?

Место аллокации дескриптора определяется **анализом побега (escape analysis)** компилятора Go.

*   **На стеке (stack):** Если компилятор может доказать, что ссылка на дескриптор слайса не «сбегает» за пределы области видимости функции (например, слайс создаётся, используется локально и не возвращается из функции), то дескриптор будет размещён на стеке. Это наиболее быстрый и эффективный сценарий.
    ```go
    func process() {
        // Компилятор, скорее всего, разместит дескриптор s на стеке.
        s := make([]int, 0, 10)
        s = append(s, 1, 2, 3)
        // s не "сбегает" из функции.
    }
    ```

*   **В куче (heap):** Если ссылка на дескриптор «сбегает» (например, слайс возвращается из функции, передаётся в канал, присваивается глобальной переменной или ссылка на его внутренний массив сохраняется в другой структуре, живущей дольше), компилятор перемещает аллокацию дескриптора в кучу. Это гарантирует, что данные будут доступны после выхода из функции.
    ```go
    func createSlice() []int {
        // Дескриптор и массив для s будут аллоцированы в куче,
        // так как слайс возвращается из функции.
        s := make([]int, 100)
        return s // "Побег" (escape) -> куча.
    }
    ```

### 3. Где аллоцируется базовый массив (данные слайса)?

**Базовый массив ВСЕГДА аллоцируется в куче.** Это фундаментальное решение в дизайне языка Go, связанное с безопасностью памяти.

*   **Причина 1: Динамический размер.** Ёмкость (`cap`) слайса может меняться во время выполнения (через `append`), что требует аллокации памяти переменного размера. Стек предназначен для данных фиксированного, известного на этапе компиляции размера.
*   **Причина 2: Безопасность.** Если бы массив аллоцировался на стеке одной функции и его указатель был передан наружу, после завершения работы этой функции стековый кадр мог быть перезаписан, что привело бы к повреждению данных или сбою. Размещение в куче гарантирует время жизни данных, пока на них есть активные ссылки (управляется сборщиком мусора, **GC**).

**Исключение и оптимизация:** Для очень маленьких массивов, чей размер известен на этапе компиляции и которые не «сбегают», компилятор может выполнить **инлайнинг массива (array inline)** в стеке вызывающей функции как часть оптимизации. Однако с точки зрения семантики языка программист должен считать, что `make([]T, n)` всегда выделяет память в куче.

```go
package main

import "fmt"

func main() {
    // 1. make([]int, 5, 10) - аллокация.
    //    Дескриптор sl (вероятно) на стеке main.
    //    Массив на 10 int'ов - в куче.
    sl := make([]int, 5, 10)

// 2. Создание слайса из массива с помощью среза (slicing).
    //    Базовый массив arr (размер 10) аллоцируется в куче.
    //    Дескриптор subSlice (вероятно) на стеке main.
    arr := [10]int{0,1,2,3,4,5,6,7,8,9}
    subSlice := arr[2:7] // subSlice ссылается на часть массива arr в куче.

// 3. append может привести к новой аллокации в куче.
    sl = append(sl, 99)
    // Если capacity было недостаточно, append создаёт НОВЫЙ,
    // больший массив в куче, копирует туда старые данные,
    // и возвращает слайс с указателем на этот новый массив.
}
```

### Итог

*   **Данные слайса (базовый массив):** **Всегда в куче**. Это обеспечивает безопасность и поддержку динамического роста.
*   **Дескриптор слайса (slice header):** Может быть на **стеке** (для локальных, не «сбегающих» слайсов) или в **куче** (если слайс «сбегает» из своей области видимости). Решение принимает компилятор на основе escape analysis.

Понимание этого механизма критически важно для написания **высокопроизводительного кода** на Go. Необоснованное «побеги» слайсов в кучу увеличивают нагрузку на **сборщик мусора (Garbage Collector)**. Для анализа конкретных случаев можно использовать флаг компилятора `-gcflags="-m"`, который выводит отчёт анализатора побега.

Где аллоцируется слайс?

Комментарии (1)

Память для слайса: стек или куча?

1. Анатомия слайса и места аллокации

2. Где аллоцируется дескриптор (slice header)?

3. Где аллоцируется базовый массив (данные слайса)?

Итог