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

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

Вводные слова и зачем изучать менеджер памяти?

Память — это один из самых критичных ресурсов любой программы. Каждый раз, когда вы пишете x = 42 или name = "hello", Python должен где-то в памяти разместить этот объект. А когда объект больше не нужен — освободить занятое место. И всё это должно происходить максимально быстро и эффективно.

Почему это важно для Python-разработчика?

Понимание производительности: почему одна программа ест 100 МБ, а другая — 2 ГБ? Почему создание миллиона мелких объектов быстрее, чем кажется? Ответы кроются в устройстве менеджера памяти.
Дебаг утечек: когда программа течёт по памяти, знание внутренностей аллокатора — ваш лучший друг.
Собеседования: менеджер памяти CPython — одна из любимых тем интервьюеров для Senior-позиций.

Статья не для новичков — я предполагаю, что читатель уже знаком с Python. Как минимум:

Понимает, что всё в Python — объект
Имеет базовое представление о стеке и куче
Слышал про сборщик мусора

Несмотря на объём статьи, мне приходится во многих случаях делать упрощения, чтобы материал было легче усвоить. В некоторых местах я буду обращать на это ваше внимание, а в некоторых — нет.

Краткий ликбез по основам

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

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

Как программы получают память

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

Процесс получения памяти выглядит примерно так:

Программа → просит у ОС → ОС выделяет кусок виртуальной памяти → этот кусок сопоставляется с физической RAM

Ключевой момент: запрос памяти у ОС — это дорогая операция. Каждый такой запрос — это системный вызов (syscall), который переключает контекст из пользовательского пространства в пространство ядра и обратно. Это как если бы каждый раз, когда вам нужен лист бумаги, вы звонили в канцелярский магазин и заказывали доставку.

Иллюстрация 1 — «Дорогой путь к памяти».
Горизонтальная цепочка из четырёх блоков слева направо: «Python-программа» → «syscall (mmap/brk)» → «Ядро ОС» → «Физическая RAM». Между первым и вторым блоком — толстая красная стрелка с подписью «Дорого! Переключение контекста». Стиль: рукописный, тёплые цвета. Блок программы — голубой, ядро ОС — оранжевый, RAM — зелёный. Красная стрелка syscall — акцент, показывающий узкое место.

Что такое malloc и free

В языке C (на котором написан CPython) для работы с динамической памятью используются функции malloc и free:

// Выделяем 100 байт памяти
void *ptr = malloc(100);

// Используем...

// Освобождаем
free(ptr);

malloc — это стандартный аллокатор из библиотеки libc. Он уже достаточно умный — не вызывает syscall на каждый запрос, а запрашивает у ОС большие куски памяти и раздаёт их по частям. Но, как мы скоро увидим, для нужд Python даже malloc недостаточно эффективен.

Почему Python особенный

Python создаёт колоссальное количество объектов. Вот что происходит, когда вы пишете простейший код:

x = [1, 2, 3]

Python создаст минимум 5 отдельных объектов: объект списка, и три объекта int (да, каждое число в Python — полноценный объект в куче). Плюс внутренний массив указателей списка.

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

При этом подавляющее большинство объектов Python — маленькие. Число int занимает 28 байт, строка "hello" — 54 байта, пустой список — 56 байт. Это важная характеристика, которая будет ключевой для нашего проектирования.

Иллюстрация 2 — «Размеры объектов Python».
Столбчатая диаграмма (гистограмма). Ось X — размер объекта в байтах (0–100, 100–200, 200–512, >512). Ось Y — количество объектов. Огромный столбик на диапазоне 0–100 (подпись: «int 28B, float 24B, str ~50B, list 56B»), маленький на 100–200, совсем крошечный на 200–512, и еле заметный на >512. Столбики — градиент от голубого к оранжевому. Крупная подпись сверху: «Большинство объектов Python — мелкие (< 512 байт)». Стиль: рукописный шрифт, мягкие цвета.

Постановка задачи

Итак, представим, что мы инженеры из CPython Team, и перед нами стоит задача — создать эффективный менеджер памяти для интерпретатора Python. Наши требования:

Скорость: выделение и освобождение памяти должно быть максимально быстрым, ведь Python делает это миллионы раз в секунду
Экономность: мы не хотим тр��тить память впустую — overhead на каждый объект должен быть минимальным
Минимум syscall'ов: каждый запрос к ОС — дорогой, мы хотим их минимизировать
Минимум фрагментации: память не должна превращаться в «швейцарский сыр» с кучей мелких дырок

Общий принцип проектирования: дорогие операции выполняем редко (обращения к ОС), а дешёвые — часто (выделение блоков из подготовленных пулов). Грубо говоря, мы строим многоуровневую иерархию кешей — от крупных кусков к мелким.

Проектируем собственный менеджер памяти

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

1. Наивный подход — malloc на каждый объект

Иллюстрация 3 — «Наивный подход: malloc на каждый объект».
Слева — колонка из 6–8 маленьких разноцветных прямоугольников, подписанных «int 28B», «str 54B», «list 56B», «float 24B» и т.д. От каждого объекта отдельная стрелка вправо к большому блоку «malloc()». От malloc ещё стрелки вправо к блоку «ОС». Все стрелки красные и пунктирные, с подписью-счётчиком: «1000 вызовов», «10 000 вызовов»... Общее впечатление — хаос, слишком много стрелок. Красная рамка вокруг всей схемы с надписью «Слишком много вызовов malloc! Медленно!». Стиль: рукописный.

Самое простое, что можно придумать — вызывать malloc для каждого нового объекта, а free — когда объект больше не нужен.

// Создаём объект int
PyObject *obj = (PyObject *)malloc(sizeof(PyLongObject));

// ... используем ...

// Удаляем
free(obj);

Решение вполне рабочее — объекты будут создаваться и удаляться корректно. Но всё ли нас тут устраивает?

Проблема 1: Медленно. malloc — это универсальный аллокатор. Он не знает, что мы создаём миллионы мелких объектов, и на каждый вызов тратит время на поиск подходящего свободного куска памяти, обновление внутренних структур данных и так далее.

Проблема 2: Фрагментация. Представьте: мы создали миллион объектов по 28 байт, потом удалили каждый второй. В памяти образовалось 500 тысяч «дырок» по 28 байт. Теперь, если нам нужно выделить 56 байт, malloc может не найти подходящий непрерывный кусок, хотя свободной памяти у нас полно.

