关于Python中的弱引用

原文地址：https://yuerblog.cc/2018/08/28/python-weakref-real-usage/

弱引用在很多语言中都存在，最常用来解决循环引用问题，我个人熟悉C++的版本。

在本文，我们讲一下python中的weakref弱引用，因为我发现网上没有人把这个东西讲明白，要么是千篇一律解决循环引用，要么是长篇大论各种demo，着实让人头疼。

观察者模式
弱引用是观察者模式，A持有B的弱引用，那么不会对B增加引用计数。

当B引用计数为0之后，A尝试通过弱引用访问B就会失败，因为弱引用对象是观察者，观察着B对象的引用计数。

不同的编程语言实现弱引用的底层原理略有不同，但本质都是观察者模式。

深度解读
下面以C++为例，其实一个对象的引用计数是存储在对象之外的堆内存中的，下面请紧跟我的思路。

A对象在私有属性保存着refcount指针，refcount保存真正的引用计数N，初始化N=1。

当另一处代码想要获取A对象的引用时，调用A->refcount->addRef()令N=N+1，即可增加1个引用计数，确保自己访问A对象期间，内存不会释放。

同样的，释放A引用调用A->refcount->delRef()令N=N-1即可释放自己持有的引用，当N减少为0的时候说明A对象没有人持有，可以释放资源。

总结一下，维护引用计数的是refcount*，而不是A。

当我们创建一个指向A的weakref对象时，它要做的是观察A对象的引用计数，所以weakref对象会将A->refcount*保存在自己的私有属性里。

这时候，refcount对象出现了多处引用的共享问题，所以refcount对象自身也需要引用计数。

refcount有另外一个属性M记录自身被引用的次数，而不是A被引用的次数。

当A创建时M=1，因为只有A保存了refcount；当weakref观察A时，weakref会将A->refcount赋值给自己的私有属性，所以refcount的M=M+1，也就是2。

当A对象的引用计数N减少为0后，A会释放自己，所以也释放了对A->refcount的1个引用计数，此时M=M-1，还剩余1是weakref持有的。

此时weakref可以检查refcount的N=0，即可获知A已经被释放。

当weakref自身释放时，会令weakref->refcount的M=M-1，即M减少为0，此时refcount对象已无人持有，也会被释放。

Python中的weakref
Python的weakref最强的一点，在于其观察者模式可以主动回调。

也就是说，当A对象N=0后，python可以主动通知持有weakref的观察者，即回调通知函数，下面大家看个例子：

import weakref

class Container:
    def __init__(self):
        self.dict = {}

    def add(self, obj):
        # 维护弱引用, 实现gc回调
        self.dict[weakref.ref(obj, self.gc)] = id(obj)

    def gc(self, ref_obj):
        obj_id = self.dict[ref_obj]
        print("移除object id:", obj_id, "weakref对象:", ref_obj, "指向的对象:", ref_obj())
        del self.dict[ref_obj]

class SomeCls:
    pass

容器

container = Container()

任意对象

obj1 = SomeCls()
obj2 = SomeCls()

加入容器

container.add(obj1)
container.add(obj2)

释放对象

del obj2
del obj1

import weakref
 
class Container:
    def __init__(self):
        self.dict = {}
 
    def add(self, obj):
        # 维护弱引用, 实现gc回调
        self.dict[weakref.ref(obj, self.gc)] = id(obj)
 
    def gc(self, ref_obj):
        obj_id = self.dict[ref_obj]
        print("移除object id:", obj_id, "weakref对象:", ref_obj, "指向的对象:", ref_obj())
        del self.dict[ref_obj]
 
class SomeCls:
    pass

容器

container = Container()

任意对象

obj1 = SomeCls()
obj2 = SomeCls()

加入容器

container.add(obj1)
container.add(obj2)

释放对象

del obj2
del obj1
代码输出：

移除object id: 4351353968 weakref对象: <weakref at 0x1035c4598; dead> 指向的对象: None
移除object id: 4351353800 weakref对象: <weakref at 0x1035c4548; dead> 指向的对象: None
1
2
移除object id: 4351353968 weakref对象: <weakref at 0x1035c4598; dead> 指向的对象: None
移除object id: 4351353800 weakref对象: <weakref at 0x1035c4548; dead> 指向的对象: None
容器Conainter：

只维护对象的weakref，并且当对象refcount为0后，会回调container.gc方法。
在gc方法中，把相关的上下文删除掉，其实也就是释放weakref对象自身的内存资源。
python回调时，会传入关联的weakref对象，我们利用weakref()可以获得观察的真实对象，但在gc中一定会返回None，因为对象已经被回收。

用途
理解weakref后，就可以拿来实现一些连接池之类的东西。

比如Conainter是mysql连接池，内部维护了20个mysql连接，然后提供get/put方法来获取connection和归还connection。

那么作为一个工具库提供者，最害怕的就是使用者忘记put归还连接，如何妥善应对这群傻瓜用户呢？最简单的思路就是，当使用者不再持有connection对象后，我们主动把连接回收到连接池中，也就是我们如何知道使用者搞完了？

想办法套用weakref的callback机制！

既然weakref是观察者，那么要观察的就是connection。

但是底层connection对象在Container里本身就维护了一份引用，直接给使用者的话，refcount永远不可能减少为0。

所以，Container返回给使用者的应该是一个WrappedConnection对象，里面装着底层Connection，然后Container额外维护一个WrappedConnection的weakref即可。

当WrappedConnection对象不再被使用者持有后，weakref会回调Container，那么Container就可以把weakref对应的底层Connection归还到池子中。