Python Language
쓰레기 수거

비고

/* 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;

참조 횟수

대다수의 파이썬 메모리 관리는 참조 계산으로 처리됩니다.

객체가 참조 될 때마다 (예 : 변수에 할당 됨) 참조 카운트가 자동으로 증가합니다. 역 참조 될 때 (예 : 변수가 범위를 벗어나는 경우) 참조 카운트가 자동으로 감소합니다.

참조 횟수가 0이되면 개체가 즉시 파괴 되고 메모리가 즉시 해제됩니다. 따라서 대부분의 경우 가비지 컬렉터가 필요하지 않습니다.

>>> 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

참조 개념을 더 설명하기 위해 :

>>> 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

참조주기 가비지 수집기

가비지 수집기가 필요한 유일한 시간은 참조주기가있는 경우 입니다. 참조 사이클의 예제는 A가 B를 참조하고 B가 A를 참조하는 반면 A 또는 B는 다른 것을 참조하지 않는 프로그램입니다. A 또는 B는 프로그램의 어느 곳에서나 액세스 할 수 없으므로 안전하게 파괴 될 수 있습니다. 아직 그것들의 레퍼런스 카운트는 1이므로 레퍼런스 카운트 알고리즘만으로는 해제 될 수 없다.

>>> 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

기준주기는 임의로 길 수 있습니다. A가 B를 가리키면 C를 가리키고 ...가 A를 가리키는 Z를 가리키면 가비지 수집 단계까지 A부터 Z까지 수집되지 않습니다.

>>> 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

del 명령의 효과

del v 사용하여 범위에서 변수 이름을 제거하거나 del v[item] 또는 del[i:j] 사용하여 콜렉션에서 객체를 제거하거나 del v.name 사용하여 속성을 제거하거나 다른 참조를 제거하는 방법 객체 는 소멸자 호출이나 메모리 자체가 해제 되지 않도록 트리거 하지 않습니다 . 객체는 참조 카운트가 0에 도달 할 때만 소멸됩니다.

>>> 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

원시적 인 객체의 재사용

응용 프로그램을 최적화하는 데 도움이 될 수있는 흥미로운 점은 실제로는 프리미티브가 실제로 후드에서 다시 계산된다는 것입니다. 숫자를 살펴 보겠습니다. -5에서 256 사이의 모든 정수에 대해 파이썬은 항상 동일한 객체를 다시 사용합니다.

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

refcount가 증가함에 유의하자. 이것은 a 와 b 가 1 기본을 참조 할 때 동일한 기본 객체를 참조한다는 것을 의미한다. 그러나 더 큰 숫자의 경우 Python은 실제로 기본 객체를 재사용하지 않습니다.

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

999999999 대한 참조는 a 와 b 대입 할 때 변경되지 않으므로 둘 다 동일한 프리미티브가 할당 되더라도 서로 다른 두 개의 기본 객체를 참조한다고 추론 할 수 있습니다.

객체의 참조 개수보기

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

개체의 강제 할당 해제

파이썬 2와 3에서 refcount가 0이 아니더라도 객체의 할당을 해제 할 수 있습니다.

두 버전 모두 ctypes 모듈을 사용합니다.

경고 :이 작업을 수행하는 역 추적하지 않고 충돌로 불안정하고 쉬운 파이썬 환경을 떠날 것이다! 이 방법을 사용하면 보안 문제가 발생할 수도 있습니다 (매우 드뭅니다) 다시 참조하지 않을 것임을 확신하는 객체 만 할당을 해제합니다. 이제까지.

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

실행 후, 현재 할당 해제 된 객체에 대한 참조는 파이썬이 정의되지 않은 행동을 일으키거나 추적을하지 않고 충돌을 유발합니다. 가비지 컬렉터가 해당 객체를 제거하지 않은 이유는 아마도 ...

None 을 할당 해제하면 특별한 메시지가 나온다. Fatal Python error: deallocating None 충돌 전에 Fatal Python error: deallocating None .

가비지 수집 관리

메모리 정리가 수행 될 때 영향을주는 두 가지 접근 방법이 있습니다. 그들은 자동 프로세스가 수행되는 빈도와 다른 프로세스가 수동으로 정리를 트리거하는 데 영향을줍니다.

수집기가 실행되는 빈도에 영향을주는 수집 임계 값을 조정하여 가비지 수집기를 조작 할 수 있습니다. 파이썬은 세대 기반의 메모리 관리 시스템을 사용합니다. 새로운 객체는 새로운 세대에 저장됩니다 - generation0 각 컬렉션을 살아와, 객체는 이전 세대로 승격된다. 마지막 세대에 도달 한 후 - generation2을, 그들은 승진 더 이상 없습니다.

다음 스 니펫을 사용하여 임계 값을 변경할 수 있습니다.

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

첫 x 째 인수는 generation0 을 수집하는 임계 값을 나타냄니다. 할당 수가 할당 해제 횟수를 초과 할 때마다 가비지 수집기가 호출됩니다.

이전 세대는 각 공정에서 공정을 최적화하기 위해 세척되지 않습니다. 두 번째 및 세 번째 인수는 선택 사항 이며 이전 세대를 얼마나 자주 청소 할지를 제어합니다. generation0가 generation1 세정없이 100 시간 처리 한 경우 generation1 처리한다. generation1의 것들 generation2 건드리지 않고 10 회 세정 때 마찬가지로 generation2의 개체 만 처리한다.

임계 값을 수동으로 설정하는 것이 유익한 경우는 프로그램이 할당하지 않은 많은 작은 객체를 할당하여 가비지 수집기가 너무 자주 실행되는 경우입니다 (각 generation0_threshold 객체 할당). 컬렉터가 꽤 빠르다고하더라도 대량의 객체를 실행하면 성능 문제가 발생합니다. 어쨌든, 임계 값을 선택하기위한 모든 전략에 맞는 크기가 없으며 유스 케이스는 신뢰할 만합니다.

수동으로 콜렉션을 트리거하는 것은 다음 스니 j에서와 같이 수행 할 수 있습니다.

import gc
gc.collect()

가비지 콜렉션은 소비되거나 사용 가능한 메모리가 아니라 할당 및 할당 취소 횟수에 따라 자동으로 트리거됩니다. 따라서 큰 개체로 작업 할 때 자동 정리가 트리거되기 전에 메모리가 고갈 될 수 있습니다. 이것은 수동으로 가비지 콜렉터를 호출하는 좋은 유스 케이스를 만든다.

그것이 가능하더라도, 그것은 권장 된 연습이 아닙니다. 메모리 누수를 피하는 것이 가장 좋은 방법입니다. 어쨌든, 큰 프로젝트에서 메모리 누수를 감지하는 것은 좋은 일이 될 수 있으며 가비지 수집을 수동으로 트리거하는 것은 추가 디버깅까지 빠른 해결책으로 사용될 수 있습니다.

장기 실행 프로그램의 경우 가비지 콜렉션은 시간 기준 또는 이벤트 기준으로 트리거 될 수 있습니다. 첫 번째 예제는 고정 된 수의 요청 후에 콜렉션을 트리거하는 웹 서버입니다. 나중에, 특정 유형의 요청이 수신 될 때 가비지 콜렉션을 트리거하는 웹 서버.

가비지 수집이 정리 될 때까지 기다리지 마십시오.

가비지 수집을 정리한다고해서 가비지 수집주기가 정리 될 때까지 기다려야한다는 의미는 아닙니다.

특히 파일 핸들, 데이터베이스 연결 및 열린 네트워크 연결을 닫기 위해 가비지 수집을 기다리지 않아야합니다.

예 :

다음 코드에서는 f가 파일에 대한 마지막 참조 인 경우 파일이 다음 가비지 수집주기에 종료 될 것이라고 가정합니다.

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

좀 더 명확한 방법은 f.close() 를 호출하는 것입니다. 컨텍스트 관리자 라고도하는 with 문을 사용하면 훨씬 더 우아하게 처리 할 수 ​​있습니다.

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

with 문을 사용하면 열린 파일 아래에 코드를 들여 쓸 수 있습니다. 이렇게하면 파일이 얼마나 오랫동안 열려 있는지를 명확하고 쉽게 알 수 있습니다. while 블록에서 예외가 발생하더라도 항상 파일을 닫습니다.