Иллюстрация 4 — «Фрагментация памяти».
Горизонтальная полоска памяти (длинный прямоугольник), разделённая на блоки одинаковой ширины. Блоки чередуются: синий (занят, подпись «28B») — белый/серый с пунктирной рамкой (свободен, «28B») — синий — белый — и так далее, как шахматная доска. Под полоской — стрелка к пустому месту с подписью «Нужно 56 байт подряд» и красный крестик: «Нет непрерывного куска!». Хотя половина памяти свободна. Подпись снизу: «Фрагментация — швейцарский сыр из памяти». Стиль: рукописный, синие занятые блоки, белые свободные.

Проблема 3: Overhead. malloc хранит метаданные для каждого выделенного блока — как минимум, его размер. Для крупных блоков по 10 КБ эти 8-16 байт метаданных — ерунда. Но для объекта int размером 28 байт, дополнительные 16 байт — это +57% overhead!

Как же быть? Нам нужен промежуточный слой — свой собственный аллокатор, который будет запрашивать память у malloc большими кусками, а раздавать маленькими порциями. Давайте его построим.

2. Арены — просим память большими кусками

Если вызывать malloc на каждый мелкий объект дорого, давайте вызывать его реже! А именно — будем запрашивать память большими кусками, а потом раздавать её маленькими порциями сами.

Назовём такой большой кусок памяти — Arena (арена). Каждая арена будет размером 256 КБ (256 * 1024 = 262 144 байт). Это достаточно много, чтобы вместить тысячи мелких объектов, и достаточно мало, чтобы не отъедать слишком много памяти сразу.

// Вместо тысяч вызовов malloc...
PyObject *obj1 = malloc(28);
PyObject *obj2 = malloc(28);
PyObject *obj3 = malloc(28);
// ...

// ...делаем один вызов и получаем большой кусок
void *arena = malloc(256 * 1024);  // 256 KB

// А дальше раздаём из него порциями
PyObject *obj1 = arena;             // первые 28 байт
PyObject *obj2 = arena + 28;        // следующие 28 байт
PyObject *obj3 = arena + 56;        // и так далее...

Иллюстрация 5 — «Арена: один вызов вместо тысячи».
Разделена на две части (левая и правая) разделителем «VS».
Левая часть (красная рамка, подпись «Без арен»): множество маленьких объектов, от каждого стрелка к отдельному вызову malloc. Внизу: «1000 объектов = 1000 вызовов malloc 🐢».
Правая часть (зелёная рамка, подпись «С аренами»): один большой прямоугольник «Arena 256 KB», полученный одним вызовом malloc (одна стрелка). Внутри арены — те же 1000 маленьких объектов, аккуратно уложенных рядами. Внизу: «1000 объектов = 1 вызов malloc ⚡».
Зелёная галочка справа, красный крестик слева. Стиль: рукописный, тёплые цвета.

Красота! Вместо тысяч вызовов malloc мы делаем один. Это уже огромная оптимизация. Но...

Проблема: как раздавать память внутри арены?

Наш простейший подход «сдвигай указатель на N байт» работает, только если все объекты одного размера. Но Python создаёт объекты самых разных размеров — int (28 байт), float (24 байта), str (от 50 байт), list (56 байт)...

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

Иллюстрация 6 — «Фрагментация внутри арены».
Большой прямоугольник «Arena 256 KB». Внутри — блоки разных размеров и цветов: синий 28B (int), зелёный 56B (list), оранжевый 24B (float). Некоторые блоки удалены — на их месте белые «дырки» с пунктирной рамкой разной ширины (28B, 24B, 56B). Стрелка снизу указывает на дырки: «Нужно 40 байт — ни одна дырка не подходит!». Подпись: «Фрагментация переехала внутрь арены. Нужно решение!». Стиль: рукописный.

Знакомо? Когда у всех объектов был один общий malloc, возникали проблемы с фрагментацией. Решение — разделить большой кусок на более мелкие, специализированные части.

3. Пулы — делим арену на части

Разобьём каждую арену на пулы (Pool) размером 4 КБ каждый. Почему именно 4 КБ? Потому что это размер страницы памяти в большинстве операционных систем, и выравнивание по страницам даёт нам бонус к производительности.

Каждая арена в 256 КБ вмещает ровно 64 пула (256 * 1024 / 4096 = 64).

Иллюстрация 7 — «Арена разбита на пулы».
Большой прямоугольник «Arena 256 KB» разделён горизонтальными линиями на 8 рядов по 8 маленьких квадратов = 64 пула. Каждый квадрат подписан «4 KB». Несколько пулов подсвечены разными цветами: голубые (блоки по 32B), зелёные (блоки по 64B), фиолетовые (блоки по 16B), остальные — серые (пустые/незанятые). Подпись: «Арена = 64 пула по 4 КБ. Каждый пул — для объектов своего размера». Стиль: рукописный, решётка с цветными ячейками.

А теперь ключевая идея — каждый пул будет обслуживать объекты только одного размера. Один пул — для объектов по 16 байт, другой — для объектов по 32 байта, третий — для объектов по 48 байт, и так далее. Таким образом, внутри каждого пула все блоки одинакового размера, и фрагментация исключена полностью!

Иллюстрация 8 — «Пулы с блоками одного размера».
Три прямоугольника-пула рядом, каждый подписан «Pool 4 KB».
Пул 1 (голубой): нарезан на множество маленьких блоков по 16B — видно ~20 блоков. Подпись: «блоки по 16 байт — 256 штук».
Пул 2 (зелёный): нарезан на блоки покрупнее по 32B — видно ~10 блоков. Подпись: «блоки по 32 байт — 128 штук».
Пул 3 (оранжевый): нарезан на ещё более крупные блоки по 64B — видно ~5 блоков. Подпись: «блоки по 64 байт — 64 штуки».
Внизу зелёная галочка и подпись: «Все блоки одного размера → фрагментации нет!». Стиль: рукописный, три пула разных цветов.

Но возникает вопрос — каких именно размеров будут наши пулы? Мы же не можем создать пул для каждого возможного размера объекта — их слишком много.

4. Классы размеров — 8, 16, 24, ..., 512

Давайте введём классы размеров (size classes). Вместо того чтобы обслуживать каждый возможный размер, мы округлим запрошенный размер вверх до ближайшего кратного 8 байтам. Получается вот такой набор:

8, 16, 24, 32, 40, 48, 56, 64, 72, ..., 504, 512

Всего 64 класса размеров (от 8 до 512 с шагом 8). Если Python хочет создать объект int размером 28 байт, мы округлим до 32 и разместим его в пуле с блоками по 32 байта.

Запрошено 28 байт → Класс размера: 32 байта
Запрошено 13 байт → Класс размера: 16 байт
Запрошено 64 байта → Класс размера: 64 байта
Запрошено 1 байт  → Класс размера: 8 байт

