Python Language
Skräp samling

Anmärkningar

/* Break reference cycles by clearing the containers involved.  This is
 * tricky business as the lists can be changing and we don't know which
 * objects may be freed.  It is possible I screwed something up here.
 */
static void
delete_garbage(PyGC_Head *collectable, PyGC_Head *old)

class A(object):
    def __init__(self, b=None):
        self.b = b
 
    def __del__(self):
        print("We're deleting an instance of A containing:", self.b)
     
class B(object):
    def __init__(self, a=None):
        self.a = a
 
    def __del__(self):
        print("We're deleting an instance of B containing:", self.a)

/* list of uncollectable objects */
static PyObject *garbage = NULL;

Referensräkning

Den stora majoriteten av Python-minneshanteringen hanteras med referensräkning.

Varje gång ett objekt refereras (t.ex. tilldelas en variabel) ökas dess referensantal automatiskt. När den avbryts (t.ex. variabeln går utanför räckvidden) minskas referensräkningen automatiskt.

När referensräkningen når noll förstörs objektet omedelbart och minnet frigörs omedelbart. I de flesta fall behövs således inte skräpfångaren.

>>> import gc; gc.disable()  # disable garbage collector
>>> class Track:
        def __init__(self):
            print("Initialized")
        def __del__(self):
            print("Destructed")
>>> def foo():
        Track()
        # destructed immediately since no longer has any references
        print("---")
        t = Track()
        # variable is referenced, so it's not destructed yet
        print("---")
        # variable is destructed when function exits
>>> foo()
Initialized
Destructed
---
Initialized
---
Destructed

För att ytterligare demonstrera referensbegreppet:

>>> def bar():
        return Track()
>>> t = bar()
Initialized
>>> another_t = t  # assign another reference
>>> print("...")
...
>>> t = None          # not destructed yet - another_t still refers to it
>>> another_t = None  # final reference gone, object is destructed
Destructed

Garbage Collector för referenscykler

Den enda gången du behöver sopor är om du har en referenscykel . Det enkla exemplet på en referenscykel är ett där A hänvisar till B och B hänvisar till A, medan inget annat hänvisar till varken A eller B. Varken A eller B är tillgängliga var som helst i programmet, så att de kan säkert förstöras, ändå är deras referensräkning 1 och så att de inte kan frigöras endast med referensräknarealgoritmen.

>>> import gc; gc.disable()  # disable garbage collector
>>> class Track:
        def __init__(self):
            print("Initialized")
        def __del__(self):
            print("Destructed")
>>> A = Track()
Initialized
>>> B = Track()
Initialized
>>> A.other = B
>>> B.other = A
>>> del A; del B  # objects are not destructed due to reference cycle
>>> gc.collect()  # trigger collection
Destructed
Destructed
4

En referenscykel kan vara godtycklig lång. Om A pekar på B pekar på C pekar på ... pekar på Z som pekar på A, kommer varken A till Z att samlas in förrän skräppassningsfasen:

>>> objs = [Track() for _ in range(10)]
Initialized
Initialized
Initialized
Initialized
Initialized
Initialized
Initialized
Initialized
Initialized
Initialized
>>> for i in range(len(objs)-1):
...     objs[i].other = objs[i + 1]
...
>>> objs[-1].other = objs[0]  # complete the cycle
>>> del objs                  # no one can refer to objs now - still not destructed
>>> gc.collect()
Destructed
Destructed
Destructed
Destructed
Destructed
Destructed
Destructed
Destructed
Destructed
Destructed
20

Effekter av del-kommandot

Ta bort ett variabelnamn från räckvidden med hjälp av del v , eller ta bort ett objekt från en samling med del v[item] eller del[i:j] , eller ta bort ett attribut med del v.name , eller på något annat sätt att ta bort referenser till ett objekt, inte utlöser några destructor samtal eller något minne frigörs i och av sig själv. Objekt förstörs endast när deras referensräkning når noll.

>>> import gc
>>> gc.disable()  # disable garbage collector
>>> class Track:
        def __init__(self):
            print("Initialized")
        def __del__(self):
            print("Destructed")
>>> def bar():
    return Track()
>>> t = bar()
Initialized
>>> another_t = t  # assign another reference
>>> print("...")
...
>>> del t          # not destructed yet - another_t still refers to it
>>> del another_t  # final reference gone, object is destructed
Destructed

Återanvändning av primitiva föremål

En intressant sak att notera som kan hjälpa till att optimera dina applikationer är att primitiva faktiskt också redovisas under huven. Låt oss titta på siffror; för alla heltal mellan -5 och 256 återanvänder Python alltid samma objekt:

>>> import sys
>>> sys.getrefcount(1)
797
>>> a = 1
>>> b = 1
>>> sys.getrefcount(1)
799

Observera att återbetalningen ökar, vilket innebär att a och b refererar till samma underliggande objekt när de hänvisar till det 1 primitiva. Men för större antal återanvänder Python faktiskt inte det underliggande objektet:

>>> a = 999999999
>>> sys.getrefcount(999999999)
3
>>> b = 999999999
>>> sys.getrefcount(999999999)
3

Eftersom återbetalningen för 999999999 inte ändras när vi tilldelar den till a och b vi dra slutsatsen att de hänvisar till två olika underliggande objekt, även om de båda tilldelas samma primitiva.

