Python garbage collection mechanism: GC Module

In Python, the object reference count is used to solve the memory leak problem, and automatic garbage collection is implemented based on the reference count.

Because Python has an automatic garbage collection feature, many beginners mistakenly think that it is unnecessary to be harassed by memory leaks. But if you look closely at the description of the Python document to the __del__ () function, you know there is a cloud in this good day. Here's a little excerpt from the document below:

Some common situations that could prevent the reference count of an object from going to zero include:circular references B Etween objects (e.g., a doubly-linked list or a tree data structure with parent and child pointers); A reference to the object on the stack frame of a function this caught an exception (the traceback stored in Sys.exc_trace Back keeps the stack frame alive); Or a reference to the object on the stack frame, raised an unhandled exception in interactive mode (the Traceback stor Ed in sys.last_traceback keeps the stack frame alive).

　　Visible, have a between objects of the __del__ () function . Circular References is the main culprit that caused the memory leak. However, circular references between objects without the __del__ () function can be reclaimed by the garbage collector.

How do I know if an object is leaking out of memory?

You can view the details of objects that cannot be reclaimed by using the Python extension GC.

Cases

Example 1: A memory leak is not present

Import gcimport sysclassCgcleak (Object): def __init__ (self): Self._text='#'*Tendef __del__ (self): Passdef make_circle_ref (): _gcleak=Cgcleak ()Print"_gcleak ref count0:%d"%(Sys.getrefcount (_gcleak)) del _gcleakTry: Print"_gcleak ref Count1:%d"%(Sys.getrefcount (_gcleak)) except Unboundlocalerror: # local variable XXX reference not defined before print"_gcleak is invalid!"def test_gcleak (): gc.enable () #设置垃圾回收器调试标志Gc.set_debug (GC. Debug_collectable| Gc. debug_uncollectable | Gc. debug_instances |GC. debug_objects) Print"begin leak Test ..."make_circle_ref () print"\nbegin Collect ..."_unreachable=gc.collect () print"Unreachable Object num:%d"%(_unreachable) Print"Garbage Object num:%d"%(Len (gc.garbage)) #gc. Garbage is a list object that is the object that the garbage collector finds unreachable (that is, garbage), but cannot be released (not recyclable) , the object in Gc.garbage is usually the object in the Reference object. Because Python does not know in what order to invoke the object's __del__ function, causing the object to always survive in gc.garbage, resulting in a memory leak if __name__ = = "__main__": Test_gcleak (). If you know a security order, then you can break the citation refresh and then execute del gc.garbage[:] To empty the list of junk objects

Results

Begin leak Test..._gcleak ref count0:2         #对象_gcleak的引用计数为2_gcleak is invalid!          #因为执行了del函数, _gcleak becomes unreachable object begin collect             ... #开始垃圾回收Unreachable object num:0      #本次垃圾回收发现的不可达的对象个数为0Garbage Object num:0          # The total number of garbage objects in the interpreter is 0

The conclusion is that the reference count of the object _gcleak is correct, and there is no memory leak.

Example 2: A memory leak to your own circular reference

ImportGCImportSYSclassCgcleak (object):def __init__(self): Self._text='#'* 10def __del__(self):Passdefmake_circle_ref (): _gcleak=cgcleak () _gcleak._self=_gcleak #自己循环引用自己Print "_gcleak ref count0:%d"%(Sys.getrefcount (_gcleak))del_gcleakTry:        Print "_gcleak ref Count1:%d"%(Sys.getrefcount (_gcleak))exceptUnboundlocalerror:Print "_gcleak is invalid!"deftest_gcleak (): Gc.enable () Gc.set_debug (GC. Debug_collectable| Gc. debug_uncollectable | Gc. debug_instances |GC. debug_objects)Print "begin leak Test ..."make_circle_ref ()Print "\nbegin Collect ..."_unreachable=Gc.collect ()Print "Unreachable Object num:%d"%(_unreachable)Print "Garbage Object num:%d"%(Len (gc.garbage))if __name__=="__main__": Test_gcleak ()

Results

Begin leak Test...gc:uncollectable <cgcleak 00000000026366a0>_gcleak ref Count0:3_gcleak is Invalid!gc:uncollect Able <dict 0000000002667bd8>begin collect...unreachable object num:2       #本次回收不可达的对象个数为2Garbage Object Num:1           #整个解释器中垃圾个数为1

Example 3: A circular reference between multiple objects causes a memory leak

ImportGCImportSYSclassCgcleaka (object):def __init__(self): Self._text='$'* 10def __del__(self):Passclasscgcleakb (object):def __init__(self): Self._text='$'* 10def __del__(self):Passdefmake_circle_ref (): _a=Cgcleaka () _b=cgcleakb () _a.s=_b _B.D=_aPrint "ref count0:a=%d b=%d"%(Sys.getrefcount (_a), Sys.getrefcount (_b))del_adel_bTry:        Print "ref count1:a%d"%(Sys.getrefcount (_a))exceptUnboundlocalerror:Print "_a is invalid!"deftest_gcleak (): Gc.enable () Gc.set_debug (GC. Debug_collectable| Gc. debug_uncollectable | Gc. debug_instances |GC. debug_objects)Print "begin leak Test ..."make_circle_ref ()Print "\nbegin Collect ..."_unreachable=Gc.collect ()Print "Unreachable Object num:%d"%(_unreachable)Print "Garbage Object num:%d"%(Len (gc.garbage))if __name__=="__main__": Test_gcleak ()

Results

Begin leak Test...ref count0:a=3 b=3_a is invalid!begin collect...unreachable object Num:4garbage Object Num:2gc:uncollec Table <cgcleaka 00000000022766d8>gc:uncollectable <cgcleakb 0000000002276710>gc:uncollectable <dict 00000000022a7e18>gc:uncollectable <dict 00000000022df3c8>

Conclusion

Python's GC has strong features, such as setting Gc.set_debug (GC). Debug_leak) can be checked for memory leaks caused by circular references. If a memory leak check is made at development time, and when it is released to ensure that no memory leaks are available, you can increase the operational efficiency by extending the garbage collection interval for Python, or even proactively shutting down the garbage collection mechanism.

Knowledge to be studied in depth: monitoring reference counts in Python

Reference: Python memory leaks and usage analysis of GC modules

Python garbage collection mechanism: GC Module