Python Language
Вывоз мусора

замечания

/* Break reference cycles by clearing the containers involved.  This is
 * tricky business as the lists can be changing and we don't know which
 * objects may be freed.  It is possible I screwed something up here.
 */
static void
delete_garbage(PyGC_Head *collectable, PyGC_Head *old)

class A(object):
    def __init__(self, b=None):
        self.b = b
 
    def __del__(self):
        print("We're deleting an instance of A containing:", self.b)
     
class B(object):
    def __init__(self, a=None):
        self.a = a
 
    def __del__(self):
        print("We're deleting an instance of B containing:", self.a)

/* list of uncollectable objects */
static PyObject *garbage = NULL;

Подсчет ссылок

Подавляющее большинство управления памятью Python обрабатывается с подсчетом ссылок.

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

Когда счетчик ссылок достигает нуля, объект немедленно уничтожается и память немедленно освобождается. Таким образом, для большинства случаев сборщик мусора даже не нужен.

>>> import gc; gc.disable()  # disable garbage collector
>>> class Track:
        def __init__(self):
            print("Initialized")
        def __del__(self):
            print("Destructed")
>>> def foo():
        Track()
        # destructed immediately since no longer has any references
        print("---")
        t = Track()
        # variable is referenced, so it's not destructed yet
        print("---")
        # variable is destructed when function exits
>>> foo()
Initialized
Destructed
---
Initialized
---
Destructed

Чтобы еще раз продемонстрировать концепцию ссылок:

>>> def bar():
        return Track()
>>> t = bar()
Initialized
>>> another_t = t  # assign another reference
>>> print("...")
...
>>> t = None          # not destructed yet - another_t still refers to it
>>> another_t = None  # final reference gone, object is destructed
Destructed

Сборщик мусора для ссылочных циклов

Единственный раз, когда сборщик мусора нужен, если у вас есть эталонный цикл . Пример примера ссылочного цикла - это тот, в котором A относится к B и B, относится к A, тогда как ничто иное не относится ни к A, ни к B. Ни A, ни B не доступны из любой точки программы, поэтому их можно безопасно уничтожить, но их подсчеты ссылок равны 1 и поэтому они не могут быть освобождены только алгоритмом подсчета ссылок.

>>> import gc; gc.disable()  # disable garbage collector
>>> class Track:
        def __init__(self):
            print("Initialized")
        def __del__(self):
            print("Destructed")
>>> A = Track()
Initialized
>>> B = Track()
Initialized
>>> A.other = B
>>> B.other = A
>>> del A; del B  # objects are not destructed due to reference cycle
>>> gc.collect()  # trigger collection
Destructed
Destructed
4

Обратный цикл может быть произвольным долго. Если A указывает на B, то точка C указывает на ... указывает на Z, который указывает на A, тогда ни от A до Z не будет собрано, пока фаза сбора мусора:

>>> objs = [Track() for _ in range(10)]
Initialized
Initialized
Initialized
Initialized
Initialized
Initialized
Initialized
Initialized
Initialized
Initialized
>>> for i in range(len(objs)-1):
...     objs[i].other = objs[i + 1]
...
>>> objs[-1].other = objs[0]  # complete the cycle
>>> del objs                  # no one can refer to objs now - still not destructed
>>> gc.collect()
Destructed
Destructed
Destructed
Destructed
Destructed
Destructed
Destructed
Destructed
Destructed
Destructed
20

Эффекты команды del

Удаление имени переменной из области с помощью del v или удаление объекта из коллекции с помощью del v[item] или del[i:j] или удаление атрибута с помощью del v.name или любой другой способ удаления ссылок на объект, не вызывает вызовы деструктора или любую свободную память и сам по себе. Объекты уничтожаются только тогда, когда их количество ссылок достигает нуля.

>>> import gc
>>> gc.disable()  # disable garbage collector
>>> class Track:
        def __init__(self):
            print("Initialized")
        def __del__(self):
            print("Destructed")
>>> def bar():
    return Track()
>>> t = bar()
Initialized
>>> another_t = t  # assign another reference
>>> print("...")
...
>>> del t          # not destructed yet - another_t still refers to it
>>> del another_t  # final reference gone, object is destructed
Destructed

Повторное использование примитивных объектов