Visar ett objekts antal

>>> import sys
>>> a = object()
>>> sys.getrefcount(a)
2
>>> b = a
>>> sys.getrefcount(a)
3
>>> del b
>>> sys.getrefcount(a)
2

Fördelar kraftfullt med objekt

Du kan tvinga tilldelade objekt även om deras antal inte är 0 i både Python 2 och 3.

Båda versionerna använder ctypes att göra det.

VARNING: Om du gör detta kommer din Python-miljö att bli instabil och benägen att krascha utan spårning! Om du använder den här metoden kan det också medföra säkerhetsproblem (ganska osannolikt) Endast omlokalisera objekt som du är säker på att du aldrig kommer att referera igen. Någonsin.

import ctypes
deallocated = 12345
ctypes.pythonapi._Py_Dealloc(ctypes.py_object(deallocated))

import ctypes, sys
deallocated = 12345
(ctypes.c_char * sys.getsizeof(deallocated)).from_address(id(deallocated))[:4] = '\x00' * 4

Efter att ha kört kommer någon hänvisning till det nu omlokaliserade objektet att Python antingen producerar odefinierat beteende eller kraschar - utan en traceback. Det fanns antagligen en anledning till att skräpfångaren inte tog bort det föremålet ...

Om du deallocate None får du ett speciellt meddelande - Fatal Python error: deallocating None innan du kraschar.

Hantera sopor

Det finns två sätt att påverka när en minnesrensning utförs. De påverkar hur ofta den automatiska processen utförs och den andra utlöser manuellt en sanering.

Sopkollektorn kan manipuleras genom att ställa in uppsamlingströsklarna som påverkar frekvensen vid vilken kollektorn körs. Python använder ett generationsbaserat minnehanteringssystem. Nya objekt sparas i den nyaste generationen - generation0 och med varje överlevd samling befordras objekt till äldre generationer. Efter att ha nått den sista generationen - generation2 , marknadsförs de inte längre.

Trösklarna kan ändras med följande utdrag:

import gc
gc.set_threshold(1000, 100, 10) # Values are just for demonstration purpose

Det första argumentet representerar tröskeln för att samla generation0 . Varje gång antalet tilldelningar överstiger antalet fördelningar med 1000 kommer avfallssamlaren att ringas.

De äldre generationerna städas inte vid varje körning för att optimera processen. Det andra och tredje argumentet är valfria och styr hur ofta de äldre generationerna rengörs. Om generation0 bearbetades 100 gånger utan rengöring generation1 , kommer generation1 att behandlas. På liknande sätt kommer objekt i generation 2 att behandlas endast när de i generation 1 städades 10 gånger utan att beröra generation2 .

Ett exempel där manuellt ställer in trösklarna är fördelaktigt är när programmet allokerar en hel del små föremål utan att omlokalisera dem vilket leder till att skräpkollektorn körs för ofta (varje generation0_threshold- objektallokeringar). Trots att samlaren är ganska snabb, när den körs på ett stort antal föremål, utgör den en prestationsproblem. Hur som helst, det finns ingen storlek som passar alla strategier för att välja tröskelvärden och det är användningsfall beroende.

Manuell triggning av en samling kan göras som i följande utdrag:

import gc
gc.collect()

Skräpkollektionen utlöses automatiskt baserat på antalet tilldelningar och fördelningar, inte på det konsumerade eller tillgängliga minnet. Följaktligen, när du arbetar med stora objekt, kan minnet tappas innan den automatiska saneringen utlöses. Detta är ett bra användningsfall för att manuellt ringa sopor.

Trots att det är möjligt är det inte en uppmuntrad praxis. Att undvika minnesläckor är det bästa alternativet. Hur som helst, i stora projekt kan detektera minnesläckan vara en fast uppgift och manuellt utlösa en soporinsamling kan användas som en snabb lösning tills ytterligare felsökning.

För långvariga program kan skräpkollektionen utlösas tidvis eller på händelsebasis. Ett exempel för den första är en webbserver som utlöser en samling efter ett fast antal förfrågningar. För det senare, en webbserver som utlöser en sopsamling när en viss typ av begäran tas emot.

Vänta inte på att soporna samlas in

Det faktum att skräpuppsamlingen kommer att rensa betyder inte att du bör vänta på att skräpuppsamlingscykeln rensas upp.

I synnerhet bör du inte vänta på att skräpuppsamlingen stänger filhandtag, databasanslutningar och öppnar nätverksanslutningar.

till exempel:

I följande kod antar du att filen kommer att stängas vid nästa skräppassningscykel, om f var den sista referensen till filen.

>>> f = open("test.txt")
>>> del f

Ett mer tydligt sätt att rensa upp är att ringa f.close() . Du kan göra det ännu mer elegant, det vill säga genom att använda with uttalandet, även känt som context manager :

>>> with open("test.txt") as f:
...     pass
...     # do something with f
>>> #now the f object still exists, but it is closed

Den with uttalandet kan du indrag koden under öppna filen. Detta gör det tydligt och lättare att se hur länge en fil hålls öppen. Det stänger också alltid en fil, även om ett undantag tas upp i while blocket.