解释器环境中的python垃圾回收和_下划线 [英] python garbage collection and _ underscore in interpreter environment

查看:82
本文介绍了解释器环境中的python垃圾回收和_下划线的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

如果在解释器环境中定义了一个类:

If a class is defined in interpreter environment:

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

然后实例化而没有名称:

Then instantiated without names:

>>> C(1)
>>> C(2)
>>> 

然后我们可以使用下划线_来引用C(2),所以这是我的问题:

Then we can use underscore _ to refer to C(2), so here is my question:

  • 由于下划线'_'指的是C(2),因此我们可以说参考 C(2)的计数器是还是1 ?因此python gc将不免费 C(2)占用的内存?
  • 据我所知,在执行这些C(2)之后,没有名称将引用C(1),所以我可以说一旦执行 C(2),即C(1)' s 内存会被python gc 释放吗?
  • Since the underscore '_' refer to C(2), can we say the reference counter for C(2) is still 1? So the python gc will not free the memory taken by C(2)?
  • As far as I know, after these C(2) is executed, no names will refer to C(1), so can I say as soon as C(2) is executed, C(1)'s memory will be freed by python gc?

这些实际上是4个问题,一个加粗字体变成一个.

These are actually 4 questions, one bold font to one.

gc:垃圾回收的缩写

gc: short for garbage collection

编辑

让我通过直接对代码进行注释来使我的第一个问题更加清楚.

Let me make my first question more clear by commenting directly into the codes.

>>> C(1) # Press Enter Key and run
>>> 
>>> At Here, what is the exact reference count for the previous anonymous object "C(1)"? 
>>> And how to prove?
>>> 
>>> C(2) # Press Enter Key and run
>>> 
>>> At Here, what is the exact reference count for the previous anonymous object "C(1)"?
>>> And how to prove?

推荐答案

C(1)C(2),因为解释器的最后一行位于代码的中间或上方时,其行为有所不同.

C(1) or C(2) as last line of the interpreter behaves differently when they are in the middle or to the up of the code.

如果C(1)在最后一行,则python解释器会将其存储为<__main__.C object at 0x00000000********>,因此实际上它会附加一个名称.如果选中number_of_instances(C),结果将为1.

If C(1) is at the last line, python interpreter will store it as <__main__.C object at 0x00000000********>, so actually it will have a name attached to it. If you check number_of_instances(C), the result will be 1.

如果C(1)不在最后一行,则此临时匿名对象将被破坏并消失.

If C(1) is not at the last line, this temporary anonymous object is just destroyed and disappeared.

检查以下测试代码.

您可以使用number_of_instances来显示内存中是否存在任何C对象.

You can use number_of_instances to show if there is any C object resides in memory.

import gc

def name_of_instances(cls):
    return [obj for obj in gc.get_objects() if isinstance(obj, cls)]

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

1.匿名对象不在最后一行

1.anonymous object not at last line

In [12]: C(1)
    ...: C(2)
    ...: print(number_of_instances(C))
    ...:
0

In [13]:

2.最后一行的匿名对象

2.anonymous object at last line

In [6]: C(1)
Out[6]: <__main__.C at 0x6a97ba8>

In [7]: print(number_of_instances(C))
   ...: print(name_of_instances(C))
   ...:
1
[<__main__.C object at 0x0000000006A97BA8>]

In [8]: C(2)
Out[8]: <__main__.C at 0x6a9b518>

In [9]: print(number_of_instances(C))
   ...: print(name_of_instances(C))
   ...:
2
[<__main__.C object at 0x0000000006A97BA8>, <__main__.C object at 0x0000000006A9B518>]

3.下划线_会记住C(3)如果它是最后一行

3.underscore _ will remember C(3) if it is the last line

In [13]: C(3)
Out[13]: <__main__.C at 0x6aa06d8>

In [14]: type(_)
Out[14]: __main__.C

但是在这种情况下,引用计数器从不对来自_的引用进行计数,仅对您未观察到的<__main__.C object at 0x0000000006AA06D8>进行计数.

But in this case, the reference counter never counts reference from _, it only counts <__main__.C object at 0x0000000006AA06D8> which you didn't observe.

在这里猜测:_不在gc.garbage列表中.如果依次运行C(1)print(number_of_instances(C)),则number_of_instances不会签入_,后者可能存储了先前的C(1)

A guess here: _ is not in gc.garbage list. If you run C(1), print(number_of_instances(C)) successively, number_of_instances will not check into _ which may be storing the previous C(1)

请参阅: sys.getrefcount延续

这篇关于解释器环境中的python垃圾回收和_下划线的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