ISRPO1/Лекции/Go/Попков

# Лекция 1: Управление памятью в Go: архитектура, эвакуация и влияние на latency

Управление памятью в компилируемых языках программирования традиционно требовало либо ручного контроля (malloc/free), либо значительных накладных расходов на сборку мусора (GC). Язык **Go** (Golang) предлагает компромиссное решение: автоматическое управление памятью с **неблокирующим конкурентным сборщиком мусора**, спроектированным для минимизации задержек (latency) в высоконагруженных системах.

Ключевая архитектурная особенность — это разделение кучи (heap) на области, управляемые потокобезопасными кэшами (mcache). Каждый поток выполнения (P в терминах планировщика Go) имеет свой локальный кэш мелких объектов. Это реализует принцип **безлоковой аллокации**: выделение памяти под микрообъекты происходит простым увеличением указателя в пределах локальной страницы, без захвата глобальных блокировок мьютексов.

![Изображение: схема иерархии памяти Go (mcache, mcentral, mheap). Ключевые слова для поиска: "Go memory allocation diagram mcache mheap"]()

### Таблица 1. Уровни аллокации памяти в Go
| Компонент | Уровень | Область видимости | Механизм синхронизации |
| -------- | -------- | -------- | -------- |
| **mcache** | Поток (P) | Локальный кэш | Без блокировок (lock-free) |
| **mcentral** | Глобальный | Список для размера класса | Мьютексы (при балансировке) |
| **mheap** | Глобальный | Вся куча (arena) | Мьютексы (при запросе у ОС) |

Сборщик мусора реализует **трехцветный алгоритм пометки и заметания (mark-and-sweep)** и работает конкурентно с основным кодом. Однако ключевая фаза — **фаза остановки мира (Stop The World)** — сведена к минимуму и происходит только для начала цикла и для завершающей пометки. Инженеру важно понимать концепцию **эвакуации (evacuation)** — хотя в стандартном GC Go нет явной эвакуции объектов как в поколенческих сборщиках, есть процесс **фрагментации кучи**. Чтобы избежать деградации производительности, Go периодически выполняет дефрагментацию, перемещая или подчищая страницы, что может вызвать микро-паузы.

Для снижения нагрузки на GC разработчики применяют **пулы объектов (sync.Pool)**. Использование sync.Pool позволяет переиспользовать уже выделенные структуры, снимая нагрузку со сборщика мусора и уменьшая количество аллокаций в куче. Это критически важно для приложений реального времени (например, прокси-серверов или API Gateway), где каждая миллисекунда задержки на счету.

Таким образом, эффективная работа с памятью в Go требует не только понимания синтаксиса, но и осознанного управления аллокациями: предпочтение стека перед кучей (благодаря анализу побега — escape analysis), переиспользование временных буферов и учет поведения конкурентного GC.