Модуль 5 ⏱ ~23 мин чтения 📐 1 Mermaid диаграмм

20. Строки в Go. Immutable string и работа с Unicode

В прикладном бэкенде строки окружают нас повсюду: заголовки HTTP-запросов, тела JSON-документов, SQL-запросы, ключи в распределенном кэше и журналы логов. В лекции 7. Rune, Byte и Unicode в Go мы уже выяснили, что строка в Go — это не абстрактный массив букв, а неизменяемая последовательность сырых байт в стандарте кодирования UTF-8.

В традиционном C строка представляла собой указатель на массив символов, завершающийся нулевым байтом (char*, null-terminated). Это историческое решение породило легион уязвимостей переполнения буфера и требовало обхода всей памяти за $O(N)$ для тривиального вычисления длины через strlen().

В Go создатели языка — Кен Томпсон и Роб Пайк — полностью переосмыслили работу со строками. Они заложили в них железные гарантии неизменяемости (Immutability). Это защищает многопоточные приложения от гонок данных без единого мьютекса, но при неосторожном обращении может спровоцировать колоссальные утечки памяти и деградацию производительности при конкатенациях.

В этой главе мы препарируем структуру StringHeader, разберем физику неизменяемости, узнаем, почему наивная конвертация строки в срез байт убивает производительность, и изучим, как strings.Builder использует низкоуровневые механизмы для Zero-Copy манипуляций.

Анатомия структуры строки (StringHeader)

На уровне рантайма (runtime/string.go) строка — это легковесная 16-байтная структура (на 64-битной архитектуре) из двух полей:

type stringStruct struct {
    str unsafe.Pointer // Указатель на непрерывный байтовый массив в памяти
    len int            // Точное количество физических байт в строке
}

(Исторически в пакете reflect была определена аналогичная структура StringHeader, но начиная с Go 1.21 она объявлена устаревшей (deprecated) в пользу функций unsafe.String и unsafe.StringData, появившихся в Go 1.20).

Обратите внимание на ключевое отличие от SliceHeader из главы 16. Slice. Главная структура данных в Go: у строки принципиально отсутствует поле Cap (Capacity). Поскольку размер строки неизменяем, резервировать избыточную емкость не имеет физического смысла:

Data: указатель на непрерывный read-only массив байт в памяти процесса.
Len: точное количество физических байт (а не рун!).

flowchart LR
    classDef process  fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef success  fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc
    classDef error    fill:#7f1d1d,stroke:#f87171,stroke-width:1px,color:#f8fafc
    classDef warning  fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc
    classDef entry    fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef aux      fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc
    classDef system   fill:#312e81,stroke:#a78bfa,stroke-width:1px,color:#f8fafc
    classDef data     fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc
    classDef network  fill:#881337,stroke:#fb7185,stroke-width:1px,color:#f8fafc
    classDef accent   fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    subgraph Header ["StringHeader - 16 байт"]
        direction TB
        Data["Data - Указатель"]:::process
        Len["Len - 5"]:::process
    end

    subgraph Memory ["Read-Only Memory - .rodata"]
        direction LR
        B1["'h'"]:::process
        B2["'e'"]:::process
        B3["'l'"]:::process
        B4["'l'"]:::process
        B5["'o'"]:::process
    end

    Data -->|"Смотрит на начало"| B1

Поскольку структура весит всего 16 байт (два машинных слова), передача строки в функцию по значению (без указателей) обходится процессору практически бесплатно: рантайм просто копирует два 8-байтных регистра CPU (Data и Len). Сами текстовые данные при этом не дублируются.

Неизменяемость (Immutability) и её цена

Фундаментальный инвариант языка: строка в Go абсолютно неизменяема.
После того как строка создана в памяти, вы не можете модифицировать ни один ее байт:

s := "hello"
// s[0] = 'H' // Ошибка компиляции! Cannot assign to s[0]

Mechanical Sympathy: Зачем нужна неизменяемость?