Иллюстрация 9 — «Классы размеров: округление вверх».
Горизонтальная числовая ось от 0 до 520. На ней отмечены деления через каждые 8 байт: 8, 16, 24, 32, 40, …, 504, 512. Деления выглядят как «корзины» или «слоты».
Две стрелки-примера сверху:
— Красная стрелка от числа «28» падает в корзину «32» с подписью «int (28B) → класс 32».
— Зелёная стрелка от числа «54» падает в корзину «56» с подписью «str "hello" (54B) → класс 56».
Справа от оси — красная вертикальная черта на отметке 512 с подписью «Граница! > 512B → обычный malloc».
Подпись снизу: «64 класса с шагом 8 байт. Теряем максимум 7 байт на округлении». Стиль: рукописный, ось — тёплый коричневый.

Да, мы теряем немного памяти на округлении — для объекта в 28 байт мы выделяем 32, «теряя» 4 байта. Но это копейки по сравнению с тем, что мы получаем взамен — полное отсутствие фрагментации внутри пула и мгновенное выделение памяти.

А что если объект больше 512 байт? Тогда наш менеджер просто передаст запрос стандартному malloc. Такие объекты встречаются гораздо реже, и для них overhead malloc уже не критичен. Это разделение «мелкие объекты — наш аллокатор, крупные — malloc» является ключевым архитектурным решением CPython.

Иллюстрация 10 — «Развилка: pymalloc vs malloc».
В центре — ромб-развилка с подписью «Размер объекта?». Стрелка влево (зелёная): «≤ 512 байт» ведёт к блоку «pymalloc (Arena → Pool → Block)» — блок зелёный, с подписью «Быстро! O(1)». Стрелка вправо (оранжевая): «> 512 байт» ведёт к блоку «malloc (системный)» — блок оранжевый, с подписью «Медленнее, но редко нужен». Внизу подпись: «Порог 512 байт — граница между двумя мирами». Стиль: рукописный, развилка в центре.

Давайте посмотрим, как устроен пул изнутри. Пул на 4 КБ с блоками по 32 байта вместит 4096 / 32 = 128 блоков (минус немного на заголовок пула). А пул с блоками по 8 байт — целых 4096 / 8 = 512 блоков.

Пул (4 KB) для блоков по 32 байта:
┌──────────┬───────┬───────┬───────┬───────┬───────┬─────┐
│ Заголовок│Блок #0│Блок #1│Блок #2│Блок #3│Блок #4│ ... │
│  (meta)  │ 32 B  │ 32 B  │ 32 B  │ 32 B  │ 32 B  │     │
└──────────┴───────┴───────┴───────┴───────┴───────┴─────┘

5. Freelists — переиспользуем блоки

Отлично, у нас есть пулы с блоками одинакового размера. Но как мы будем управлять свободными блоками? Когда объект удаляется, мы не хотим просто «забыть» про его блок — мы хотим его переиспользовать для нового объекта.

Самое простое и элегантное решение — freelist (список свободных блоков). Идея проста: каждый свободный блок содержит указатель на следующий свободный блок, образуя односвязный список.

Иллюстрация 11 — «Freelist — цепочка свободных блоков».
Горизонтальная полоска пула из ~10 блоков. Занятые блоки — сплошные синие с подписями «int», «str», «int». Свободные блоки — белые с пунктирной рамкой. От заголовка пула (слева, подписан «freeblock →») идёт красная стрелка к первому свободному блоку. От него — красная стрелка к следующему свободному (перепрыгивая через занятые). И так далее — цепочка красных стрелок соединяет только свободные блоки. Последний свободный указывает на NULL.
Подпись: «Свободные блоки образуют цепочку. Указатель хранится прямо внутри блока — бесплатно!». Стиль: рукописный, синие занятые блоки, белые пустые, красные стрелки freelist.

Когда нужно выделить память:

Берём первый блок из freelist (по указателю freeblock)
Сдвигаем freeblock на следующий свободный блок
Возвращаем блок вызывающему коду

Когда нужно освободить память:

Освобождённый блок ставим в начало freelist
Он теперь указывает на бывший первый свободный блок
freeblock теперь указывает на только что освобождённый блок

Выделение (O(1)):                  Освобождение (O(1)):
                                   
freeblock → [B3] → [B5] → [B9]    freeblock → [B3] → [B5] → [B9]
                                              ↑
Берём B3:                          Освобождаем B7:
freeblock → [B5] → [B9]           freeblock → [B7] → [B3] → [B5] → [B9]

Обе операции выполняются за O(1) — константное время! Никакого поиска, никаких циклов. Это невероятно быстро.

Обратите внимание на хитрый трюк: указатель на следующий свободный блок хранится внутри самого свободного блока. Раз блок свободен, его содержимое нам не нужно, и мы можем использовать это пространство для служебных целей. Ноль дополнительных затрат памяти на freelist!

6. Три состояния пула

Пул с блоками может находиться в одном из трёх состояний:

Full — все блоки заняты, свободных нет
Used — часть блоков занята, часть свободна (есть непустой freelist)
Empty — все блоки свободны

Иллюстрация 12 — «Три состояния пула».
Три пула рядом, каждый — горизонтальная полоска из блоков.
Full (красная рамка): все блоки залиты синим цветом, подпись «Все занято. Бесполезен для аллокации».
Used (жёлтая рамка): часть блоков синие, часть белые с пунктирной рамкой, видна цепочка freelist. Подпись: «Есть свободные блоки. Именно отсюда берём!». Жёлтая звёздочка акцента.
Empty (серая рамка): все блоки белые/серые, подпись «Все свободны. Можно переназначить на другой размер».
Стрелки переходов: «освобождение блока» от Full к Used, «выделение последнего» от Used к Full, «освобождение всех» от Used к Empty. Стиль: рукописный, три состояния в ряд.

Когда Процессор (в терминах нашей аналогии) ищет блок для нового объекта, ему нужны только Used пулы — в них есть свободные блоки. Full-пулы бесполезны — там всё занято. Empty-пулы — тоже можно использовать, но лучше их придержать.

Чтобы быстро находить нужный пул, для каждого класса размеров мы ведём список Used-пулов — usedpools. Это массив из 64 элементов (по числу классов размеров), каждый — указатель на двусвязный список Used-пулов данного размера.

usedpools[0]  → Pool(8B) ↔ Pool(8B) ↔ Pool(8B)     // пулы для объектов ≤8 байт
usedpools[1]  → Pool(16B) ↔ Pool(16B)               // пулы для объектов ≤16 байт
usedpools[2]  → Pool(24B)                            // пулы для объектов ≤24 байт
...
usedpools[63] → Pool(512B) ↔ Pool(512B)             // пулы для объектов ≤512 байт

