#!/usr/bin/env python

class Foo:
    def __init__(self):
        self._bar = {"test": self.test}
        print "construct"

    def test(self):
        print "test"

    def __del__(self):
        print "del"

f = Foo()
del f



A list of objects which the collector found to be unreachable but could not be freed (uncollectable objects). By default, this list contains only objects with __del__() methods. [1] Objects that have __del__() methods and are part of a reference cycle cause the entire reference cycle to be uncollectable, including objects not necessarily in the cycle but reachable only from it. Python doesn’t collect such cycles automatically because, in general, it isn’t possible for Python to guess a safe order in which to run the __del__() methods. If you know a safe order, you can force the issue by examining the garbage list, and explicitly breaking cycles due to your objects within the list. Note that these objects are kept alive even so by virtue of being in the garbage list, so they should be removed from garbage too. For example, after breaking cycles, do del gc.garbage[:] to empty the list. It’s generally better to avoid the issue by not creating cycles containing objects with __del__() methods, and garbage can be examined in that case to verify that no such cycles are being created.




PS: 这次事件也再一次显示“分层架构互不信任防雪崩策略”的重要性。这个出事的DB是一个slave,它的max_connection和max_user_connection是一样的,而且连接超时竟然是8小时……如果max_user_connection设小点,顶多是使用这个用户的系统挂掉,而不会是所有使用这个DB的系统都挂掉,把影响隔离起来。