Потокобезопасность без мьютексов (Mutex): Вы можете одновременно читать одну и ту же строку из 10 000 параллельных горутин. Никакие блокировки не нужны: данные гарантированно защищены от модификации.
Разделение памяти (Memory Sharing): Операция среза подстроки (s[1:3]) выполняется за мгновенные $O(1)$. Go не копирует байты подстроки, а создает новый 16-байтный дескриптор StringHeader, поле Data которого просто указывает со смещением на середину оригинального массива.
Защита на уровне сегментов памяти: Если строковый литерал задан в коде программы жестко ("hello"), компилятор помещает массив байт в защищенную секцию бинарного файла — .rodata (Read-Only Data). Любая попытка аппаратно перезаписать этот сектор памяти приведет к системному прерыванию процессора SIGSEGV (Segmentation fault).

Конкатенация: O(N^2) и убийство Garbage Collector'а

Обратной стороной неизменяемости является поведение оператора сложения строк +:

Ловушка / Gotcha: Сложение в цикле

Взгляните на типичный антипаттерн новичка:

var result string
for i := 0; i < 100000; i++ {
    result += "A" // КАТАСТРОФА!
}

При каждом вызове result += "A" рантайм Go не может дописать символ в существующую память. Он вынужден выделять в куче новый массив байт размером Len(старая строка) + Len(добавка) и побайтово копировать туда обе части.
На следующей итерации предыдущая строка превращается в мусор. Для 100 000 итераций такой цикл выделит в куче около 5 Гигабайт временных байтов, нагрузив Garbage Collector и загнав CPU в многосекундные паузы! Сложность алгоритма деградирует до катастрофических $O(N^2)$.

Идиоматичный подход: strings.Builder

Для высокопроизводительной сборки строк создан тип strings.Builder. Под капотом он инкапсулирует динамический срез байт []byte, в который данные дописываются через метод WriteString():

package main

import "strings"

func main() {
    var b strings.Builder
    b.Grow(100000) // Оптимизация! Заранее просим аллокатор выделить память

    for i := 0; i < 100000; i++ {
        b.WriteString("A") 
    }
    result := b.String()
    _ = result
}

Под капотом: Магия Zero-Copy

В отличие от классического bytes.Buffer, который при вызове .String() создает новую строку и полностью копирует в нее байтовый массив, strings.Builder выполняет Zero-Copy конвертацию.
Заглянем в исходный код метода String():

func (b *Builder) String() string {
    return unsafe.String(unsafe.SliceData(b.buf), len(b.buf))
}

С помощью пакета unsafe (а именно функций unsafe.String и unsafe.SliceData) компилятор возвращает новый заголовок StringHeader, который напрямую указывает на внутренний массив b.buf. Никакого копирования памяти! Писать в Builder после вызова .String() можно: новые байты лишь дописываются в буфер (или в новый массив при росте), уже отданная строка не меняется. А вот копировать сам Builder по значению нельзя: в нём есть специальный маркер addr, и запись в копию непустого Builder вызовет панику strings: illegal use of non-zero Builder copied by value. Аллокации остаются только на рост буфера — их убирает Grow(n).

Конвертация string <-> []byte

В сетевом бэкенде нам непрерывно приходится преобразовывать текст в байты для отправки в TCP-сокеты или файлы, а затем читать байты обратно в строки:

s := "hello"
b := []byte(s) // Конвертация в байты

b[0] = 'H' // Меняем байт
s2 := string(b) // Конвертация обратно в строку

Собеседование

Вопрос: Выделяет ли память конструкция b :=[]byte(s)?
Ответ: Да, и это дорогая операция со сложностью $O(N)$! Поскольку исходная строка s неизменяема (и может находиться в сегменте .rodata), а срез b обязан быть изменяемым, по семантике языка создаётся копия байтов строки — обычно в новом блоке памяти в куче, если результат убегает из функции (небольшой неубегающий результат компилятор может разместить на стеке). Точно такое же копирование $O(N)$ происходит при обратной конвертации string(b).