Интересно отметить, что может помочь оптимизировать ваши приложения, так это то, что примитивы фактически также пересчитываются под капот. Давайте посмотрим на цифры; для всех целых чисел от -5 до 256, Python всегда использует один и тот же объект:

>>> import sys
>>> sys.getrefcount(1)
797
>>> a = 1
>>> b = 1
>>> sys.getrefcount(1)
799

Обратите внимание, что пересчет увеличивается, что означает, что a и b ссылаются на один и тот же базовый объект, когда они ссылаются на 1 примитив. Однако для больших чисел Python фактически не использует повторно базовый объект:

>>> a = 999999999
>>> sys.getrefcount(999999999)
3
>>> b = 999999999
>>> sys.getrefcount(999999999)
3

Поскольку refcount для 999999999 не изменяется при назначении ему a и b мы можем заключить, что они относятся к двум различным базовым объектам, даже если им присваивается один и тот же примитив.

Просмотр пересчета объекта

>>> import sys
>>> a = object()
>>> sys.getrefcount(a)
2
>>> b = a
>>> sys.getrefcount(a)
3
>>> del b
>>> sys.getrefcount(a)
2

Сильно освобождение объектов

Вы можете принудительно освободить объекты, даже если их refcount не равен 0 в обоих Python 2 и 3.

Обе версии используют модуль ctypes для этого.

ПРЕДУПРЕЖДЕНИЕ: это сделает вашу среду Python нестабильной и подверженной сбою без следа! Использование этого метода также может привести к проблемам безопасности (весьма маловероятно). Только освободите объекты, которые, как вы уверены, никогда больше не будете ссылаться. Когда-либо.

import ctypes
deallocated = 12345
ctypes.pythonapi._Py_Dealloc(ctypes.py_object(deallocated))

import ctypes, sys
deallocated = 12345
(ctypes.c_char * sys.getsizeof(deallocated)).from_address(id(deallocated))[:4] = '\x00' * 4

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

Если вы освободите None , вы получите специальное сообщение - Fatal Python error: deallocating None перед сбоем.

Управление сборкой мусора

Существует два подхода к влиянию при выполнении очистки памяти. Они влияют на то, как часто выполняется автоматический процесс, а другой вручную запускает очистку.

Сборщик мусора можно манипулировать путем настройки порогов сбора, которые влияют на частоту, с которой работает сборщик. Python использует систему управления памятью на основе поколений. Новые объекты сохраняются в новейшем поколении - generation0 и с каждой сохранившейся коллекцией, объекты продвигаются в более старые поколения. Достигнув последнего поколения - generation2 , они больше не продвигаются.

Пороги могут быть изменены с помощью следующего фрагмента:

import gc
gc.set_threshold(1000, 100, 10) # Values are just for demonstration purpose

Первый аргумент представляет собой пороговое значение для сбора генерации 0 . Каждый раз, когда количество распределений превышает количество освобождений на 1000, будет вызываться сборщик мусора.

Предыдущие поколения не очищаются при каждом запуске, чтобы оптимизировать процесс. Второй и третий аргументы являются необязательными и контролируют частоту очистки старых поколений. Если генерация 0 обрабатывалась 100 раз без чистки поколения1 , то генерация 1 будет обрабатываться. Точно так же объекты в генерации 2 будут обрабатываться только тогда, когда те, что были в генерации 1, были очищены 10 раз, не касаясь поколения2 .

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

Вручную запуск коллекции можно выполнить в следующем фрагменте:

import gc
gc.collect()

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

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

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

Не ждите, пока сбор мусора будет очищен

Тот факт, что сбор мусора будет очищен, не означает, что вы должны дождаться очистки цикла сбора мусора.

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

например:

В следующем коде вы предполагаете, что файл будет закрыт в следующем цикле сбора мусора, если f была последней ссылкой на файл.

>>> f = open("test.txt")
>>> del f

Более явный способ очистки - это вызвать f.close() . Вы можете сделать это еще более изящным, то есть с помощью оператора with , также известного как менеджер контекста :

>>> with open("test.txt") as f:
...     pass
...     # do something with f
>>> #now the f object still exists, but it is closed

Оператор with позволяет отступывать код под открытым файлом. Это делает его явным и легче понять, как долго файл остается открытым. Он также всегда закрывает файл, даже если в блоке while создается исключение.