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;

参照カウント

Pythonのメモリ管理の大部分は、参照カウントで処理されます。

オブジェクトが参照されるたびに（例えば、変数に代入される）、参照カウントは自動的に増加します。逆参照されると（例えば、変数が範囲外になる）、参照カウントは自動的に減少します。

参照カウントがゼロになると、オブジェクトは直ちに破棄され、メモリはただちに解放されます。したがって、ほとんどの場合、ガベージコレクタは必要ない。

>>> 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の間のすべての整数に対して、Pythonは常に同じオブジェクトを再利用します：

>>> 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のrefcountはaとbに代入するときに変更されないため、2つの異なる基本オブジェクトを参照することができます。ただし、両方に同じプリミティブが割り当てられています。

オブジェクトの参照数を表示する

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

強制的にオブジェクトの割り当てを解除する

Python 2と3の両方でrefcountが0でなくても、オブジェクトの割り当てを強制的に解除することができます。

どちらのバージョンもctypesモジュールを使用しています。

警告：これを行うと 、Python環境が不安定になり、トレースバックなしでクラッシュする傾向があります。この方法を使用すると、セキュリティ上の問題が発生する可能性があります（まったく考えられません）。再度参照しないことが確実なオブジェクトのみを割り当て解除してください。これまで

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

実行後、現在割り当て解除されているオブジェクトへの参照があると、Pythonは未定義の動作を引き起こすか、トレースバックなしでクラッシュします。ガベージコレクタがそのオブジェクトを削除しなかった理由はおそらくありました...

Noneを割り当て解除すると、特別なメッセージが表示されます。 Fatal Python error: deallocating None 。クラッシュする前にFatal Python error: deallocating Noneします。

ガベージコレクションの管理

メモリクリーンアップが実行されるときに影響を与える2つのアプローチがあります。それらは、自動プロセスが実行される頻度と手動でクリーンアップをトリガーする頻度に影響します。

ガベージコレクタは、コレクタが動作する頻度に影響を与えるコレクタしきい値を調整することによって操作できます。 Pythonは、世代別のメモリ管理システムを使用しています。新しいオブジェクトは最新の世代に保存されます - 世代 0および各生き残ったコレクションでは、オブジェクトは古い世代に昇格します。最後の世代に達した後- generation2を 、彼らが推進されなくなりました。

しきい値は次のスニペットを使用して変更できます。

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

最初の引数は、 世代交代のためのしきい値を表します。 割り振りの数が割り振り解除の数を1000を超えるたびに、ガベージコレクターが呼び出されます。

プロセスを最適化するために、古い世代は各実行時にはクリーニングされません。 2番目と3番目の引数はオプションで、古い世代のクリーニング頻度を制御します。 generation0が generation1を掃除せずに100回を加工した場合には、generation1が処理されます。同様に、generation2のオブジェクトはgeneration1におけるものがgeneration2に触れることなく10回洗浄した場合にのみ処理されます。

しきい値を手動で設定するのが有益なのは、プログラムが割り当てを解除せずに多数の小さなオブジェクトを割り当てて、ガベージコレクタが頻繁に実行される（各generation0_thresholdオブジェクトの割り当て）場合です。コレクターは非常に高速ですが、膨大な数のオブジェクトで動作する場合、パフォーマンスの問題が発生します。とにかく、しきい値を選択するためのすべての戦略に適合するサイズはなく、ユースケースは信頼できるものです。

手動でコレクションをトリガするには、次のスニペットのようにします。

import gc
gc.collect()

ガーベッジ・コレクションは、消費または使用可能なメモリーではなく、割り振りおよび割り振り解除の数に基づいて自動的にトリガーされます。したがって、大きなオブジェクトを使用して作業する場合、自動クリーンアップがトリガーされる前にメモリがなくなる可能性があります。これはガベージコレクタを手動で呼び出すための良いユースケースです。

それは可能ですが、それは奨励された練習ではありません。メモリリークを避けることが最善の選択肢です。とにかく、大きなプロジェクトではメモリリークを検出することができますが、ガベージコレクションを手動でトリガすることは、さらにデバッグするまでは迅速な解決策として使用できます。

長期実行プログラムの場合、ガベージコレクションは時間ベースまたはイベントベースでトリガーできます。最初の例は、一定数の要求の後に収集をトリガーするWebサーバーです。後では、特定のタイプの要求が受信されたときにガベージコレクションをトリガーするWebサーバー。

ガベージコレクションがクリーンアップするのを待つ必要はありません

ガベージコレクションがクリーンアップされるという事実は、ガベージコレクションサイクルがクリーンアップするのを待つべきではありません。

特に、ガベージコレクションがファイルハンドル、データベース接続、およびオープンネットワーク接続を閉じるのを待つべきではありません。

例えば：

次のコードでは、fがファイルへの最後の参照であった場合、ファイルが次のガベージコレクションサイクルで閉じられることを前提としています。

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

もっと明確な方法は、 f.close()を呼び出すこと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ブロックで例外が発生しても、常にファイルをクローズします。