How Python GC deal with reference-cycles?
The supplemental garbage collection facility, however, is enabled by default and should be able to free that structure, if none of its components are reachable from the outside anymore and they do not have __del__() methods.
If they do, the garbage collector will not free them because it cannot determine a safe order to run these __del__() methods.
To extend on above answer a bit, the "reference counts" section of the docs explains the supplementary cycle detection nicely.
Since I find explaining things a good way to confirm I understand it, here are some examples... With these two classes:
1 2 3 4 5 6 7 | class WithDel( object ): def __del__( self ): print "deleting %s object at %s" % ( self .__class__.__name__, id ( self )) class NoDel( object ): pass |
Creating an object and losing the reference from a triggers the __del__ method, thanks to the ref-counting:
1 2 3 | >>> a = WithDel() >>> a = None # leaving the WithDel object with no references deleting WithDel object at 4299615184 |
If we make a reference loop between two objects with no __del__ method, all is still leak-free, this time thanks to the cycle detection. First, enable the garbage-collection debug output:
1 2 | >>> import gc >>> gc.set_debug(gc.DEBUG_COLLECTABLE | gc.DEBUG_UNCOLLECTABLE | gc.DEBUG_OBJECTS) |
Then make a reference loop between the two objects:
1 2 3 4 5 6 7 8 9 10 11 | >>> a = NoDel(); b = NoDel() >>> a.other = b; b.other = a # cyclical reference >>> a = None ; b = None # Leave only the reference-cycle >>> gc.collect() gc: collectable <NoDel 0x10046ed50 > gc: collectable <NoDel 0x10046ed90 > gc: collectable < dict 0x100376c20 > gc: collectable < dict 0x100376b00 > 4 >>> gc.garbage [] |
(the dict is from the objects internal __dict__ attribute)
All is fine, until even one of the objects in the cycle contains a __del__ method:
1 2 3 4 5 6 7 8 9 10 11 | >>> a = NoDel(); b = WithDel() >>> a.other = b; b.other = a >>> a = None ; b = None >>> gc.collect() gc: uncollectable <WithDel 0x10046edd0 > gc: uncollectable < dict 0x100376b00 > gc: uncollectable <NoDel 0x10046ed90 > gc: uncollectable < dict 0x100376c20 > 4 >>> gc.garbage [<__main__.WithDel object at 0x10046edd0 >] |
As mentioned, the loop can be broken with a weakref:
1 2 3 4 | >>> import weakref >>> a = NoDel(); b = WithDel() >>> a.other = weakref.ref(b) >>> b.other = a # could also be a weakref |
Then when the b reference to the WithDel object is lost, it gets deleted, despite the cycle:
1 2 3 4 | >>> b = None deleting WithDel object at 4299656848 >>> a.other <weakref at 0x10045b9f0 ; dead> |
Oh, objgraph would have helpfully indicated the problematic __del__ method like this
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 分享4款.NET开源、免费、实用的商城系统
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了