Оптимизации компилятора (Compiler Magic)

Создатели Go понимали, что постоянное копирование байтов при конвертациях парализует производительность. Поэтому компилятор gc содержит несколько исключений, при которых аллокация памяти при конвертации string([]byte) оптимизируется в Zero-Allocation (это оптимизации реализации, а не гарантии языка; в ряде случаев gc избегает копирования и в обратном направлении — для неубегающего []byte(s), который только читается):

Поиск в хеш-таблице: Выражение m[string(bytesSlice)]. Компилятор не создает реальную строку в куче: он берет указатель на байты среза и на лету вычисляет хэш для поиска по бакетам.
Конкатенация строк: Конструкция s + string(bytesSlice).
Сравнение: Проверка равенства string(bytesSlice) == "hello".

Практическая эвристика:
Если вы работаете со стандартной библиотекой ввода-вывода (например, формируете ответ HTTP-сервера в http.ResponseWriter или пишете в файл os.File), интерфейс Write требует на вход []byte. Если у вас на руках готовая строка, не конвертируйте ее вручную через w.Write([]byte(s)). Всегда используйте хелпер io.WriteString(w, s): если писатель реализует интерфейс io.StringWriter (как *os.File, *bufio.Writer, *strings.Builder), строка уйдёт без лишнего копирования в куче; иначе хелпер сам сделает w.Write([]byte(s)).

String Interning: Экономия на дубликатах

Что произойдет, если в десятках разных файлов вашего проекта объявлены одинаковые строковые константы?

s1 := "internal_server_error"
s2 := "internal_server_error"

Будет ли эта строка дублироваться в оперативной памяти? Нет.

Компилятор Go производит автоматическое интернирование строк (String Interning) для строковых литералов, известных на этапе компиляции. Он находит все идентичные строки и сохраняет их в единственном экземпляре в секции .rodata. Переменные s1 и s2 получают независимые 16-байтные дескрипторы, указатели Data которых ссылаются на один и тот же адрес памяти.

Однако помните: рантайм не интернирует динамические строки автоматически. Если ваш сервис читает из базы данных миллионы одинаковых записей со статусом "success", рантайм честно выделит независимый кусок памяти под каждую из них. Для строк, полученных во время работы (из сети, из файла), интернирование даёт пакет unique (Go 1.23): h := unique.Make(s) возвращает компактный дескриптор, одинаковый для равных строк.

И помните обратную сторону разделения памяти подстроками: s[:10] от строки в 1 МБ удерживает от сборщика мусора весь мегабайт. Чтобы отрезать независимую копию, используйте strings.Clone (Go 1.18).

Итог

StringHeader: 16-байтная структура (Data, Len). Передача строк по значению столь же легковесна, как копирование двух регистров процессора.
Неизменяемость: Строки монолитны. Срез подстроки s[1:5] бесплатен, так как разделяет память с оригинальной строкой.
Конкатенация: Избегайте сложения строк через += в циклах. Всегда используйте strings.Builder с методом Grow(): аллокации остаются только на рост буфера (Grow убирает и их), а String() отдаёт результат без копирования (Zero-Copy).
Конвертация: Приведение []byte(s) производит $O(N)$ копирование (обычно в куче, если результат убегает). Используйте io.WriteString для потокового ввода-вывода без лишних конвертаций.
String Interning: Строковые литералы кода интернируются компилятором в единственном экземпляре в секции .rodata.

Мы завершили изучение встроенных примитивных типов и коллекций языка Go. Теперь пришло время исследовать то, как инженер моделирует предметную область. Как сгруппировать разнородные поля сущности «Пользователь» или «Транзакция» в единый компактный тип?

В следующей лекции — 21. Struct. Пользовательские типы данных — мы препарируем структуры, разберем выравнивание памяти (Memory Alignment, Padding) и выясним, почему правильный порядок полей в структуре способен сэкономить десятки мегабайт RAM.