Как работает память в Python

Что такое память и зачем она нужна?

Ни одна компьютерная программа не может работать без данных. А данные, чтобы программа имела к ним доступ, должны располагаться в оперативной памяти вашего компьютера. Но что такое оперативная память на самом деле? Когда произносишь это словосочетание, многие сразу представляют «железную» плашку, вставленную в материнскую плату, на которой написано что-то типа 16Gb DDR4 2666MHz. И они, разумеется, правы — это действительно физический блок оперативной памяти, в котором, в итоге, все данные и оказываются. Но прежде, чем стать доступной внутри вашей программы, на память (как и на всё остальное аппаратное обеспечение) накладывается куча абстракций.

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

Во-вторых, внутри операционной системы, есть абстракция, называемая «процесс», которая, в том числе, предназначена для изоляции и упрощения работы с ресурсами отдельными программами. Именно процесс «делает вид», что независимо от количества запущенных программ и объема установленной в компьютер оперативной памяти, вашей программе доступно 4 ГБ RAM (на 32-разрядных системах) или сильно больше (на 64-разрядных).

Долгое время, компьютерным программам, хватало этого набора абстракций. Вам нужны данные, вы хотите с ними поработать? Всё просто:

1. Попросите у процесса (ОС) выделить вам немного (одну или несколько страниц) оперативной памяти.

2. Поработайте с ней.

3. Верните ее в операционную систему.

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

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

Механизм памяти в Python

Python — это язык с управляемой памятью. Причем для управления ею он использует несколько механизмов. Я постараюсь коротко осветить основные из них. Для зануд сразу подчеркну, что под Python’ом я понимаю конкретную реализацию CPython, а не какие-то другие версии, в которых всё может работать по-другому :)

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

Оставшаяся свободная виртуальная память может использоваться для хранения информации об объектах Python’а. Для управления этой памятью в CPython используется специальный механизм, который называется аллокатор. Он используется каждый раз, когда вам нужно создать новый объект.

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

Ремарка. Для больших объектов (больше 512 байт) Python выделяет память напрямую у ОС. Обычно таких объектов не очень много в рамках программы, и создаются они нечасто. Поэтому накладные расходы на создание таких объектов напрямую в RAM не так высоки.

Как же устроен аллокатор внутри? Он состоит из частей трёх видов:

• Арена — большой непрерывный кусок памяти (обычно 256 килобайт), содержит несколько страниц виртуальной памяти операционной системы.

• Пул — одна страница виртуальной памяти (обычно 4 килобайта).

• Блок — маленький кусочек памяти, используемый для хранения одного объекта.

Давайте поговорим о них подробнее. Когда Python’у нужно расположить какой-то объект в оперативной памяти он ищет подходящую арену. Если такой нету, он запрашивает новую арену у операционной системы. Что значит «подходящую»? Арены организованы в двусвязный список и отсортированы от самой заполненной к самой свободной. Для добавления нового объекта выбирается САМАЯ ЗАПОЛНЕННАЯ арена. Почему такая странная логика? Это связано с политикой освобождения памяти. Арены — единственное место, в котором происходит запрос и освобождение памяти в Python. Если какая-то арена полностью освобождается от объектов, она возвращается назад операционной системе и память освобождается. Таким образом, чем компактнее живут объекты в рамках арен, тем ниже общее потребление оперативной памяти программой.

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

Каждый пул может быть в одном из трех состояний — used, full и empty. Full означает, что пул полностью занят и не может принять новые объекты. Empty — что пул полностью пустой и может быть использован для хранения новых объектов (при этом пустой пул может быть использован для хранения объектов любого размера). Used — это пул, который используется для хранения объектов, но при этом еще не заполнен полностью.

Python поддерживает списки пулов каждого из размеров и отдельно список пустых пулов. Если вы хотите создать новый объект, то Python сначала пытается найти used-пул с нужным размером блока и расположить объект там. Если used-пула нет, тогда берется empty-пул, и объект создается в нем (а сам пул из статуса empty переводится в статус used). Если и empty-пулов нет, то запрашивается новая арена.

