В этом посте я писал почему работа с файлами и другими объектами, требующими гарантированного закрытия должна должна производиться через with. Однако кроме минуса в виде добавления в код лишнего уровеня вложенности with еще и решает только часть проблемы — если код обработки файла не локален (нужно возвращать дескриптор в вызывающий код или хранить неопределенное время) with не может помочь. И собственно никто вообще не может помочь — суровая реальность состоит в том, что python не гарантирует вызов деструктора объекта. Т.е. если вы работаете на CPython, и не создаете циклических ссылок, то за крайне редкими исключениями деструктор будет вызываться вовремя. Но если вы используете ironpython/jython/pypy то ситуация становится совсем печальна.

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

    // C++
    {
        // open file
        std::fstream fs(fname, std::ios_base::out);
        process_file(fs);
    } // file is closed before we get beyong this line, no matter what happened

Гарантированный вызов деструктора — великое программистское благо, позволяющее не заботится о освобождении некоторых ресурсов, не загромождать код всякими with/using/try-finally & Co, и даже для объектов в куче есть всякие unique_ptr. Но все это хорошо работает только в том случае, если объект имел некую локальную область жизни(впрочем unique_ptr/shared_ptr могут и больше). Если же объект выделяется из кучи в одном месте, а освобождается в другом то можно забыть сделать ему delete — получаем утечку памяти. Не смотря на множество способов значительно сократить вероятность такого исхода (например арены) полностью исключить его нельзя.

В качестве решения этой проблемы в современных языках используются сборщики мусора. Периодически они проходятся по памяти, и тем или иным способом удаляют неиспользуемые объекты. Все бы хорошо, но у сборщиков мусора возникают небольшие или большие проблемы с вызовами деструкторов у объектов. Во-первых все сборщики мусора бессильны перед циклическими ссылками. Если объект a ссылается на b, а b ссылается на a, то не понятно в каком порядке вызывать деструкторы. Сначала у a или сначала у b. Если сначала у a, то при вызове деструктора b его ссылка на a будет не валидна и наоборот. Отсутствие информации о смысле взаимосвязей между объектами не дает сборщику мусора вызвать деструкторы в корректном порядке. Копирующие сборщики мусора пошли еще дальше. Они вообще ничего не вызывают, оставляя программиста один на один с этой проблемой и гордо подписываясь «современный сборщик мусора».

Проблема, очевидно, состоит в том что оперативная память это не единственный ресурс требующий освобождения. Еще, как минимум, есть объекты OS, мютексы, транзакции БД, и много много другого. Часть из таких объектов будет через время прикрыта другим кодом (например транзакции БД — но в любом случае они будут создавать лишнюю нагрузку на базу все это время), но объекты OS останутся с процессом до его смерти. А ведь бОльшая часть таких объектов имею локальную область видимости и при гарантированном вызове деструктор был бы идеальным местом для их освобождения. Таким образом переходя от С++ к языкам со сборкой мусора но с недетерменированным вызовом деструкторов мы выигрываем в коде освобождения памяти, но проигрываем на других объектах. Теперь вместо delete «где-то там» вы должны написать dispose/using/with/try-finally прямо тут на каждый объект. Впрочем если файл, например, является не локальным, то и это не поможет. Для примера можно открыть Экслера и глянуть как в яве правильно работать с файлами. Страница ужасного кода ради одного маленького файлика. Не уверен, что такая сборка мусора того стоила.

Итак посмотрим как себя ведут с деструкторами разные варианты питона. В качестве примера возьмем вот такую программу:

Без подсветки синтаксиса

import gc
import sys

class DestTest(object):
    def __init__(self, val):
        self.val = val

    def __del__(self):
        sys.stdout.write(str(self) + '.__del__()n')

    def __str__(self):
        return "DestTest({})".format(self.val)

    def __repr__(self):
        return "DestTest({})".format(self.val)

def simple_var():
    d = DestTest("simple var")

def mdeleted_var():
    d = DestTest("manyally deleted var")
    del d

def simple_list():
    a = [DestTest("simple list")]

def internal_exc():
    try:
        d = DestTest("exception_func")
        raise IndexError()
    except:
        pass

def exception_func():
    d = DestTest("exception_func")
    raise IndexError()

def self_ref_list():
    a = [DestTest("self-ref list")]
    a.append(a)

def cycle_refs():
    d1 = DestTest("cycle_ref_obj1")
    d2 = DestTest("cycle_ref_obj2")
    d3 = DestTest("free_obj")

    d1.ref = d2
    d2.ref = d1
    d2.ref2 = d3

simple_var()
sys.stdout.write("after simple varn")
sys.stdout.write("n")

simple_list()
sys.stdout.write("after simple listn")
sys.stdout.write("n")

mdeleted_var()
sys.stdout.write("after manually deleted varn")
sys.stdout.write("n")

self_ref_list()
sys.stdout.write("after self ref listn")
gc.collect()
sys.stdout.write("after gc.collect()n")
sys.stdout.write("n")

internal_exc()
sys.stdout.write("after internal excn")

try:
    exception_func()
except Exception as x:
    pass
sys.stdout.write("after exception funcn")
gc.collect()
sys.stdout.write("after gc.collect()n")
try:
    sys.exc_clear()
except AttributeError:
    pass
else:
    sys.stdout.write("after sys.exc_clear()n")
sys.stdout.write("n")

cycle_refs()
sys.stdout.write("after cycle refsn")
gc.collect()
sys.stdout.write("after gc.collect()n")
sys.stdout.write("n")