Иллюстрация 13 — «usedpools — быстрый индекс по размерам».
Слева — вертикальный массив (таблица) «usedpools» с ячейками: [8B], [16B], [24B], [32B], …, [512B]. От каждой ячейки — горизонтальная стрелка вправо к цепочке (двусвязному списку) пулов-прямоугольников.
Цепочка от [32B] — самая длинная (3 пула), подсвечена голубым. Подпись рядом: «Популярный размер — много пулов».
Цепочка от [512B] — короткая (1 пул), бледная. Подпись: «Редкий размер».
Отдельно нарисован Full-пул (серый, перечёркнутый), не связанный ни с одной цепочкой. Подпись: «Full-пулы не в usedpools — в них нечего брать».
Общая подпись: «O(1) доступ: знаем размер → сразу находим пул со свободными блоками». Стиль: рукописный, массив слева, цепочки вправо.

Полный алгоритм выделения памяти теперь выглядит так:

Определяем класс размера: size_class = (requested_size + 7) / 8
Смотрим в usedpools[size_class]
Если есть Used-пул → берём блок из его freelist
Если нет Used-пула → берём Empty-пул, инициализируем его для данного класса, переводим в Used
Если нет Empty-пула → выделяем новую Arena

А при освобождении:

Определяем, какому пулу принадлежит блок (по адресу)
Возвращаем блок в freelist пула
Если пул был Full → переводим в Used (добавляем в usedpools)
Если пул стал Empty → переводим в Empty (убираем из usedpools)

7. Собираем всё вместе — трёхуровневая иерархия

Давайте теперь посмотрим на всю картину целиком. У нас получилась элегантная трёхуровневая иерархия:

      ┌─────────────────────────────────────────────┐
      │              Arena (256 KB)                  │
      │  ┌─────────┬─────────┬─────────┬─────────┐  │
      │  │Pool 4KB │Pool 4KB │Pool 4KB │  ...    │  │
      │  │┌──┬──┬─┐│┌──┬──┬─┐│┌──┬──┬─┐│         │  │
      │  ││B │B │..│││B │B │..│││B │B │..││         │  │
      │  │└──┴──┴─┘│└──┴──┴─┘│└──┴──┴─┘│         │  │
      │  │ 32B ea. │ 64B ea. │ 16B ea. │         │  │
      │  └─────────┴─────────┴─────────┴─────────┘  │
      └─────────────────────────────────────────────┘

Arena (256 КБ) — большой кусок памяти, полученный одним вызовом malloc. Делится на 64 пула.
Pool (4 КБ) — обслуживает объекты одного класса размера. Содержит блоки и freelist.
Block (8–512 байт) — минимальная единица выделения. Размер кратен 8 байтам.

8. Возврат памяти операционной системе

Мы отлично справляемся с выделением и переиспользованием памяти. Но есть ещё один вопрос — когда и как мы возвращаем память операционной системе?

Здесь CPython поступает хитро. Он не возвращает память ОС при каждом освобождении блока — это было бы слишком дорого. Вместо этого работает следующая логика:

Когда блок освобождается → он возвращается в freelist пула
Когда все блоки пула свободны → пул переходит в состояние Empty
Когда все пулы арены пустые → арена целиком освобождается через free()

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

Иллюстрация 14 — «Арена освобождается только целиком».
Два больших прямоугольника-арены рядом.
Арена 1 (красная рамка): 64 пула, 63 полностью пустые (серые), но в одном пуле — один синий занятый блок (остальные пустые). Красный крестик и подпись: «1 объект из миллиона — и вся арена (256 KB) заблокирована!».
Арена 2 (зелёная рамка): все 64 пула полностью пустые. Зелёная галочка и подпись: «Все пусто → free() → память вернулась ОС».
Подпись снизу: «Один "прилипший" объект может удерживать 256 КБ памяти». Стиль: рукописный, контраст красного и зелёного.

Это может приводить к ситуации, когда ваша программа держит в памяти гораздо больше, чем реально использует. Один «прилипший» объект в арене может удерживать все 256 КБ. Эту особенность полезно знать при отладке потребления памяти.

Для оптимизации возврата арен CPython сортирует арены по заполненности — при выделении памяти предпочтение отдаётся наиболее заполненным аренам. Логика простая: если мы будем заполнять полупустые арены, есть шанс, что менее загруженные арены полностью освободятся и их можно будет вернуть ОС.

А теперь — подсчёт ссылок и сборка мусора

Итак, мы спроектировали эффективный аллокатор, который умеет быстро выделять и переиспользовать память. Но остался один важнейший вопрос — когда именно освобождать память? Как понять, что объект больше не нужен?

9. Reference Counting — считаем ссылки

Самый простой и интуитивно понятный подход — считать, сколько «живых» ссылок указывает на объект. Когда счётчик доходит до нуля — объект можно удалять.

Каждый объект Python хранит в своём заголовке поле ob_refcnt — счётчик ссылок:

import sys

a = [1, 2, 3]
print(sys.getrefcount(a))  # 2 (a + аргумент getrefcount)

b = a
print(sys.getrefcount(a))  # 3 (a + b + аргумент getrefcount)

del b
print(sys.getrefcount(a))  # 2

Когда ob_refcnt падает до 0, объект немедленно удаляется — вызывается его деструктор (__del__), а блок памяти возвращается в freelist пула.

Иллюстрация 15 — «Жизненный цикл счётчика ссылок».
Объект-прямоугольник в центре с полем «refcount» внутри. Четыре кадра (слева направо, как комикс):
Кадр 1: a = obj — от переменной «a» стрелка к объекту. refcount = 1.
Кадр 2: b = a — добавилась стрелка от «b». refcount = 2.
Кадр 3: del b — стрелка от «b» исчезла (перечёркнута). refcount = 1.
Кадр 4: del a — стрелка от «a» исчезла. refcount = 0 → объект взрывается/исчезает (эффект «пуф»), блок возвращается в freelist (стрелка к freelist пула).
Подпись: «refcount = 0 → мгновенное удаление. Детерминированно и предсказуемо». Стиль: рукописный, четыре кадра в ряд как комикс.

Подсчёт ссылок — потрясающе простой и эффективный механизм:

Детерминированный: объект удаляется в тот же момент, когда последняя ссылка пропадает
Инкрементальный: нет пауз «stop the world» — работа размазана по времени
Предсказуемый: __del__ вызывается сразу, что удобно для управления ресурсами (файлы, соединения)

Но у него есть фатальный недостаток — он не справляется с циклическими ссылками.

10. Проблема циклических ссылок

Рассмотрим простой пример:

a = []
b = []
a.append(b)  # a ссылается на b
b.append(a)  # b ссылается на a

del a  # refcount a: 2 → 1 (b всё ещё ссылается)
del b  # refcount b: 2 → 1 (a всё ещё ссылается)

