sys.getrefcount продолжение

Question

link text

я получил понятие счетчика ссылок

Так что, когда я выполняю «дель astrd», количество ссылок падает до нуля и astrd получает собранные дс?

Это является образец codes.These коды я разработал после моего вчерашнего вопроса: link text

one.py:

Защиту абв():

print "Hello" 
print "123" 
print '345' 

two.py:

import one 
#reload(one) 

#def defg(): 

one.abc() 

three.py:

import os,sys,gc 
from time import sleep 

import two 
#reload(two) 
#two.defg() 

sleep(20) 


directory = os.listdir('.') 

for filename in directory: 

     if filename[-3:] == 'pyc': 

       print '- ' + filename 

       print sys.getrefcount(filename) 

       file_name = os.path.splitext (filename)[0] 

       del file_name # remove the local reference 

       del sys.modules[os.path.splitext (filename)[0]] # removes import 

       gc.collect() # garbage collect 

       #del sys.modules[filename] 

       #del filename 

       #os.remove(filename) 

Что я сделал в three.py правильно или нет? Есть ли лишний шаг? Если да, то почему?

Пожалуйста, помогите мне в этом.

Answer 1

Он получает шанс, чтобы получить собранную информацию о следующем запуске коллекции GC.

См: http://docs.python.org/library/gc.html

Answer 2

Я считаю, что память автоматически освобождается в тот момент, RefCount достигает нуля. ГК не участвует.

GC python не является обязательным и используется только в том случае, если существуют недоступные объекты, имеющие ссылочные циклы. Фактически вы можете позвонить gc.disable(), если вы уверены, что ваша программа не создает ссылочные циклы.

Что касается первоначального вопроса:

• Когда вы del astrd, удалить связывание astrd из локального пространства имен ссылку на объект (ссылки независимо от astrd).
• Если это означает, что refcount равен нулю, память, используемая объектом, будет освобождена.
• So del не удаляет объекты, он откручивает ссылки. Удаление объектов - это побочный эффект, который возникает, если отключение ссылки приводит к тому, что refcount достигает нуля.

Обратите внимание, что вышесказанное относится только к CPython. Jython и IronPython использует механизм JVM/CLR GC и, по-моему, не использует refcounting вообще.

Удобный gc.get_objects возвращает список всех экземпляров объектов, отслеживаемых интерпретатором python. Пример:

 
import gc 

class test(object): 
    pass 

def number_of_test_instances(): 
    return len([obj for obj in gc.get_objects() if isinstance(obj, test)]) 

for i in range(100): 
    t = test() 

print "Created and abandoned 100 instances, there are now", \ 
    number_of_test_instances(), \ 
    "instances known to the python interpreter." 

# note that in normal operation, the GC would 
# detect the unreachable objects and start 
# collecting them right away 
gc.disable() 

for i in range(100): 
    t = test() 
    t.t = t 

print "Created and abandoned 100 instances with circular ref, there are now", \ 
    number_of_test_instances(), \ 
    "instances known to the python interpreter." 

gc.collect() 
print "After manually doing gc.collect(), there are now", \ 
    number_of_test_instances(), \ 
    "instances known to the python interpreter." 

Запуск этой программы дает:

 
Created and abandoned 100 instances, there are now 1 instances known to the python interpreter. 
Created and abandoned 100 instances with circular ref, there are now 100 instances known to the python interpreter. 
After manually doing gc.collect(), there are now 1 instances known to the python interpreter. 

Answer 3

Не могли бы вы дать некоторый фон относительно того, что вы делаете? Существует редко какая-либо причина для явного использования del для переменных, отличных от очистки пространства имен, которое вы не хотите раскрывать. Я не знаю, почему вы звоните del file_name или запускаете gc.collect(). (del sys.modules[filename] - это отличное использование del)

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

Для объектов, которые должны быть окончательно оформлены (например, открытый файл или удерживаемый замок), вы не должны полагаться на сборщик мусора в любом случае - это не гарантирует немедленного сбора таких объектов. Это происходит в стандартной реализации Cython C, но не в Jython или IronPython, и это не гарантируется. Вместо этого вы должны явно очистить такие объекты, вызвав close или используя новую конструкцию with.

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

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