Python finalize 清理回调：已经删掉对象，为什么绑定方法还把它留住了
为对象注册销毁时的清理动作，最顺手的写法是 weakref.finalize(obj, obj.close)。但删掉 obj 后，close 迟迟没有执行。终结器虽然通过弱引用观察目标，它保存的回调却是绑定方法；绑定方法又持有目标实例，结果清理安排本身把准备释放的对象留住了。
这种错误不能靠多调用几次垃圾回收修复。只要仍有有效的强引用链，对象就不应被回收。应检查回调、位置参数、关键字参数和闭包是否间接指向目标，而不是只看 finalize 的第一个参数使用了弱引用机制。
可直接运行的对照实验
下面只记录字符串事件，不打开任何真实资源。保存为 demo.py，在 CPython 3.12 运行。坏例子保留终结器句柄，随后用 detach 主动拆除错误注册；好例子则让独立函数只接收资源名字，避免在实验结束时留下待执行动作。
AI概念插图：清理装置的绳索回连目标时会把它留住，独立资源信息才能解除这种牵连。图片不是运行截图，也不表示实测性能。
import gc
import weakref
events = []
class Resource:
def __init__(self, name):
self.name = name
def close(self):
events.append(self.name)
bad = Resource("bad")
watch_bad = weakref.ref(bad)
bad_finalizer = weakref.finalize(bad, bad.close)
del bad
gc.collect()
assert watch_bad() is not None
assert events == []
print("bad still alive:", watch_bad() is not None)
released = bad_finalizer.detach()
assert released is not None
assert not bad_finalizer.alive
del released
gc.collect()
assert watch_bad() is None
print("after detach:", watch_bad() is None)
def cleanup(name):
events.append(name)
good = Resource("good")
watch_good = weakref.ref(good)
good_finalizer = weakref.finalize(good, cleanup, good.name)
del good
gc.collect()
assert watch_good() is None
assert not good_finalizer.alive
assert events == ["good"]
good_finalizer()
assert events == ["good"]
print("cleanup events:", events)绑定方法把谁放进了引用链
第一行 bad still alive: True 表明删除局部变量后目标仍存在，事件列表也为空。obj.close 并非只有函数代码，它还记住方法的接收者。终结器保存这个方法，就拥有了一条回到 obj 的强引用路径；弱引用不会自动把回调里的这种持有关系改弱。
detach 返回包含目标、回调和参数的信息，同时让终结器不再存活。代码立即丢弃返回结果，再调用 gc.collect，弱引用才变为 None。如果为了调试把 detach 的返回元组长期存进列表，元组又会继续持有对象，容易让调查结果看起来像拆除没有生效。
把清理需要的数据单独保存
好例子使用 cleanup 函数和普通名字字符串。对象消失时函数能完成记录，因为它不需要重新读对象字段。真实资源可以用独立的句柄状态或受控资源标识，但必须检查这些参数自身是否又引用包装对象，避免换一层容器后重建同样的环路。
事件列表只包含 good，说明好例子的回调恰好执行一次；随后再次调用已经结束的终结器，没有追加第二次记录。这一保证针对同一个终结器对象，不代表两次独立注册会自动去重，也不证明真实清理动作可以安全重复执行。
显式关闭仍应承担主要责任
需要确定时间释放的资源，应优先提供 close 或上下文管理接口，让调用者明确结束使用。finalize 更适合作为补充措施，而不适合承诺文件在某个时间点关闭或远端操作必定完成。对象回收时机和进程退出方式都可能影响观察结果。
代码的 gc.collect 只是实验控制手段，不能把这里的立即观察结果推广成所有 Python 实现都采用相同回收时序。运行时切换后应复核生命周期测试；强制终止进程也不能指望正常清理逻辑必然执行。不要用终结器替代事务提交或可靠任务队列。
另外，清理回调中发生的异常可能无法像普通调用那样交给原调用方处理。应让回调职责很小，记录必要故障，并避免依赖已失效的其他对象。验收时同时观察目标是否存活、终结器 alive 状态与清理事件数量，才能区分未回收、已拆除和已完成三种情况。
资料核对日期：2026年10月2日（北京时间）。代码在 CPython 3.12.14 中独立运行。