# Оба объекта недостижимы, но refcount = 1 у каждого!
# Утечка памяти!

Иллюстрация 16 — «Циклические ссылки — ловушка для refcount».
Два объекта (прямоугольники): «список A» (голубой) и «список B» (зелёный). Толстая стрелка от A к B (подпись «a.append(b)»), толстая стрелка от B к A (подпись «b.append(a)»). Образуют кольцо.
Переменные «a» и «b» сверху — перечёркнуты красным (del a, del b).
У каждого объекта поле refcount = 1 (подсвечено красным).
Пунктирная линия вокруг обоих объектов с подписью: «Недостижимы из программы, но refcount > 0. Утечка!».
Красный восклицательный знак. Подпись: «Reference counting бессилен перед циклами». Стиль: рукописный, два объекта со стрелками-кольцом., образуя цикл. Даже когда мы удалили все внешние ссылки (переменные a и b), у каждого объекта refcount = 1 из-за внутренней ссылки от другого объекта. Reference counting никогда не сможет их удалить.

Это серьёзная проблема, потому что циклические ссылки в Python встречаются постоянно: объекты хранят ссылку на свой класс, класс — на своих наследников, фреймы функций ссылаются друг на друга через traceback, и так далее.

11. Cycle GC — сборщик циклов

Для решения проблемы циклов нужен дополнительный механизм — циклический сборщик мусора (Cycle GC). Он периодически запускается и ищет группы объектов, которые ссылаются друг на друга, но недостижимы из остальной программы.

Алгоритм работает так (упрощённо):

Находим потенциальных кандидатов — это объекты-контейнеры (списки, словари, экземпляры классов), которые могут содержать ссылки на другие объекты. Простые типы (int, str, float) не могут создавать циклы, поэтому GC их игнорирует.
Удаляем внутренние ссылки — для каждого объекта-кандидата создаём временную копию refcount и уменьшаем её на количество ссылок от других кандидатов. Если после этого временный refcount = 0, значит объект жив только благодаря ссылкам из цикла.
Определяем живые объекты — те, у кого временный refcount > 0, достижимы извне. Всё, на что они ссылаются, тоже живое.
Удаляем мусор — всё остальное — мёртвые циклы, которые можно безопасно удалить.

Иллюстрация 17 — «Алгоритм Cycle GC в 4 шага».
Четыре кадра вертикально (или 2×2 сетка):
Шаг 1 «Находим контейнеры»: несколько объектов — list, dict, object подсвечены жёлтым (кандидаты). int, str, float — серые (игнорируем, не создают циклов).
Шаг 2 «Вычитаем внутренние ссылки»: те же объекты, но стрелки между кандидатами перечёркнуты красным. У каждого кандидата — временный refcount. Те, у кого он стал 0 — подсвечены красным.
Шаг 3 «Определяем живых»: объекты с refcount > 0 — зелёные (живые). Всё, на что они ссылаются — тоже зелёное. Остальные — красные (мусор).
Шаг 4 «Удаляем мусор»: красные объекты исчезают (эффект удаления). Зелёные остаются.
Подпись: «Cycle GC находит "острова" недостижимых объектов». Стиль: рукописный, 4 кадра.

12. Поколения — оптимизируем сборку

Запускать полный обход всех объектов-контейнеров — дорого. Если у нас миллион объектов, то обход миллиона — это ощутимые паузы. Как оптимизировать?

Здесь работает гипотеза поколений (Generational Hypothesis): большинство объектов умирают молодыми. Создали временную переменную в функции — она живёт только пока функция выполняется. Промежуточный список в list comprehension — живёт миллисекунды.

Используя эту гипотезу, разделим все отслеживаемые объекты на три поколения:

Поколение 0 (gen0): все новые объекты попадают сюда. Проверяется чаще всего.
Поколение 1 (gen1): объекты, пережившие одну сборку gen0. Проверяется реже.
Поколение 2 (gen2): объекты, пережившие сборку gen1. Проверяется совсем редко.

import gc
print(gc.get_threshold())  # (700, 10, 10)

Эти три числа означают:

700: когда количество новых аллокаций минус деаллокаций достигает 700, запускается сборка gen0
10: каждые 10 сборок gen0 запускается сборка gen1
10: каждые 10 сборок gen1 запускается сборка gen2

Иллюстрация 18 — «Три поколения GC — конвейер выживания».
Три контейнера слева направо, каждый больше предыдущего:
Gen 0 (маленький, красный/горячий): много мелких объектов внутри. Подпись: «Молодые. Проверяем каждые 700 аллокаций. Большинство умрёт здесь ☠️».
Gen 1 (средний, оранжевый/тёплый): меньше объектов. Подпись: «Средние. Проверяем в 10× реже».
Gen 2 (большой, синий/холодный): мало объектов, но крупных. Подпись: «Долгожители. Проверяем ещё в 10× реже. Модули, классы, глобалы».
Стрелки между ними: «Выжил →» от Gen0 к Gen1, «Выжил →» от Gen1 к Gen2. Стрелки вниз из каждого: «Мусор ☠️» (удалённые объекты).
Подпись: «Гипотеза поколений: большинство объектов умирают молодыми». Стиль: рукописный, три контейнера с градиентом от красного к синему.

Логика простая: если объект пережил сборку — значит, скорее всего, он живёт долго, и проверять его так часто не нужно. Мы «повышаем» его в следующее поколение, где проверки реже.

Бонус: Специальные оптимизации

CPython идёт ещё дальше и вводит ряд специальных оптимизаций для самых популярных типов.

Кеш малых целых чисел

Числа от -5 до 256 создаются при запуске интерпретатора и никогда не удаляются. Каждый раз, когда вам нужно число 42 — вы получаете один и тот же объект:

a = 42
b = 42
print(a is b)  # True — это один и тот же объект!

a = 257
b = 257
print(a is b)  # False — разные объекты (вне кеша)

Это экономит огромное количество аллокаций, ведь числа вроде 0, 1, -1, 42 используются в программах постоянно.

Интернирование строк

Короткие строки, состоящие из ASCII-букв, цифр и подчёркиваний, автоматически интернируются — кешируются так, чтобы одинаковые строки были одним объектом:

a = "hello"
b = "hello"
print(a is b)  # True — интернированы

a = "hello world!"
b = "hello world!"
print(a is b)  # False — пробел и '!' мешают интернированию

Free lists для популярных типов

Для самых частых типов (float, list, dict, tuple) CPython ведёт собственные freelists — списки недавно удалённых объектов этих типов. Когда нужен новый float — сначала проверяется freelist, и если там есть готовый «каркас», он переиспользуется без обращения к pymalloc.

