Python 的 weakref.finalize 经常被当成：

“比 __del__ 更安全的资源释放方案”

确实它解决了：

循环引用导致 __del__ 不执行

GC 顺序问题

对象销毁崩溃

但它本身也有很多非常隐蔽的边缘行为。

尤其：

文件句柄

socket

Selenium driver

asyncio 对象

ctypes 资源

数据库连接

临时文件

这些场景里很容易踩坑。

1. finalize 并不保证立即执行

很多人以为：

import weakref

weakref.finalize(obj, cleanup)

等于：

对象销毁瞬间执行 cleanup

实际上：

finalize 依赖 GC。

例如：

import weakref

class A:

pass

a = A()

weakref.finalize(a, print, "destroyed")

del a

print("end")

输出顺序可能：

end

destroyed

也可能：

destroyed

end

取决于：

CPython 引用计数

GC 时机

PyPy/Jython 实现

2. 在 PyPy 上行为更不稳定

CPython：

引用计数立即回收

所以 finalize 经常“看起来”立即执行。

但 PyPy：

使用 tracing GC

对象真正释放可能延后很久。

因此：

weakref.finalize(...)

不能用于：

实时锁释放

事务提交

临时文件及时删除

3. finalize 回调可能根本不执行

程序退出时：

os._exit(0)

会直接终止进程。

所有 finalize：

全部跳过

甚至：

SIGKILL

kill -9

崩溃

也不会执行。

因此：

finalize 不能替代真正的资源管理。

4. 最危险的问题：回调意外持有对象引用

经典错误：

import weakref

class A:

def cleanup(self):

print(self)

a = A()

weakref.finalize(a, a.cleanup)

这里：

a.cleanup

是 bound method。

它内部持有：

self

引用。

结果：

对象永远无法释放

因为：

finalize -> bound method -> self

形成强引用链。

正确做法

应该：

weakref.finalize(a, A.cleanup, a)

或者：

weakref.proxy(a)

避免强引用。

5. finalize 顺序不可靠

多个对象：

a -> b -> c

注册 finalize：

finalize(a)

finalize(b)

finalize(c)

执行顺序：

不保证。

因此：

cleanup_b()

可能发生时：

a 已经被销毁

导致：

AttributeError

6. 模块卸载问题

程序退出阶段：

sys.modules

可能已经部分清空。

例如：

import weakref

import logging

class A:

pass

a = A()

weakref.finalize(a, logging.info, "cleanup")

程序退出时：

logging

模块可能已经变成：

None

结果：

cleanup 失败

7. finalize 不会阻止对象复活

例如：

import weakref

resurrected = None

class A:

pass

def cleanup(obj):

global resurrected

resurrected = obj

某些复杂场景：

对象可能在 finalize 期间被重新引用。

导致：

半死亡对象

状态。

这是非常危险的。

8. finalize 与循环引用

虽然 finalize 比 __del__ 好。

但：

a.ref = b

b.ref = a

如果 finalize 回调又引用闭包变量：

lambda: print(a)

仍可能形成：

复杂引用链

导致：

延迟回收

GC 压力

内存泄漏

9. finalize 回调异常会被吞掉

例如：

def cleanup():

1 / 0

Python 通常：

打印 stderr

忽略异常

不会真正中断程序。

因此：

资源释放失败

你可能根本没发现。

10. finalize 不适合异步资源

例如：

async def cleanup():

await conn.close()

不能直接：

weakref.finalize(obj, cleanup)

因为 finalize：

不是 async

没 event loop

无法 await

结果：

协程根本没执行

11. finalize 与线程竞争

如果对象在其他线程被释放：

del obj

finalize 回调：

可能在不可预期时间执行。

因此：

cleanup()

里访问：

全局变量

socket

event loop

都可能竞态。

12. finalize 不适合关键资源

很多人把：

数据库提交

文件写入

事务结束

放进 finalize。

这是危险的。

因为 finalize：

不是确定性析构

不能保证：

时机

顺序

是否执行

正确理解 finalize

它更适合：

兜底清理（fallback cleanup）

而不是：

核心资源管理

推荐方案

关键资源

始终优先：

with

try/finally

contextmanager

最安全模式

例如：

class Resource:

def close(self):

...

def __enter__(self):

return self

def __exit__(self, *exc):

self.close()

而：

weakref.finalize

仅作为：

忘记 close 时的最后保险

官方都不建议依赖 finalize 做核心逻辑

因为它本质仍依赖：

垃圾回收时机

而垃圾回收：

不确定

可延迟

可跳过

可跨线程

一个常见正确用法

例如临时文件：

import tempfile

import weakref

import os

class TempFile:

def __init__(self):

self.path = tempfile.mktemp()

weakref.finalize(

self,

os.remove,

self.path

)

即使用户忘记：

close()

最终也有机会清理。

但：

不能保证立即删除

所以：

真正稳妥的代码仍要：

try/finally

主动释放资源。

使用 weakref.finalize 释放资源的微妙问题