d = DestTest("module var")

import gc
import sys

class DestTest(object):
    def __init__(self, val):
        self.val = val

    def __del__(self):
        sys.stdout.write(str(self) + '.__del__()n')

    def __str__(self):
        return "DestTest({})".format(self.val)

    def __repr__(self):
        return "DestTest({})".format(self.val)

def simple_var():
    d = DestTest("simple var")

def mdeleted_var():
    d = DestTest("manyally deleted var")
    del d

def simple_list():
    a = [DestTest("simple list")]

def internal_exc():
    try:
        d = DestTest("exception_func")
        raise IndexError()
    except:
        pass

def exception_func():
    d = DestTest("exception_func")
    raise IndexError()

def self_ref_list():
    a = [DestTest("self-ref list")]
    a.append(a)

def cycle_refs():
    d1 = DestTest("cycle_ref_obj1")
    d2 = DestTest("cycle_ref_obj2")
    d3 = DestTest("free_obj")

    d1.ref = d2
    d2.ref = d1
    d2.ref2 = d3

simple_var()
sys.stdout.write("after simple varn")
sys.stdout.write("n")

simple_list()
sys.stdout.write("after simple listn")
sys.stdout.write("n")

mdeleted_var()
sys.stdout.write("after manually deleted varn")
sys.stdout.write("n")

self_ref_list()
sys.stdout.write("after self ref listn")
gc.collect()
sys.stdout.write("after gc.collect()n")
sys.stdout.write("n")

internal_exc()
sys.stdout.write("after internal excn")

try:
    exception_func()
except Exception as x:
    pass
sys.stdout.write("after exception funcn")
gc.collect()
sys.stdout.write("after gc.collect()n")
try:
    sys.exc_clear()
except AttributeError:
    pass
else:
    sys.stdout.write("after sys.exc_clear()n")
sys.stdout.write("n")

cycle_refs()
sys.stdout.write("after cycle refsn")
gc.collect()
sys.stdout.write("after gc.collect()n")
sys.stdout.write("n")

d = DestTest("module var")

В идеальном мире вызов деструктора у объектов класса DestTest во всех этих функциях должен происходить до выхода из соответствующей функции. Итак что получается:

python2.7

    DestTest(simple var).__del__()
    after simple var

    DestTest(simple list).__del__()
    after simple list

    DestTest(manyally deleted var).__del__()
    after manually deleted var

    after self ref list
    DestTest(self-ref list).__del__()
    after gc.collect()

    after exception func
    after gc.collect()
    DestTest(exception_func).__del__()
    after sys.exc_clear()

    after cycle refs
    after gc.collect()

    Exception AttributeError: "'NoneType' object has no attribute 'stdout'" in 
     ignored

Более-менее. Деструктор у циклических ссылок не был вызван, как и ожидалось. Для уничтожения объектов, связанных с исключением, дошедшем до уровня модуля приходится вызывать sys.clear_exc(), в остальных случаях с исключениями все ок. Интересно, что питон освободил sys.stdout раньше, чем переменную d, в итоге чего ее деструктор отработал не корректно (впрочем это поведение не всегда повторяется).

python3.3

    DestTest(simple var).__del__()
    after simple var

    DestTest(simple list).__del__()
    after simple list

    DestTest(manyally deleted var).__del__()
    after manually deleted var

    after self ref list
    DestTest(self-ref list).__del__()
    after gc.collect()

    DestTest(exception_func).__del__()
    after exception func
    after gc.collect()

    after cycle refs
    after gc.collect()

    Exception AttributeError: "'NoneType' object has no attribute 'stdout'" in 
     ignore

Почти то-же самое, что и 2.7, только sys.exc_clear() больше не нужно.

ironpython2.7

    after simple var

    after simple list

    after manually deleted var

    after self ref list
    DestTest(self-ref list).__del__()
    DestTest(manyally deleted var).__del__()
    DestTest(simple list).__del__()
    DestTest(simple var).__del__()
    after gc.collect()

    after exception func
    DestTest(exception_func).__del__()
    after gc.collect()
    after sys.exc_clear()

    after cycle refs
    DestTest(free_obj).__del__()
    DestTest(cycle_ref_obj2).__del__()
    DestTest(cycle_ref_obj1).__del__()
    after gc.collect()

    DestTest(module var).__del__()

Удаляет все, но только при сборке мусора, до те
х пор все объекты живут где-то в памяти.

И — встречаем победителя. Сама лаконичность или мир всем вашим деструкторам от нашей Java и копирующего сборщика мусора: jython2.7a2 — Java HotSpot(TM) Client VM (Oracle Corporation) on java1.7.0_07

    after simple var

    after simple list

    after manually deleted var

    after self ref list
    after gc.collect()

    after exception func
    after gc.collect()
    after sys.exc_clear()

    after cycle refs
    after gc.collect()

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

А вывод все тот-же. По возможности — используйте with. По невозможности — попробуйте поправить код, так что-бы можно было использовать with. Иначе — аккуратно вызывайте деструкторы руками

P.S. Как я люблю, когда мне предлагают делать какую-то рутинную работу в коде «аккуратно».

Ссылки:
          koder-ua.blogspot.com/2012/10/python-with.html
          en.wikipedia.org/wiki/Region-based_memory_management

Исходники этого и других постов со скриптами лежат тут — github.com/koder-ua. При использовании их, пожалуйста, ссылайтесь на koder-ua.blogspot.com.

Автор: konstantin danilov