Создаём float → проверяем float freelist → пусто → pymalloc (Pool → Block)
Удаляем float → кладём в float freelist (не в Pool!)
Создаём float → проверяем float freelist → есть! → берём оттуда (быстрее!)

Иллюстрация 19 — «Пирамида аллокации — 5 уровней».
Пирамида из 5 горизонтальных полос, сверху вниз (узкая → широкая):
Уровень 1 (самый верхний, узкий, золотой): «Кеши: int -5..256, string interning». Подпись: «Мгновенно — объект уже создан».
Уровень 2 (бирюзовый): «Type freelists: float, list, dict, tuple». Подпись: «Очень быстро — переиспользуем каркас».
Уровень 3 (голубой, широкий): «pymalloc: Arena → Pool → Block». Подпись: «Быстро — O(1) из freelist пула».
Уровень 4 (оранжевый): «malloc (libc)». Подпись: «Медленнее — для объектов > 512 байт».
Уровень 5 (красный, самый широкий): «ОС: mmap / brk». Подпись: «Медленно — syscall, переключение контекста».
Стрелка слева вдоль пирамиды: «Скорость ↑» (вверх быстрее). Стрелка справа: «Каждый уровень пропускает вниз то, что не смог обработать ↓».
Стиль: рукописный, пирамида с градиентом от золотого к красному.

Вот мы и построили эффективный менеджер памяти CPython. Давайте посмотрим на итоговую картину:

┌──────────────────────────────────────────────────────────────────┐
│                         Python Code                              │
│                    x = 42, name = "hello"                        │
└────���─────────────────────┬───────────────────────────────────────┘
                           │
                           ▼
┌──────────────────────────────────────────────────────────────────┐
│  Уровень 0: Кеши и специальные случаи                           │
│  • Кеш int (-5..256)                                             │
│  • Интернирование строк                                         │
│  • Type-specific freelists (float, list, dict, tuple)            │
└──────────────────────────┬───────────────────────────────────────┘
                           │  Не нашли в кеше?
                           ▼
┌──────────────────────────────────────────────────────────────────┐
│  Уровень 1: pymalloc (объекты ≤ 512 байт)                       │
│  ┌────────────────────────────────────────────────┐              │
│  │ usedpools[size_class] → Pool → freelist → Block│              │
│  └────────────────────────────────────────────────┘              │
│  • 64 класса размеров (8, 16, 24, ..., 512)                     │
│  • Arena (256KB) → Pool (4KB) → Block (8-512B)                   │
│  • Freelist для O(1) аллокации/деаллокации                       │
└──────────────────────────┬───────────────────────────────────────┘
                           │  Объект > 512 байт?
                           ▼
┌──────────────────────────────────────────────────────────────────┐
│  Уровень 2: malloc / libc                                        │
│  • Стандартный системный аллокатор                               │
│  • Для крупных объектов                                          │
└──────────────────────────┬───────────────────────────────────────┘
                           │
                           ▼
┌──────────────────────────────────────────────────────────────────┐
│  Уровень 3: Операционная система                                 │
│  • mmap / brk / VirtualAlloc                                     │
│  • Виртуальная → Физическая память                               │
└──────────────────────────────────────────────────────────────────┘

Параллельно работают:
┌──────────────────────────┐  ┌──────────────────────────────────┐
│  Reference Counting      │  │  Cycle GC                        │
│  • ob_refcnt на объекте  │  │  • 3 поколения (gen0, gen1, gen2)│
│  • Мгновенное удаление   │  │  • Пороги: 700 / 10 / 10        │
│  • Не ловит циклы!       │  │  • Ловит циклические ссылки      │
└──────────────────────────┘  └──────────────────────────────────┘

Иллюстрация 20 — «Полная схема менеджера памяти CPython» (главная иллюстрация статьи).
Большая схема, объединяющая всё. В центре — вертикальная цепочка из 4 уровней (сверху вниз):
«Python Code» (x = 42, name = "hello") — верхний блок.
«Кеши и freelists» — проверяем кеш int, interning строк, type-specific freelists.
«pymalloc» — большой блок с usedpools, Arena (256KB), Pool (4KB), Block. Внутри видны цветные пулы с блоками и freelist-стрелками.
«malloc / ОС» — нижний уровень, тусклый, используется редко. Справа от основной цепочки — два блока сбоку: — «Reference Counting» (ob_refcnt, мгновенное удаление, не ловит циклы). — «Cycle GC» (3 поколения, пороги 700/10/10, ловит циклы). Стрелки между ними показывают: refcount освобождает блок → возвращается в freelist пула. GC находит циклы → освобождает → freelist. Размер: широкая горизонтальная схема. Стиль: рукописный, тёплые цвета. Это ГЛАВНАЯ иллюстрация статьи — должна быть самой детальной и красивой.

Практические выводы

Знание устройства менеджера памяти даёт конкретные практические преимущества:

1. Понимание потребления памяти. Каждый объект Python имеет overhead: 16 байт на заголовок (ob_refcnt + ob_type) + данные + выравнивание. Число int(1) занимает 28 байт. Словарь из 10 элементов — сотни байт. Зная это, вы можете оценивать потребление памяти ваших структур данных.

2. Миллион мелких объектов — это нормально. Благодаря pymalloc, создание миллиона мелких объектов работает быстро. Не бойтесь создавать много маленьких объектов — аллокатор оптимизирован именно под это.

3. Осторожно с крупными объектами. Объекты > 512 байт обходят pymalloc и идут через обычный malloc. Если вы создаёте и удаляете миллионы крупных объектов — это будет медленнее.

4. Циклические ссылки — не приговор, но знайте про них. GC справится, но лучше использовать weakref где возможно, и помнить, что __del__ у объектов в циклах может вызвать проблемы.

5. Память не всегда возвращается ОС. Даже если вы удалили миллион объектов, память может остаться за процессом Python из-за «прилипших» объектов в аренах. Это нормальное поведение, а не утечка.

Препарируем менеджер памяти на практике

Теория — это прекрасно, но давайте посмотрим на всё это своими глазами. CPython предоставляет несколько инструментов для наблюдения за работой менеджера памяти. Давайте ими воспользуемся.

sys — заглядываем внутрь объектов

Начнём с самого простого — посмотрим, сколько памяти занимают разные объекты:

import sys

# Размеры базовых типов
print(sys.getsizeof(1))           # 28 байт — int
print(sys.getsizeof(3.14))        # 24 байта — float
print(sys.getsizeof("hello"))     # 54 байта — str (5 символов)
print(sys.getsizeof(""))          # 49 байт — пустая строка (overhead!)
print(sys.getsizeof([]))          # 56 байт — пустой список
print(sys.getsizeof([1, 2, 3]))   # 88 байт — список из 3 элементов
print(sys.getsizeof({}))          # 64 байта — пустой dict
print(sys.getsizeof((1, 2, 3)))   # 64 байта — tuple из 3 элементов