Внутри пула живут блоки. Каждый блок предназначен для хранения одного объекта. В целях унификации размеры блоков фиксированы. Они могут быть размером 8, 16, 24, 32 …. 512 байт. Если Вам нужно 44 байта для хранения объекта, то он будет расположен в блоке на 48 байт. Каждый пул содержит список свободных и занятых блоков (на самом деле, есть еще untouched-блоки, в которых никогда не жили данные, но по сценариям использования они похожи на free-блоки, поэтому не будем на них останавливаться подробно). Когда вы хотите разместить новый объект, берется первый свободный блок, и объект располагается в нем. Когда объект удаляется, его блок помещается в список свободных.

Время жизни объекта и причем тут GIL

Поговорив о том, как происходит выделение и освобождение памяти в Python, стоит отдельно поговорить о том, а как язык управляет временем жизни. Для этого в Python реализовано два механизма:

• Счетчик ссылок.

• Механизм сборки мусора.

Каждый объект в Python — это, в первую очередь, объект, унаследованный от базового класса PyObject. Этот самый PyObject содержит всего два поля: ob_refcnt — количество ссылок, и ob_type — указатель на другой объект, тип данного объекта.

Нас интересует первое поле — ob_refcnt. Это счетчик ссылок на конкретный экземпляр данного класса. Каждый раз, когда мы сохраняем объект в новой переменной, массиве и т.п. (то есть когда мы сохраняем где-то ссылку на объект), мы увеличиваем счетчик ссылок на единицу. Каждый раз, когда мы перестаем использовать переменную, удаляем объект из массива и т.п. (то есть когда ссылка на объект удаляется), мы уменьшаем счетчик ссылок на единицу. Когда он доходит до 0 — объект больше никем не используется и Python его удаляет (в том числе помещая блок, в котором располагался объект, в список пустых).

К сожалению, счетчик ссылок подвержен проблемам в многопоточной среде. Состояния гонки могут приводит к некорректности обновления этого счетчика из разных потоков. Чтобы этого избежать CPython использует GIL — Global Interpreter Lock. Каждый раз, когда происходит работа с памятью, GIL — как глобальная блокировка — препятствует выполнению этих действий одновременно из двух потоков. Он гарантирует, что сначала отработает один, потом другой.

Второй механизм очистки памяти — это сборщик мусора (garbage collector), основанный на идее поколений. Зачем он нам нужен, если есть счетчик ссылок? Дело в том, что счетчик ссылок не позволяет отслеживать ситуации с кольцевыми зависимостями, когда объект A содержит ссылку на B, а B — на A. В таком случае, даже если никто больше не ссылается на объекты A и B, их счетчик всё равно никогда не станет равным нулю и они никогда не удалятся через механизм счетчика ссылок. Для борьбы с такими зависимостями и появился второй механизм (как модуль gc, начиная с версии Python 1.5).

Работает он следующим образом: GC отслеживает объекты (объекты-контейнеры, которые могут содержать ссылки на другие объекты) и смотрит, доступны ли они из основного кода на Python. Если нет, то сборщик их удаляет. Если да — оставляет.

В отличие от счетчика ссылок, механизм сборки мусора не работает постоянно. Он запускается от случая к случаю на основе эвристик. GC разделяет объекты на три поколения. Каждый новый объект начинает свой путь с первого поколения. Если объект переживает раунд сборки мусора, он переходит к более старому поколению. В младших поколениях сборка происходит чаще, чем в старших. Эта практика является стандартной для такого рода сборщиков мусора и снижает частоту и объем очищаемых данных. Идея простая: чем дольше живет объект, тем с большей вероятностью он проживет еще. То есть новые объекты удаляются гораздо чаще, чем те, которые уже просуществовали достаточно долго.

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

Итоги

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

Что осталось за рамками статьи?

Мы не поговорили еще о многих вещах:

• Об оптимизации хранения небольших чисел.

• О том, что режим работы аллокатора в Python можно менять.

• О работе с большими файлами через Memory Mapping.

• И многом другом.

Оставлю эти вопросы заделом на следующие статьи :)

Автор: Кузьмин Алексей

Источник