Python 3.4 のオブジェクト開放処理

Python Advent Calendar 2013 の六日目です。Python3.4 で導入された PEP 442 -- Safe object finalization の解説を簡単に。

Pythonのメモリ解放処理

Pythonでは、処理中に使われなくなったオブジェクトを検出し、自動的に開放するようになっている。他のオブジェクトから全く参照されておらず、Python インタープリタからアクセスできなくなってしまっているオブジェクトは、不要なオブジェクトとして削除される。

例えば、

>>> class Spam:
...     pass
...
>>>
>>> obj = Spam()
>>> obj = None

では、最初に作成した Spam オブジェクトは、obj という名前で参照できるが、次の行では obj = None と別のオブジェクトを指すように変更されると、もうPython インタープリタから参照できなくなる。このため、Pythonはこの Spam オブジェクトは不要となったと判断し、削除する。

循環参照

他のオブジェクトからの参照があっても、孤立したグループ内でのみ参照されているなら、そのグループのオブジェクトは開放される。

>>> class Spam:
...     pass
...
>>>
>>> obj1 = Spam()
>>> obj2 = Spam()
>>> obj3 = Spam()
>>> obj1.obj2 = obj2
>>> obj2.obj3 = obj3
>>> obj3.obj1 = obj1
>>> obj1 = obj2 = obj3 = None

この例では、obj1、 obj2、obj3 オブジェクトは、それぞれお互いへの参照をメンバとして持っている。このように、複数のオブジェクトがループ状にお互いを参照することを、*循環参照* と呼ぶ。

この循環参照は、最後の obj1 = obj2 = obj3 = None で変数 obj1, obj2, obj3 が別のオブジェクトを参照するように変更されたので、どのオブジェクトもPython インタープリタからはアクセスできなくなってしまった。Pythonは、このようにお互い同士では参照していても、外部からはアクセスできなくなってしまったオブジェクトも不要と判断し、開放する。

しかし、これまでのPythonでは、この循環参照の開放には制限があった。

>>> class Spam:
...     def __del__(self):
...         print('deleting...')
...         global dont_kill_me
...         dont_kill_me = self

このように、特殊メソッド __del__() を持つオブジェクトが循環参照を構成する場合、開放の対象外となっていた。これは開放のときに __del__() メソッドを呼び出すと、その呼出の順番によってはすでに解放済みのオブジェクトを参照してしまったり、また自分自身を再び外部から参照可能な状態にしたりしてしまう可能性があったためだ。

上の例では、__del__() でグローバル変数 dont_kill_me にオブジェクトを保存しているので、Spam クラスのインスタンスは削除されることはない。

PEP 442

Python 3.4以降では、PEP 442 でこの点が改善され、__del__() を持つオブジェクトが循環参照に含まれていても、開放されるようになった。従来のメモリ解放処理に比べて、いくぶんか処理量が増加しているが、現在ではPythonにガベージコレクションが実装された西暦2000年頃に比べてコンピュータのハードウェア環境は大きく進歩しており、この程度はあまり問題とはならないだろう。

PEP 442での変更で、以下の点は気にしておいたほうが良いだろう。

循環参照の一部に、先ほどの

>>> class Spam:
...     def __del__(self):
...         print('deleting...')
...         global dont_kill_me
...         dont_kill_me = self

のようなオブジェクトが含まれている場合、オブジェクトは参照可能な状態に戻るので開放はされない。しかし、この場合開放はされなくても、循環参照を構成する、全てのオブジェクトの __del__() メソッドが呼び出される。つまり、Python3.4以降では、__del__() が呼び出されたとしても、必ずオブジェクトが開放されるとは限らなくなった。

上の例で、すでに __del__() が呼び出されてしまったオブジェクトが再び参照不能になったときでも、もう __del__() メソッドは呼び出されない。__del__() が呼び出されるのは、ただ一度だけである。

(注: 例外として、 https://mail.python.org/pipermail/python-dev/2013-June/126834.html などのケースで複数回呼び出されることもありうるが、現実問題としてあまり考慮する必要はないだろう)

開放されない循環参照もある

PEP 442 で、すべての循環参照が開放されるようになったわけではない。循環参照に含まれるオブジェクトがPythonのクラスから作成したインスタンスだけであれば開放されるが、C言語で実装された型のオブジェクトが含まれる場合、従来と同じように開放されないケースもある。

油断は禁物

Python2で gc モジュールが実装されて以来、__del__() メソッドは実装するメリットよりもデメリットのほうが大きいと考えられ、できるだけ使わないようにするのが一般的だった。お陰で with ステートメントなどの機能が大きく進化することになったが、ここで再び __del__() のデメリットが少なくなったことで、__del__() にいろいろな処理を詰め込みたいと思う人もいるかもしれない。

しかし、__del__() のデメリットは、循環参照時に開放されないことだけではない。__del__() が呼び出されるタイミングは予測できないし、全く呼び出されないかもしれない。先程の例のように、呼び出されたとしても本当に開放されたとは限らないし、マルチスレッドアプリケーションでは、どのスレッドで呼び出されるかも予測できない。__del__() の活用には、いろいろと難しい点が残っている。

したがって、Pythonプログラミングのガイドラインとしては、「できるだけ __del__() に依存しない」というのは、依然として有効だと考える。くれぐれもC++のデストラクタと同じような使い方が出来ると思ってはならないのである。