Обратите внимание: пустая строка уже занимает 49 байт! Это тот самый overhead объекта Python — заголовок (ob_refcnt + ob_type), хеш, длина, и прочие служебные поля. Каждый «hello» — это не 5 байт, а 54.

А теперь интересный эксперимент — проверим кеш малых целых:

import sys

# Числа -5..256 — это синглтоны, они всегда один и тот же объект
a = 256
b = 256
print(a is b)  # True
print(sys.getrefcount(a))  # Большое число — много кто ссылается на 256

a = 257
b = 257
print(a is b)  # False — разные объекты, кеш не работает

tracemalloc — отслеживаем аллокации

tracemalloc — мощный встроенный инструмент для отслеживания аллокаций памяти. Он позволяет увидеть, где именно в коде выделяется память и сколько.

Базовое использование — кто ест память?

import tracemalloc

tracemalloc.start()

# Ваш код, потребляющий память
data = [dict(key=i, value="x" * 100) for i in range(10_000)]

snapshot = tracemalloc.take_snapshot()
top_stats = snapshot.statistics("lineno")

print("Топ-10 аллокаций по строкам кода:")
for stat in top_stats[:10]:
    print(stat)

Вывод покажет что-то вроде:

<stdin>:5: size=6400 KiB, count=50000, average=131 B

Это значит: строка 5 (создание списка словарей) выделила 6.4 МБ в 50 000 аллокациях, в среднем по 131 байт на аллокацию.

Отслеживаем утечки — сравнение снапшотов

Самый мощный приём — сделать два снапшота и сравнить их. Всё, что выросло между снапшотами — потенциальная утечка:

import tracemalloc

tracemalloc.start()

# Снапшот "до"
snapshot1 = tracemalloc.take_snapshot()

# Код, который подозреваем в утечке
leaked_data = []
for i in range(1000):
    leaked_data.append("x" * 1000)  # Строки, которые никогда не освобождаются

# Снапшот "после"
snapshot2 = tracemalloc.take_snapshot()

# Сравниваем
top_stats = snapshot2.compare_to(snapshot1, "lineno")

print("Разница между снапшотами (потенциальные утечки):")
for stat in top_stats[:5]:
    print(stat)

Вывод покаж��т прирост памяти с точным указанием строки кода:

<stdin>:9: size=1024 KiB (+1024 KiB), count=1000 (+1000), average=1049 B

Группировка по файлам — находим «прожорливые» модули

import tracemalloc

tracemalloc.start()

# ... ваш код ...

snapshot = tracemalloc.take_snapshot()

# Группируем по файлам вместо строк
top_stats = snapshot.statistics("filename")

print("Потребление памяти по файлам:")
for stat in top_stats[:10]:
    print(f"  {stat.traceback}: {stat.size / 1024:.1f} KiB")

Трассировка — откуда пришла аллокация?

Если включить трассировку с глубиной стека, можно увидеть полный путь вызовов:

import tracemalloc

# Число — глубина стека вызовов для трассировки
tracemalloc.start(25)

# ... ваш код ...

snapshot = tracemalloc.take_snapshot()
top_stats = snapshot.statistics("traceback")

# Смотрим самую «прожорливую» аллокацию
stat = top_stats[0]
print(f"Самая крупная аллокация: {stat.size / 1024:.1f} KiB")
print("Стек вызовов:")
for line in stat.traceback.format():
    print(f"  {line}")

Это невероятно полезно для отладки — вы увидите не просто «строка X выделила память», а полную цепочку вызовов, которая к этому привела.

gc — заглядываем в сборщик мусора

Модуль gc позволяет наблюдать за работой циклического сборщика мусора:

import gc

# Текущие пороги поколений
print(gc.get_threshold())  # (700, 10, 10)

# Счётчики: (аллокации с последней сборки gen0,
#             сборок gen0 с последней сборки gen1,
#             сборок gen1 с последней сборки gen2)
print(gc.get_count())  # например: (654, 3, 1)

# Сколько объектов отслеживается GC в каждом поколении
print(f"Gen 0: {len(gc.get_objects(0))} объектов")
print(f"Gen 1: {len(gc.get_objects(1))} объектов")
print(f"Gen 2: {len(gc.get_objects(2))} объектов")

Отлавливаем циклические ссылки

import gc

# Включаем режим отладки — GC будет сообщать о найденных циклах
gc.set_debug(gc.DEBUG_SAVEALL)

# Создаём цикл
a = []
b = []
a.append(b)
b.append(a)
del a, b

# Принудительно запускаем сборку
collected = gc.collect()
print(f"Собрано объектов: {collected}")

# gc.garbage содержит объекты, которые GC не смог удалить
# (например, объекты с __del__ в циклах — в старых версиях Python)
print(f"Неудаляемый мусор: {gc.garbage}")

Мониторим GC-паузы с помощью коллбэков

import gc
import time

def gc_callback(phase, info):
    if phase == "start":
        gc_callback._start = time.monotonic()
    elif phase == "stop":
        elapsed = time.monotonic() - gc_callback._start
        print(f"GC gen{info['generation']}: "
              f"собрано {info['collected']}, "
              f"недостижимых {info['uncollectable']}, "
              f"время {elapsed*1000:.2f}мс")

gc.callbacks.append(gc_callback)

# Теперь каждая сборка мусора будет логироваться
data = []
for i in range(10_000):
    data.append({i: [i]})

Практический пример: ищем утечку в web-приложении

Вот реальный паттерн, который часто вызывает проблемы:

import tracemalloc
import gc

tracemalloc.start(10)

# Симулируем обработку запросов
cache = {}

def handle_request(request_id):
    # Ошибка: кеш растёт бесконечно, ключи никогда не удаляются
    result = {"id": request_id, "data": "x" * 500}
    cache[request_id] = result
    return result

# Снапшот до нагрузки
snapshot1 = tracemalloc.take_snapshot()

# Обрабатываем 10_000 "запросов"
for i in range(10_000):
    handle_request(i)

# Снапшот после
snapshot2 = tracemalloc.take_snapshot()

# Ищем утечку
stats = snapshot2.compare_to(snapshot1, "lineno")
print("Потенциальные утечки:")
for stat in stats[:5]:
    print(f"  {stat}")

# Проверяем состояние GC
print(f"\nОтслеживаемые объекты GC: {len(gc.get_objects())}")
print(f"Размер кеша: {len(cache)}")
print(f"Память кеша: {sum(tracemalloc.get_object_traceback(v) is not None 
                         for v in cache.values())}")

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

Free-threaded Python 3.13 — революция в менеджере памяти

В Python 3.13 произошло, пожалуй, самое значительное изменение в архитектуре CPython за последние 20 лет — появился free-threaded режим (он же «no-GIL» или PEP 703). И менеджер памяти пришлось переписать практически с нуля. Давайте разберёмся, почему и что изменилось.

Зачем всё менять?

Вспомним: весь наш прекрасный менеджер памяти (Arena → Pool → Block) работал в предположении, что в каждый момент времени только один тред выполняет Python-код — это гарантировал GIL (Global Interpreter Lock). Именно поэтому usedpools, freelists, и даже ob_refcnt не нуждались в синхронизации между тредами.

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

mimalloc — новый аллокатор

Вместо того чтобы латать старый pymalloc, разработчики CPython перешли на mimalloc — высокопроизводительный аллокатор от Microsoft Research, специально спроектированный для многопоточных приложений.

Ключевая идея mimalloc: у каждого треда есть собственная «куча» (thread-local heap). Когда тред хочет выделить память, он работает со своей кучей без каких-либо блокировок. Блокировки нужны только в редких случаях — например, когда один тред освобождает объект, выделенный другим тредом.

Старый pymalloc (с GIL):           mimalloc в Python 3.13 (без GIL):

  Тред 1 ──┐                       Тред 1 → [Своя куча] → Pool → Block
            ├── GIL → usedpools     Тред 2 → [Своя куча] → Pool → Block
  Тред 2 ──┘                       Тред 3 → [Своя куча] → Pool → Block
                                    
  Один тред работает,               Все треды работают параллельно,
  остальные ждут                    каждый со своими структурами

Иллюстрация 21 — «Старый pymalloc vs новый mimalloc».
Разделена на две части (левая и правая) разделителем «Python ≤3.12 vs Python 3.13+».
Левая (с GIL): Несколько тредов (Thread 1, Thread 2, Thread 3) стоят в очереди перед одним замком (GIL). Только один проходит к общему блоку «usedpools» (один на всех). Подпись: «Один тред работает, остальные ждут GIL».
Правая (без GIL): Каждый тред идёт к своей собственной «куче» (Thread-local heap). Нет замка, нет очереди. Три параллельные стрелки. Подпись: «Каждый тред — своя куча, без блокировок ⚡».
Внизу правой части: маленькая сноска «Редкий случай: освобождение чужого объекта → атомарная операция (lock-free)».
Стиль: рукописный, левая часть — красноватая (медленно), правая — зеленоватая (быстро).

Это очень похоже на идею, которую мы уже обсуждали: вместо одной общей очереди (usedpools), у каждого «процессора» (треда) своя локальная — и блокировки исчезают.

Biased reference counting — хитрый подсчёт ссылок

С подсчётом ссылок проблема ещё серьёзнее. ob_refcnt изменяется при каждом присваивании, при каждом вызове функции, при каждом обращении к элементу списка. Если сделать этот счётчик атомарным (через atomic operations), производительность упадёт катастрофически — атомарные операции в 10-100 раз дороже обычного инкремента.

Решение в Python 3.13 — biased reference counting (PEP 703). Идея основана на наблюдении: в подавляющем большинстве случаев объект используется тем же тредом, который его создал.

Каждый объект хранит два счётчика:

Локальный (biased) — для треда-владельца. Изменяется обычными (быстрыми) операциями, без атомарности.
Общий (shared) — для всех остальных тредов. Изменяется атомарными операциями.

struct PyObject {
    // Вместо одного ob_refcnt:
    Py_ssize_t ob_ref_local;   // Быстрый, для треда-владельца
    _Py_atomic_ssize_t ob_ref_shared;  // Атомарный, для остальных
    PyTypeObject *ob_type;
};

Когда тред-владелец работает со своим объектом (а это ~95% случаев), он модифицирует ob_ref_local — это обычная запись в память, без блокировок, без атомарных операций. Только когда «чужой» тред берёт или отпускает ссылку, он обращается к ob_ref_shared через атомарную операцию.

Объект удаляется, когда ob_ref_local + ob_ref_shared == 0.

Deferred reference counting — отложенный подсчёт

Ещё одна оптимизация — отложенный подсчёт ссылок для «бессмертных» или часто используемых объектов. Некоторые объекты (модули, встроенные функции, None, True, False) ссылаются друг на друга так часто, что постоянное изменение счётчика — бессмысленная трата ресурсов.

Для таких объектов CPython 3.13 использует специальный флаг: счётчик ссылок «заморожен», и изменения в ob_refcnt просто пропускаются. Такие объекты не удаляются подсчётом ссылок — за ними следит только GC.

Что изменилось в GC

Циклический сборщик мусора тоже пришлось адаптировать:

Stop-the-world стал обязательным: при сборке мусора все треды должны быть приостановлены. В обычном CPython (с GIL) это было бесплатно — GIL и так блокировал все треды. В free-threaded режиме нужна явная синхронизация.
Поколения переработаны: вместо трёх отдельных списков поколений теперь используется схема с «младшим» и «старшим» пространствами. Это уменьшает количество полных сборок и упрощает многопоточную работу.

Как попробовать

В Python 3.13 free-threaded режим — это экспериментальная фича. Она доступна через специальную сборку:

# Установка через pyenv
pyenv install 3.13.0t    # 't' в конце — free-threaded build

# Или при сборке из исходников
./configure --disable-gil
make

Проверить, работаете ли вы в free-threaded режиме:

import sys
print(sys._is_gil_enabled())  # False в free-threaded сборке

Сравнение: до и после

                          CPython ≤ 3.12          CPython 3.13 (free-threaded)
                          ─────────────           ───────────────────────────
Аллокатор                 pymalloc                mimalloc (thread-local heaps)
Reference counting        ob_refcnt (простой)     ob_ref_local + ob_ref_shared
GIL                       Есть                    Нет (опционально)
Freelists                 Глобальные              Per-thread
GC паузы                  «Бесплатные» (GIL)      Stop-the-world (явный)
Многопоточная аллокация   Невозможна (GIL)        Без блокировок (thread-local)

Важно понимать: free-threaded Python 3.13 — это первый шаг. Производительность однопоточного кода пока немного ниже (5-10%) из-за overhead'а на biased refcounting и атомарные операции. Но многопоточный код, который раньше упирался в GIL, теперь может масштабироваться линейно по количеству ядер — и это огромный шаг вперёд.

Спасибо всем, кто дочитал статью до конца — вы проделали огромную работу, и это достойно уважения! Теперь самое время отправиться на собеседование, чтобы опробовать новые знания в боевой обстановке ;)

Менеджер памяти CPython — проектируем с нуля, простым языком